En esta página, se describe cómo se lanzan las GKI, incluidas las versiones semanales, mensuales y fuera de banda de emergencia. El objetivo de este documento es proporcionar a los OEMs una guía sobre dónde recoger el GKI, así como el proceso para las correcciones de emergencia fuera de banda. Los OEMs también pueden usar el desarrollo de GKI para obtener más información sobre cómo trabajar con el equipo del kernel de Android y optimizar el kernel de GKI para sus productos.
Cadencia de lanzamientos de GKI
GKI se lanza con una cadencia mensual después de la inmovilización de KMI.
Lanzamiento de GKI de Android 13, 14 y 15
La siguiente tabla solo se aplica a android13-5.10, android13-5.15 y android14-5.15.
| Compilaciones mensuales certificadas de GKI | Fecha límite de entrada | Fecha de preparación para la carga previa de GKI | ¿Confirmado? |
|---|---|---|---|
| Noviembre | 11 de noviembre de 2024 | 27 de noviembre de 2024 | Sí |
| Enero | 14 de enero de 2025 | 31 de enero de 2025 | Sí |
| Marzo | 14 de marzo de 2025 | 31 de marzo de 2025 | Sí |
La siguiente tabla solo se aplica a android14-6.1 y android15-6.6.
| Compilaciones mensuales certificadas de GKI | Fecha límite de entrada | Fecha de preparación para la carga previa de GKI | ¿Confirmado? |
|---|---|---|---|
| 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í |
| Enero | 6 de enero de 2025 | 22 de enero de 2025 | Sí |
Versión de GKI de Android 12
Después de mayo de 2024, los lanzamientos de GKI de android12-5.10 tendrán 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 de entrada | Fecha de preparación para la carga previa de GKI | ¿Confirmado? |
|---|---|---|---|
| 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 la compilación de GKI para OEMs
Los OEMs pueden usar un GKI de Android lanzado recientemente. Los OEMs pueden lanzar compilaciones con certificación de GKI, siempre y cuando cumplan con los requisitos de LTS en el Boletín de seguridad de Android (ASB).
Lanzamientos de desarrollo semanales
Las versiones se prueban con Cuttlefish para garantizar que superen una barra de calidad mínima.Los objetos binarios de GKI están disponibles para el autoservicio desde Android CI a medida que se combinan los cambios. Las compilaciones semanales no se certificarán, pero se pueden usar como un modelo de 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 mensuales certificados
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 una versión candidata mensual de GKI (no certificada) 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 cambios nuevos en la versión de ese mes. Durante el período de la ventana cerrada, solo se pueden abordar las correcciones de errores que causan fallas en las pruebas. 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 se aprueben en la compilación de GSI+GKI con un dispositivo de referencia y cuttlefish.
Figura 1: Cronograma de lanzamientos de GKI
Proceso de reenvío de emergencia
Un relanzamiento se refiere al proceso de volver a combinar, volver a compilar, volver a probar y volver a certificar un objeto binario después de un lanzamiento público del kernel de GKI. Puedes solicitar una nueva compilación de un binario certificado en cualquiera de las siguientes circunstancias:
- Para actualizar una lista de símbolos.
- Para aplicar una corrección a un error, incluidos los errores encontrados durante la aprobación del lab del operador.
- Para agregar un hook de proveedor.
- Para aplicar un parche a un componente existente.
- Aplicar un parche de seguridad (después de 6 meses)
Los parches de seguridad se combinan automáticamente en una rama de lanzamiento hasta 6 meses después del lanzamiento de la rama. Después del corte de 6 meses, debes solicitar una nueva revisión para aplicar parches de seguridad a una rama.
Lineamientos para las solicitudes de revisión
Antes de solicitar una nueva revisión, ten en cuenta los siguientes lineamientos:
Los reenganches solo se permiten en las ramas de lanzamiento después de que se haya lanzado una versión pública inicial de una compilación mensual.
Las solicitudes de reintento 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 el reenvío solo para los parches de seguridad que se citan 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, esta se da de baja. No se aceptan solicitudes de reintento para ramas obsoletas. La fecha de baja de una rama de lanzamiento de GKI determinada se incluye en las notas de compilación de lanzamiento de GKI mensuales en Lanzamientos. Para la planificación futura, los requisitos de LTS se actualizan anualmente en mayo y noviembre. Por ejemplo, la rama
android12-5.10-2023-07(5.10.177) no es compatible con los reintentos después del 1 de mayo de 2024, ya que la ramaandroid12-5.10-2023-07(5.10.177) no cumple con los requisitos de LTS de ASB-2024-05.Los reenvíos solo se aplican para correcciones de errores urgentes, actualizaciones de listas de símbolos o para aplicar un parche para corregir una función existente.
Todos los parches que se incluyen en la rama de lanzamiento mensual ya deben combinarse con la rama de desarrollo principal de GKI. Por ejemplo, si se requiere un parche para un reintento de
android12-5.10-2022-09, ya debe haberse fusionado enandroid12-5.10.Debes elegir los parches de la rama principal de desarrollo de GKI y subirlos a la rama de lanzamiento mensual.
En la solicitud de reenvío, debes asignarle una prioridad (urgencia). Esta prioridad ayuda al equipo de GKI a brindar una mejor asistencia a los socios de forma oportuna. Para solicitudes urgentes o importantes, marca la prioridad como P0. En el caso de las solicitudes P0 y P1, también debes justificar la urgencia. En la siguiente tabla, se proporciona una asignación de la prioridad de 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 revisión por separado para cada rama de lanzamiento. Por ejemplo, si se necesita un reenvío para
android12-5.10-2022-08yandroid12-5.10-2022-09, debes crear dos solicitudes de reenvío.Después de proporcionar una compilación y marcar una solicitud de reenvío como corregida, no deberías volver a abrir la solicitud de reenvío para agregar CL adicionales. Debes enviar una nueva solicitud de revisión si hay parches adicionales que se deben combinar.
Para cada CL en consideración, agrega las siguientes etiquetas.
Bug: El ID del error se debe agregar al mensaje de confirmación de cada CL.Change-Id: Debe ser idéntico al ID de cambio de la rama base.
Si una solicitud de nueva respuesta requiere tu respuesta y no respondes en un plazo de tres días hábiles, la prioridad se reduce en un nivel (por ejemplo, P0 se reduce a P1). Si no respondes durante dos semanas, el error se marca como No se corregirá (obsoleto).
Cómo enviar una solicitud de revisión
En el siguiente diagrama, se muestra el proceso de reenvío. El proceso comienza cuando el socio OEM (tú) envía la solicitud de nueva revisión.
Figura 2: El proceso de reenvío
Para ingresar al proceso de reenvío, haz lo siguiente:
- 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 rechazo de GKI. Tú (el solicitante), el equipo de GKI y las personas específicas que agregues a la lista de Cc del error pueden ver los errores de la solicitud de reenvío.
- Si ya tienes una solución, la solicitud debe apuntar al envío de parches en AOSP para que Google pueda revisarla. Si no es posible enviar el parche, este se debe adjuntar como 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 del kernel y los registros, para que Google pueda ayudar a depurar el problema.
- El equipo de GKI de Google revisará la solicitud y la aprobará o te la volverá a asignar si se necesita más información.
- Después de que se apruebe una corrección, el equipo de GKI de Google revisa el código (CR+2) del cambio. La revisión inicia el período del ESRT. El equipo de GKI combina, compila, prueba la regresión y certifica el cambio.
- El objeto binario se publica en ci.android.com. El período de la ESRT finaliza, y el equipo de GKI de Google marca la solicitud como corregida y hace referencia a la compilación de respin. La compilación de respin también se publicará en la página de compilaciones de lanzamiento de la imagen genérica de kernel (GKI).
Calificaciones de GKI
| Tipos de compilaciones de GKI | Aplicación de los estándares de calidad | Notas |
|---|---|---|
| Semanal | Pruebas de Cuttlefish
|
|
| Mensual (certificado) | Pruebas de Cuttlefish
|
|
| Reintentos (certificados) | 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 las pruebas, en el panel de Integración continua de Android.
Preguntas frecuentes
Estas son algunas preguntas frecuentes relacionadas con el proceso de lanzamiento de GKI.
¿Es posible compilar un nuevo GKI binario basado en un GKI que ya se lanzó?
Sí, esto se conoce como un rechazo. El proceso de nueva resolución es compatible, siempre y cuando la compilación de GKI publicada (en la que se solicita la nueva resolución) cumpla con los requisitos de LTS en el Boletín de seguridad de Android (ASB).
¿Es posible reproducir objetos binarios de GKI?
Sí, este es un 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 tu copia de 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. Los reintentos solo contienen parches que se encuentran sobre los kernels mensuales certificados que se eligieron. Estas revisiones contienen todas las correcciones de errores de bloqueo de inicio que los OEMs informaron hasta un momento determinado con la versión mensual base correspondiente. Consulta 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 asistencia. Estos parches pueden ser diferentes o iguales.
- Los respins sobre el binario de noviembre de 2021 tienen correcciones de bloqueo del inicio que informaron OEM1 y OEM2 durante el período de respin, pero nada más.
- Los problemas mencionados en el segundo punto también se incluyen en las versiones mensuales posteriores de GKI.
La revisión de octubre tiene todos los parches enviados por los OEM, pero otros parches de OEM nos afectan, ya que no se probaron específicamente con nuestros productos. ¿Es posible incluir solo nuestro parche?
No es posible. Una ruta de reinyección "por OEM" no es escalable. En cambio, el equipo de GKI analiza cada cambio que se incluye en las compilaciones de respin y prueba los cambios con todo el hardware disponible antes de crear una compilación nueva. Si el equipo de GKI determina que el problema es específico de un OEM, un dispositivo o un modelo, puede garantizar que el código que agrega el cambio solo se ejecute en el dispositivo, el modelo o el SKU afectados.
El principal beneficio de los respins unificados es que todos los dispositivos que usan la misma base de lanzamiento se benefician entre sí, en especial si los errores que descubren son genéricos y se aplican a todos los usuarios. Los errores del kernel principal que se encuentran en las pruebas del operador son un ejemplo específico de este concepto.
¿Hay situaciones en las que Google proporciona información específica sobre los parches y los problemas de los OEM para 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 de respin hasta que se comprenda el problema y se hayan recopilado todos los detalles. Esto se puede ver en el registro de cambios (mensaje de confirmación). Google no revela qué dispositivo específico afecta, pero los OEMs siempre pueden encontrar la descripción y la solución del problema en el registro de cambios.