Este documento describe cómo se publica GKI v5.10 para Android 12, incluidos los lanzamientos de emergencia semanales, mensuales y fuera de banda. El objetivo de este documento es brindar a los OEM una guía sobre dónde obtener el GKI, así como el proceso para las reparaciones de emergencia fuera de banda. Los OEM también pueden usar la guía de desarrollo de GKI para obtener más información sobre cómo pueden trabajar con el equipo de Android Kernel para optimizar el kernel de GKI para sus productos.
Cadencia de liberación de GKI
GKI se publica en una publicación de cadencia mensual KMI Freeze a partir del 14 de julio de 2021. El siguiente gráfico ilustra la cadencia del programa de lanzamiento.
| Compilaciones certificadas mensuales de GKI | Fecha límite de entrada | Fecha de preparación de la precarga de GKI | Etiqueta | ¿Confirmado? | |
|---|---|---|---|---|---|
| Julio (Congelar KMI) | 14 de julio de 2021 | Finales de julio | androide 12 Construcción certificada por AOSP: julio | Sí | |
| Agosto | 16 de agosto de 2021 | Finales de agosto | androide 12 Versión certificada por AOSP: agosto | Sí | |
| Septiembre | 17 de septiembre de 2021 | finales de septiembre | androide 12 Versión certificada por AOSP: septiembre | Sí | |
| Octubre | 15 de octubre de 2021 | 29 de octubre de 2021 | androide 12 Versión certificada por AOSP: octubre | Sí | |
| Noviembre | 12 de noviembre de 2021 | 30 de noviembre de 2021 | androide 12 Versión certificada por AOSP: noviembre | Sí | |
| Diciembre | 10 de diciembre de 2021 | 22 de diciembre de 2021 | androide 12 Construcción certificada por AOSP: diciembre | Sí | |
| enero | 14 de enero de 2022 | 31 de enero de 2022 | androide 12 Construcción certificada por AOSP: enero | Sí | |
| Febrero | 14 de febrero de 2022 | 28 de febrero de 2022 | androide 12 Compilación certificada por AOSP: febrero | Sí | |
| Marzo | 16 de marzo de 2022 | 31 de marzo de 2022 | androide 12 Versión certificada por AOSP: marzo | Sí | |
| Abril | 15 de abril de 2022 | 29 de abril de 2022 | androide 12 Construcción certificada por AOSP: abril | Sí | |
| Mayo | 16 de mayo de 2022 | 31 de mayo de 2022 | androide 12 Construcción certificada por AOSP: mayo | Sí | |
| Junio | 15 de junio de 2022 | 30 de junio de 2022 | androide 12 Construcción certificada por AOSP: junio | Sí | |
| Julio | 15 de julio de 2022 | 29 de julio de 2022 | androide 12 Construcción certificada por AOSP: julio | Sí | |
| Agosto | 15 de agosto de 2022 | 31 de agosto de 2022 | androide 12 Versión certificada por AOSP: agosto | Sí | |
| Septiembre | 16 de septiembre de 2022 | 30 de septiembre de 2022 | androide 12 Versión certificada por AOSP: septiembre | Sí | |
| Octubre | 14 de octubre de 2022 | 31 de octubre de 2022 | androide 12 Versión certificada por AOSP: octubre | Sí | |
| Noviembre | 14 de noviembre de 2022 | 30 de noviembre de 2022 | androide 12 Versión certificada por AOSP: noviembre | Sí | |
| Diciembre | 9 de diciembre de 2022 | 21 de diciembre de 2022 | androide 12 Construcción certificada por AOSP: diciembre | Sí |
Validez de compilación de GKI para OEM
Los OEM pueden usar un GKI de Android lanzado recientemente. Los OEM pueden lanzar compilaciones certificadas por GKI siempre que cumplan con los requisitos de LTS en el Boletín de seguridad de Android (ASB).
Política de renovación de compilación certificada
- Los binarios certificados por GKI no son compatibles con los giros una vez que ya no cumplen con los requisitos de LTS en ASB. Por ejemplo, la rama
android12-5.10-2021-11(5.10.66) no se admite para giros posteriores después de noviembre de 2022, porque la ramaandroid12-5.10-2021-11(5.10.66) no cumple con los requisitos de LTS de ASB-2022-11. - Consulte Proceso de giro de emergencia para obtener más información.
Lanzamientos de desarrollo semanales
Los lanzamientos se prueban con sepias para garantizar que superen un estándar de calidad mínimo .Los archivos binarios de GKI están disponibles para el autoservicio en ci.android.com a medida que se fusionan los cambios. Las compilaciones semanales no se certificarán, aunque se pueden usar como referencia para el desarrollo y las pruebas. Las compilaciones semanales no se pueden usar para compilaciones de dispositivos de producción para usuarios finales.
Lanzamientos certificados mensuales
Los lanzamientos mensuales de GKI contienen un boot.img probado que incluye un certificado insertado por Google para atestiguar que los archivos binarios se crearon a partir de una línea de base de código fuente conocida.
Cada mes, se selecciona un candidato de lanzamiento mensual de GKI (no certificado) después de la fecha límite de registro, que suele ser la segunda compilación semanal de ese mes. Después de seleccionar la versión candidata mensual, no se aceptarán nuevos cambios en la versión de ese mes. Durante el período de ventana cerrada, solo se pueden abordar las correcciones de errores que causan fallas en la prueba. La versión candidata se somete a control de calidad, como se describe en la sección de calificación de GKI, para garantizar que las pruebas de cumplimiento pasen en la compilación de GSI+GKI con un dispositivo de referencia y con sepia.
Figura 1. Cronograma de lanzamiento de GKI
Proceso de giro de emergencia
Figura 2. El proceso de giro de emergencia
Es posible que los OEM necesiten volver a girar el kernel para obtener las aprobaciones técnicas (TA) que están bloqueando el problema. Los respins se admiten en compilaciones de versiones certificadas mensuales y tienen un tiempo de resolución estándar esperado (ESRT) de dos días hábiles en la zona horaria de EE. UU.
ESRT se define como el tiempo que se tarda en entregar un binario de GKI certificado que contiene la corrección, siempre que haya sido aprobado por el equipo de GKI y revisado por el OEM afectado. ESRT es solo una estimación y no debe interpretarse como una garantía.
Los OEM que necesitan un nuevo giro para una solución de bloqueo de TA deben hacer lo siguiente:
- Registre un error en el Rastreador de problemas y comuníquese con su punto de contacto de Google de inmediato.
- Si ya tiene una solución, el error debería apuntar al envío del parche en AOSP para que Google pueda revisarlo. Si no es factible enviar el parche, adjunte el parche como un archivo de texto al error en el Rastreador de problemas .
- Si aún no tiene una solución, el error debe incluir la mayor cantidad de información posible, incluido el número de versión del kernel y los registros, para que Google pueda ayudar a solucionar el problema.
- Una vez que se acuerda una solución, el código del equipo de GKI de Google revisa (CR+2) el cambio y prueba la regresión. La prueba inicia la cuenta regresiva de ESRT y finaliza cuando el binario se publica en ci.android.com .
Calificaciones GKI
| Tipos de compilaciones de GKI | Cumplimiento de la calidad | notas |
|---|---|---|
| Semanalmente | Prueba de sepia
|
|
| Mensual (certificado) | Prueba de sepia
| |
| Respins (certificado) | Prueba de sepia
|
|
Dónde obtener artefactos de construcción
Los artefactos para todas las versiones se pueden obtener en ci.android.com .
Puede encontrar más información sobre el CI, incluidos los resultados de las pruebas, en el panel de control de integración continua de Android .
preguntas frecuentes
¿Es posible construir un nuevo binario GKI basado en un GKI ya publicado?
Sí, esto se conoce como respin. El proceso de repetición es compatible siempre que la compilación de GKI publicada (en la que se solicita la repetición) cumpla con los requisitos de LTS del Boletín de seguridad de Android (ASB).
¿Es posible reproducir binarios GKI?
Sí, consulte el ejemplo a continuación.
GKI 2.0
5.10 kernel prebuilts from build 7364300
https://ci.android.com/builds/submitted/7364300/kernel_aarch64/latest
Para reproducir el ejemplo, descargue manifest_$id.xml y ejecute el siguiente comando:
repo init -u https://android.googlesource.com/kernel/manifestmv manifest_7364300.xml .repo/manifestsrepo init -m manifest_7364300.xml --depth=1repo sync # build the GKI images # You may want to use LTO=thin to build faster for developmentBUILD_CONFIG=common/build.config.gki.aarch64 build/build.sh # (optional) build virtual platform modulesBUILD_CONFIG=common-modules/virtual-device/build.config.virtual_device.aarch64 build/build.sh
Puede recuperar su copia de artefacto GKI desde out/.../dist .
¿Se ha creado el binario GKI (incluido el parche de giro de emergencia) en el
última base de código?
No. Los respins solo contienen parches que se encuentran por encima de los kernels certificados mensuales que se han elegido. Estos respins contienen todas las correcciones de errores de bloqueo de lanzamiento informadas hasta un momento dado por los OEM utilizando la versión mensual base correspondiente. Vea el siguiente ejemplo de cómo sucede este tipo de escenario.
- OEM1 y OEM2 deciden utilizar la versión binaria de GKI a partir de noviembre de 2021.
- OEM1 y OEM2 encuentran problemas que requieren parches para soporte. Estos parches pueden ser diferentes o pueden ser iguales.
- Los respins por encima del binario de noviembre de 2021 tienen correcciones de bloqueo de lanzamiento informadas por OEM1 y OEM2 durante la ventana de respin, pero nada más.
- Los problemas mencionados en la segunda viñeta también se incluyen en versiones mensuales posteriores de GKI.
El respin de octubre tiene todos los parches enviados por OEM, pero otros parches OEM
nos afectan, porque no han sido probados específicamente con nuestros productos. ¿Es posible incluir solo nuestro parche?
Esto no es posible. Actualmente, una ruta de giro "por OEM" no es escalable. En cambio, el equipo de GKI examina cada cambio que se realiza en las compilaciones renovadas y prueba los cambios con todo el hardware disponible antes de crear una nueva compilación. Si el equipo de GKI encuentra que el problema es específico de un OEM/dispositivo/modelo, el equipo de GKI puede asegurarse de que el código agregado por el cambio solo se ejecute en el dispositivo/modelo/SKU afectado.
El principal beneficio de los respins unificados es que todos los dispositivos que usan la misma versión base se benefician unos de otros, especialmente si los errores que descubren son genéricos y aplicables a todos los usuarios. Los errores del kernel central encontrados en las pruebas de los operadores son un ejemplo específico de este concepto.
¿Hay situaciones en las que Google proporciona información específica sobre parches OEM y escenarios de problemas, de modo que los OEM puedan evaluar el impacto y el riesgo de implementar los parches con sus productos?
Google nunca agregará un cambio a una compilación respin hasta que se comprenda el problema y se hayan recopilado todos los detalles. Esto se ve en el registro de cambios (mensaje de confirmación). Google no revela qué dispositivo específico afecta, pero los OEM siempre pueden encontrar la descripción y la solución del problema en el registro de cambios.