En este documento, se describe cómo se lanza GKI, incluidas las actualizaciones de emergencia semanales, mensuales y fuera de banda. El objetivo de este documento es brindar a los OEM un lineamiento sobre dónde retirar el GKI, así como el proceso para las correcciones 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 trabajar con el equipo de kernel de Android a fin de optimizar el kernel de GKI para sus productos.
Cadencia de lanzamiento de GKI
GKI se lanza con una cadencia mensual después de que se suspende el servicio KMI.
Versión de GKI de Android 13, 14 y 15
La siguiente tabla solo se aplica a android13-5.10, android13-5.15 y android14-6.1.
| Compilaciones mensuales certificadas de GKI | Fecha límite para hacer el registro de entrada | Fecha de preparación de la precarga de GKI | ¿Confirmaste? |
|---|---|---|---|
| Octubre | 14 de octubre de 2022 | 31 de octubre de 2022 | Sí |
| Noviembre | 14 de noviembre de 2022 | 30 de noviembre de 2022 | Sí |
| Diciembre | 9 de diciembre de 2022 | 21 de diciembre de 2022 | Sí |
| Enero | 17 de enero de 2023 | 31 de enero de 2023 | Sí |
| Febrero | 15 de febrero de 2023 | 28 de febrero de 2023 | Sí |
| Marzo | 15 de marzo de 2023 | 31 de marzo de 2023 | Sí |
| Abril | 13 de abril de 2023 | 28 de abril de 2023 | Sí |
| Mayo | 17 de mayo de 2023 | 31 de mayo de 2023 | Sí |
| Junio | 15 de junio de 2023 | 30 de junio de 2023 | Sí |
| Julio | 18 de julio de 2023 | 31 de julio de 2023 | Sí |
| Agosto | 16 de agosto de 2023 | 31 de agosto de 2023 | Sí |
| Septiembre | 14 de septiembre de 2023 | 29 de septiembre de 2023 | Sí |
| Octubre | 18 de octubre de 2023 | 31 de octubre de 2023 | Sí |
| Noviembre | 10 de noviembre de 2023 | 30 de noviembre de 2023 | Sí |
| Diciembre | 7 de diciembre de 2023 | 22 de diciembre de 2023 | Sí |
| Enero | 16 de enero de 2024 | 31 de enero de 2024 | Sí |
| Febrero | 13 de febrero de 2024 | 29 de febrero de 2024 | Sí |
| Marzo | 13 de marzo de 2024 | 29 de marzo de 2024 | Sí |
| Abril | 16 de abril de 2024 | 30 de abril de 2024 | Sí |
| Mayo | 14 de mayo de 2024 | 31 de mayo de 2024 | Sí |
| Junio | 12 de junio de 2024 | 28 de junio de 2024 | Sí |
| Julio | 16 de julio de 2024 | 31 de julio de 2024 | Sí |
| Agosto | 15 de agosto de 2024 | 30 de agosto de 2024 | Sí |
| Septiembre | 17 de septiembre de 2024 | 30 de septiembre de 2024 | Sí |
| Octubre | 15 de octubre de 2024 | 31 de octubre de 2024 | Sí |
| Noviembre | 11 de noviembre de 2024 | 27 de noviembre de 2024 | Sí |
| Diciembre | 6 de diciembre de 2024 | 23 de diciembre de 2024 | Sí |
A partir de enero de 2024, reanudaremos los lanzamientos mensuales de android14-5.15 de acuerdo con la cadencia mensual especificada que se describe en la siguiente tabla.
android15-6.6 seguirá la misma cadencia de lanzamiento a partir de julio de 2024.
| Compilaciones mensuales certificadas de GKI | Fecha límite para hacer el registro de entrada | Fecha de preparación de la precarga de GKI | ¿Confirmaste? |
|---|---|---|---|
| Enero | 16 de enero de 2024 | 31 de enero de 2024 | Sí |
| Febrero | 13 de febrero de 2024 | 29 de febrero de 2024 | Sí |
| Marzo | 4 de marzo de 2024 | 15 de marzo de 2024 | Sí |
| Abril | 1 de abril de 2024 | 17 de abril de 2024 | Sí |
| Mayo | 1 de mayo de 2024 | 17 de mayo de 2024 | Sí |
| Junio | 3 de junio de 2024 | 17 de junio de 2024 | Sí |
| Julio | 1 de julio de 2024 | 15 de julio de 2024 | Sí |
| Agosto | 1 de agosto de 2024 | 16 de agosto de 2024 | Sí |
| Septiembre | 2 de septiembre de 2024 | 16 de septiembre de 2024 | Sí |
| Octubre | 1 de octubre de 2024 | 14 de octubre de 2024 | Sí |
| Noviembre | 1 de noviembre de 2024 | 15 de noviembre de 2024 | Sí |
| Diciembre | 2 de diciembre de 2024 | 16 de diciembre de 2024 | Sí |
Versión de GKI de Android 12
Después de mayo de 2024, las versiones de GKI de android12-5.10 se realizarán con una cadencia trimestral y se publicarán a mediados de mes.
La siguiente tabla solo se aplica a android12-5.10.
| Compilaciones mensuales certificadas de GKI | Fecha límite para hacer el registro de entrada | Fecha de preparación de la precarga de GKI | ¿Confirmaste? |
|---|---|---|---|
| Julio | 3 de julio de 2023 | 14 de julio de 2023 | Sí |
| Septiembre | 1 de septiembre de 2023 | 15 de septiembre de 2023 | Sí |
| Noviembre | 3 de noviembre de 2023 | 17 de noviembre de 2023 | Sí |
| Enero | 5 de enero de 2024 | 19 de enero de 2024 | Sí |
| Marzo | 4 de marzo de 2024 | 15 de marzo de 2024 | Sí |
| Mayo | 1 de mayo de 2024 | 17 de mayo de 2024 | Sí |
| Agosto | 1 de agosto de 2024 | 16 de agosto de 2024 | Sí |
| Noviembre | 1 de noviembre de 2024 | 15 de noviembre de 2024 | Sí |
| Febrero | 3 de febrero de 2025 | 17 de febrero de 2025 | Sí |
Validez de compilación de GKI para OEM
Los OEMs pueden usar un GKI de Android publicado recientemente. Los OEM pueden realizar lanzamientos con compilaciones certificadas por GKI, siempre que cumplan con los requisitos de LTS del Boletín de seguridad de Android (ASB).
Versiones de desarrollo semanales
Las versiones se prueban con sepia para garantizar que superen una barra de calidad mínima.Los objetos binarios de GKI están disponibles para el autoservicio desde ci.android.com a medida que se combinan los cambios. Las compilaciones semanales no se certificarán, aunque se pueden usar como modelo de referencia para el desarrollo y las pruebas. Las compilaciones semanales no se pueden usar para las compilaciones de dispositivos de producción destinadas a usuarios finales.
Versiones certificadas mensuales
Las versiones mensuales de GKI contienen un boot.img probado que incluye un certificado insertado por Google para certificar que los objetos binarios se compilaron a partir de un modelo de referencia de código fuente conocido.
Cada mes, se selecciona un candidato para el lanzamiento mensual de GKI (no certificado) después de la fecha límite de entrada, que suele ser la segunda compilación semanal de ese mes. Una vez que se seleccione la versión potencial mensual, no se aceptarán los cambios nuevos en el lanzamiento de ese mes. Durante el período de cierre de la ventana, solo se pueden abordar las correcciones de los errores que causan fallas en las pruebas. La versión candidata para el lanzamiento se somete a controles de calidad, como se describe en la sección de calificación de GKI, para garantizar que las pruebas de cumplimiento sean exitosas en la compilación de GSI+GKI con un dispositivo de referencia y con sepia.
Figura 1: Cronograma de lanzamiento de GKI
Proceso de relanzamiento de emergencias
Un relanzamiento hace referencia al proceso de volver a combinar, volver a compilar, volver a probar y recertificar un objeto binario después de un lanzamiento público del kernel de GKI. Puedes solicitar que se vuelva a configurar un objeto binario certificado en cualquiera de las siguientes circunstancias:
- Actualiza una lista de símbolos.
- Para corregir un error, incluidos los que se detectaron durante la aprobación del laboratorio del operador.
- Para agregar un hook del proveedor.
- Aplicar un parche a una función existente
- Aplicar un parche de seguridad (después de 6 meses)
Los parches de seguridad se combinan automáticamente en una rama de la versión durante un máximo de 6 meses después del lanzamiento de la rama. Después del límite de 6 meses, debes solicitar una nueva fijación para aplicar parches de seguridad a una rama.
Antes de solicitar una nueva operación, ten en cuenta los siguientes lineamientos:
Los relanzamientos solo se permiten en las ramas de versión después de que se lanza el lanzamiento público inicial de una compilación mensual.
Las solicitudes de relanzamiento solo se aceptan para una rama de lanzamiento determinada durante un máximo de seis meses después del lanzamiento público inicial. Después de seis meses, las ramas son aptas para volver a pintar solo para los parches de seguridad citados en un Boletín de seguridad de Android.
Cuando los requisitos de LTS, definidos por el Boletín de seguridad de Android (ASB) hacen que la rama no cumpla con los requisitos, deja de estar disponible. No se aceptan las solicitudes de relanzamiento de ramas obsoletas. La fecha de baja de una rama de la versión de GKI determinada se incluye en las notas de compilación de la versión de GKI mensuales que se encuentran en Versiones. Para la planificación futura, los requisitos de LTS se actualizan en mayo y noviembre de forma anual. Por ejemplo, la rama
android12-5.10-2023-07(5.10.177) no es compatible con las reposiciones después del 1 de mayo de 2024, porque la ramaandroid12-5.10-2023-07(5.10.177) no cumple con los requisitos de LTS de ASB-2024-05.Los relanzamientos solo se aplican a correcciones de errores urgentes, actualizaciones de lista de símbolos o a la aplicación de un parche para corregir una función existente.
Todos los parches que se incluyen en la rama de versión mensual ya deben estar combinados en la rama principal de desarrollo de GKI. Por ejemplo, si se requiere un parche para volver a configurar
android12-5.10-2022-09, ya debe estar combinado enandroid12-5.10.Debes seleccionar los parches de la rama principal de desarrollo de GKI y subir el parche a la rama de actualización mensual.
En la solicitud de relanzamiento, debes asignarle una prioridad (urgencia). Esta prioridad ayuda al equipo de GKI a asistir mejor a los socios de manera oportuna. Para solicitudes críticas o urgentes, marca la prioridad como P0. Para las solicitudes P0 y P1, también debes justificar la urgencia. En la siguiente tabla, se proporciona una asignación de la prioridad de los errores y el tiempo de resolución (ESRT):
Prioridad ESRT P0 Dos días hábiles P1 5 días hábiles P2 10 días hábiles P3 15 días laborables
Debes enviar una solicitud de relanzamiento independiente por cada rama de la versión. Por ejemplo, si se necesita una nueva solicitud para
android12-5.10-2022-08yandroid12-5.10-2022-09, debes crear dos solicitudes.Después de que se proporciona una compilación y se marca una solicitud de nuevo proceso como corregida, no debes volver a abrir la solicitud para agregar CL adicionales. Debes enviar una nueva solicitud de relanzamiento si hay parches adicionales que deban combinarse.
Para cada CL en consideración, agrega las siguientes etiquetas. Sin esta información, se bloquea el progreso de la solicitud de volver a fijar.
Bug: El ID de error se debe agregar al mensaje de confirmación para cada CL.Change-Id: Debe ser idéntico al ID de cambio del cambio de rama base.
Si una solicitud de relanzamiento requiere tu respuesta y no respondes en un plazo de tres días hábiles, la prioridad se baja de un nivel (por ejemplo, P0 pasa a una versión anterior P1). Si no respondes durante dos semanas, el error se marcará como No se solucionará (Obsoleto).
Envía una solicitud de relanzamiento
En el siguiente diagrama, se muestra el proceso de relanzamiento. El proceso comienza cuando el socio OEM (tú) envía la solicitud de relanzamiento.
Figura 2: El proceso de relanzamiento
Para ingresar al proceso de relanzamiento:
- Completa el formulario de solicitud de GKI Respin y comunícate con tu administrador técnico de cuentas de Google de inmediato. Este formulario crea un error de solicitud de relanzamiento de GKI. Puedes ver los errores de la solicitud de relanzamiento (el solicitante), el equipo de GKI y las personas específicas que agregues a la lista de Cc del error.
- Si ya tienes una corrección, la solicitud debe apuntar al envío del parche en el AOSP para que Google pueda revisarlo. Si no es posible enviar el parche, este se debe adjuntar como un archivo de texto a la solicitud.
- Si no tienes una solución, la solicitud debe contener la mayor cantidad de información posible, incluidos el número de versión de kernel y los registros, para que Google pueda ayudar a depurar el problema.
- El equipo de GKI de Google revisa la solicitud y la aprueba o te asigna de nuevo si se necesita más información.
- Después de que se acuerda una corrección, el equipo de GKI de Google revisa el código (CR+2) el cambio. La revisión comienza en el período de ESRT. El equipo de GKI combina, compila, prueba la regresión y certifica el cambio.
- El objeto binario se lanza en ci.android.com. El plazo de ESRT finaliza, y el equipo de GKI de Google marca la solicitud como corregida y hace referencia a la compilación de relanzamiento. La compilación de relanzamiento también se publicará en la página de compilaciones de lanzamiento de imágenes genéricas de kernel (GKI).
Calificaciones de GKI
| Tipos de compilaciones de GKI | Cumplimiento de la calidad | Notes |
|---|---|---|
| Todas las semanas | Pruebas de Cuttlefish
|
|
| Mensual (certificado) | Pruebas de Cuttlefish
|
|
| Vuelve a activar (certificado) | Pruebas de Cuttlefish
|
|
Dónde obtener artefactos de compilación
Los artefactos de todas las versiones se pueden obtener en ci.android.com.
Puedes encontrar más información sobre la CI, incluidos los resultados de la prueba en el panel de integración continua de Android.
Preguntas frecuentes
¿Es posible compilar un nuevo objeto binario de GKI basado en un GKI ya lanzado?
Sí, esto se conoce como relanzamiento. El proceso de relanzamiento es compatible siempre que la compilación de GKI lanzada (en la que se solicita la relanzamiento) cumpla con los requisitos de LTS del Boletín de seguridad de Android (ASB).
¿Es posible reproducir objetos binarios de GKI?
Sí, consulta el siguiente ejemplo.
GKI 2.0
5.10 kernel prebuilts from build 7364300
https://ci.android.com/builds/submitted/7364300/kernel_aarch64/latest
Para reproducir el ejemplo, descarga manifest_$id.xml y ejecuta 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
Puedes recuperar la copia de tu artefacto de GKI desde out/.../dist.
¿Se compiló el objeto binario de GKI (incluido el parche de giro de emergencia) en la base de código más reciente?
No. Las respins solo contienen parches que se encuentran sobre los kernels certificados mensuales que se eligieron. Estas reposiciones contienen todas las correcciones de errores de bloqueo del lanzamiento que los OEM informan hasta un momento determinado mediante la versión mensual base correspondiente. Observa el siguiente ejemplo de cómo ocurre este tipo de situación.
- OEM1 y OEM2 deciden usar la versión binaria de GKI a partir de noviembre de 2021.
- OEM1 y OEM2 encuentran problemas que requieren parches para la compatibilidad. Estos parches pueden ser diferentes o iguales.
- Las repeticiones sobre el objeto binario de noviembre de 2021 tienen correcciones de bloqueo del lanzamiento informadas por OEM1 y OEM2 durante la ventana de relanzamiento, pero nada más.
- Los problemas mencionados en el segundo punto también se incluyen en las versiones mensuales posteriores de GKI.
La nueva versión de octubre incluye todos los parches que envió el OEM, pero otros parches del OEM nos afectan porque no se probaron específicamente con nuestros productos. ¿Es posible incluir solo nuestro parche?
Esto no es posible. Por el momento, no es escalable una ruta de relanzamiento "por OEM". En cambio, el equipo de GKI analiza cada cambio que se incluye en las compilaciones de relanzamiento y prueba los cambios con todo el hardware disponible antes de crear una compilación nueva. Si el equipo de GKI descubre que el problema es específico de un OEM, dispositivo o modelo, puede asegurarse de que el código que agregó el cambio solo se ejecute en el dispositivo, el modelo o el SKU afectado.
El mayor beneficio de las respins unificadas es que todos los dispositivos que usan la misma base de versiones se benefician entre sí, en especial si los errores que descubren son genéricos y aplicables a todos los usuarios. Los errores principales del kernel que se encuentran en las pruebas de proveedores son un ejemplo específico de este concepto.
¿Hay situaciones en las que Google proporcione información específica sobre los parches del OEM y situaciones de problemas para que los OEM puedan evaluar el impacto y el riesgo de implementar los parches en sus productos?
Google nunca agregará un cambio a una compilación de relanzamiento hasta que se comprenda el problema y se recopilen todos los detalles. Esto se ve en el registro de cambios (mensaje de confirmación). Google no revela a qué dispositivo específico afecta, pero los OEM siempre pueden encontrar la descripción del problema y su solución en el registro de cambios.