Proceso de lanzamiento de imágenes genéricas de kernel (GKI)

En esta página, se describe cómo se lanza el GKI, incluidos los lanzamientos semanales, trimestrales y de emergencia fuera de banda. El objetivo de este documento es brindar a los OEM una guía sobre dónde obtener el GKI y el proceso para realizar correcciones de emergencia fuera de banda. Los OEM también pueden usar el desarrollo de GKI para obtener más información sobre cómo pueden trabajar con el equipo del kernel de Android para optimizar el kernel de GKI para sus productos.

Cadencia de lanzamientos de GKI

El GKI se lanza trimestralmente después de la congelación del KMI.

Validez de la compilación del GKI para los OEM

Los OEM pueden usar un GKI de Android lanzado recientemente. Los OEM pueden lanzar compilaciones certificadas por el GKI siempre que cumplan con los requisitos de LTS que se indican en el Boletín de seguridad de Android (ASB).

Lanzamientos semanales de desarrollo

Los objetos binarios del 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 referencia para el desarrollo y las pruebas. Las compilaciones semanales no se pueden usar para compilar dispositivos de producción para usuarios finales.

Lanzamientos trimestrales certificados

Las versiones trimestrales del GKI contienen un boot.img probado que incluye un certificado insertado por Google para certificar que los archivos binarios se compilaron a partir de un código fuente de referencia conocido.

Cada trimestre, se selecciona una versión candidata trimestral del GKI (sin certificación) 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 trimestral, no se aceptarán cambios nuevos en la versión de ese mes. Durante el período de cierre, solo se pueden abordar las correcciones de errores que provocan fallas en las pruebas. El candidato a lanzamiento se somete a un control de calidad, como se describe en la sección de calificación del GKI, para garantizar que las pruebas de cumplimiento se aprueben en la compilación de GSI + GKI con un dispositivo de referencia y con Cuttlefish.

Figura 1: Cronograma de lanzamientos de GKI

Proceso de reenvío de emergencia

Un relanzamiento se refiere al proceso de volver a combinar, compilar, probar y certificar un archivo binario después de un lanzamiento público del kernel de GKI. Puedes solicitar un respin de un archivo binario certificado en cualquiera de las siguientes circunstancias:

• Actualiza una lista de símbolos.
• Aplicar una corrección a un error, incluidos los errores que se encuentran durante la aprobación del lab de la empresa de telefonía
• Para agregar un enlace del proveedor
• Es para 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 lanzamiento hasta 6 meses después del lanzamiento de la rama. Después de ese período, debes solicitar una nueva versión para aplicar parches de seguridad a una rama.

Lineamientos para las solicitudes de reenvío

Antes de solicitar un respin, ten en cuenta los siguientes lineamientos:

• Los reenvíos solo se permiten en las ramas de versiones después de que se lanza una versión pública inicial de una compilación trimestral.

• Las solicitudes de reenvío solo se aceptan para una rama de versión determinada durante un máximo de seis meses después del lanzamiento público inicial. Después de seis meses, las ramas solo son aptas para reenvío si se trata de 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, esta se considera obsoleta. No se aceptan solicitudes de reenvío para ramas obsoletas. La fecha de baja de una rama de versión de GKI determinada se incluye en las notas trimestrales de la compilación de lanzamiento de GKI en Lanzamientos. Para la planificación futura, los requisitos de LTS se actualizan en mayo y noviembre de cada año. Por ejemplo, la rama android12-5.10-2023-07 (5.10.177) no se admite para las nuevas versiones después del 1 de mayo de 2024, ya que la rama android12-5.10-2023-07 (5.10.177) no cumple con los requisitos de LTS de ASB-2024-05.

• Los reenvíos solo se aplican a las correcciones de errores urgentes, las actualizaciones de listas de símbolos o la aplicación de un parche para corregir una función existente.

• Todos los parches que se incluyan en la rama de la versión trimestral ya deben haberse combinado en la rama principal de desarrollo del GKI. Por ejemplo, si se requiere un parche para una nueva versión de android12-5.10-2022-09, ya debe haberse combinado en android12-5.10.

• Debes seleccionar los mejores elementos de los parches de la rama de desarrollo principal del GKI y subir el parche a la rama de la versión trimestral.

• En la solicitud de reenvío, debes asignar una prioridad (urgencia) a la solicitud. Esta prioridad ayuda al equipo del GKI a brindar asistencia a los socios de manera oportuna. Para las solicitudes urgentes o críticas, marca la prioridad como P0. En el caso de las solicitudes de prioridad 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 estimado (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 respin por separado para cada rama de lanzamiento. Por ejemplo, si se necesita una nueva versión para android12-5.10-2022-08 y android12-5.10-2022-09, debes crear dos solicitudes de nueva versión.

• Después de que se proporcione una compilación y se marque una solicitud de respin como corregida, no debes volver a abrir la solicitud de respin para agregar CL adicionales. Si hay parches adicionales que se deben combinar, debes enviar una nueva solicitud de reenvío.

• 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 Change-Id del cambio de la rama base.

• Si una solicitud de reenvío 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 en dos semanas, el error se marcará como No se corregirá (obsoleto).

Envía una solicitud de respin

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 versión.

Figura 2: El proceso de respin

Para iniciar el proceso de reenvío, haz lo siguiente:

1. Completa el formulario de solicitud de reenvío de GKI y comunícate de inmediato con tu administrador técnico de cuentas de Google. Este formulario crea un error de solicitud de reenvío de GKI. Los errores de solicitud de reenvío son visibles para ti (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 AOSP para que Google pueda revisarlo. Si no es posible enviar el parche, este debe adjuntarse 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 los registros y el número de versión del kernel, para que Google pueda ayudarte a depurar el problema.
2. El equipo del GKI de Google revisa la solicitud y la aprueba o te la reasigna si se necesita más información.
3. Después de acordar una corrección, el equipo de GKI de Google realiza una revisión de código (CR+2) del cambio. La revisión inicia el período del ESRT. El equipo del GKI combina, compila, prueba la regresión y certifica el cambio.
4. El binario se lanza en ci.android.com. Finaliza el período de ESRT, 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 relanzamiento también se publicará en la página de compilaciones de lanzamiento de la imagen genérica de kernel (GKI).

Calificaciones de GKI

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 del GKI.

¿Es posible compilar un nuevo binario de GKI basado en una GKI ya lanzada?

Sí, esto se conoce como respin. El proceso de reenvío se admite siempre que la compilación de GKI lanzada (en la que se solicita el reenvío) cumpla con los requisitos de LTS que se indican en el Boletín de seguridad de Android (ASB).

¿Es posible reproducir los archivos binarios del GKI?

Sí, aquí tienes 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/manifest
mv manifest_7364300.xml .repo/manifests
repo init -m manifest_7364300.xml --depth=1
repo sync
# build the GKI images
# You may want to use LTO=thin to build faster for development
BUILD_CONFIG=common/build.config.gki.aarch64 build/build.sh
# (optional) build virtual platform modules
BUILD_CONFIG=common-modules/virtual-device/build.config.virtual_device.aarch64 build/build.sh

Puedes recuperar tu copia del artefacto de GKI desde out/.../dist.

¿Se compiló el objeto binario del GKI (incluido el parche de emergencia) en la base de código más reciente?

No. Los respins solo contienen parches que se encuentran sobre los kernels certificados trimestrales que se eligieron. Estas nuevas versiones contienen todas las correcciones de errores que impiden el lanzamiento y que los OEM informaron hasta un momento determinado con la versión trimestral base correspondiente. Consulta el siguiente ejemplo de cómo se produce este tipo de situación.

• OEM1 y OEM2 deciden usar la versión binaria del GKI de noviembre de 2021.
• OEM1 y OEM2 encuentran problemas que requieren parches para la asistencia. Estos parches pueden ser diferentes o iguales.
• Las nuevas versiones sobre el binario de noviembre de 2021 tienen correcciones de bloqueo de lanzamiento que informaron OEM1 y OEM2 durante el período de nueva versión, pero nada más.
• Los problemas mencionados en el segundo punto también se incluyen en las versiones trimestrales posteriores del GKI.

La nueva versión de octubre incluye todos los parches enviados por los OEM, pero otros parches de OEM nos afectan porque no se probaron específicamente con nuestros productos. ¿Es posible incluir solo nuestro parche?

Esto no es posible. Una ruta de reenvío "por OEM" no es escalable. En cambio, el equipo del GKI analiza cada cambio que se incluye en las compilaciones de reenvío y prueba los cambios con todo el hardware disponible antes de crear una nueva compilación. Si el equipo del GKI determina que el problema es específico de un OEM, un dispositivo o un modelo, puede asegurarse de que el código agregado por el cambio solo se ejecute en el dispositivo, el modelo o el SKU afectados.

El principal beneficio de las nuevas versiones unificadas 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 aplicables a todos los usuarios. Los errores del kernel principales que se encuentran en las pruebas de operadores son un ejemplo específico de este concepto.

¿Hay situaciones en las que Google proporciona información específica sobre parches de 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 reenvío 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 se ve afectado, pero los OEM siempre pueden encontrar la descripción del problema y la solución en el registro de cambios.