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 trimestrales y los lanzamientos de emergencia fuera de banda. El objetivo de esta página es brindarles a los OEM un lineamiento sobre dónde obtener la GKI, así como el proceso para las 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

La GKI se lanza de forma trimestral después de la congelación de la KMI.

Validez de la compilación del GKI para los OEM

Los OEM pueden usar una GKI de Android lanzada recientemente. Los OEM pueden lanzar compilaciones certificadas por el GKI siempre que cumplan con los requisitos del kernel de asistencia a largo plazo (LTS) que se indican en el Boletín de seguridad de Android (ASB).

Versiones de GKI de 16 KB

El equipo de lanzamiento de GKI controla las versiones de GKI de 16 KB con la misma cadencia de lanzamiento trimestral, las pruebas de calificación y el proceso de repetición que las versiones de GKI de 4 KB:

• Ramas admitidas:
  • android15-6.6 (a partir de enero de 2026)
  • android16-6.12 (a partir de marzo de 2026)
  • android17-6.18 (a partir de junio de 2026)
• Paridad de compilación y certificación: Los objetos binarios de GKI de 16 KB usan la misma etiqueta de origen y el mismo ID de compilación de kernel que la versión de GKI de 4 KB correspondiente. Hasta 2027, la pestaña Compilación de lanzamiento de 16 KB de las páginas de compilaciones de lanzamiento android15-6.6, android16-6.12 y android17-6.18 proporcionará objetos binarios de lanzamiento de GKI de 16 KB no certificados. No es necesario que actualices los kernels de 4 KB y 16 KB juntos, aunque te recomendamos que lo hagas.
• Nuevas versiones on demand: Solicita nuevas versiones de GKI de 16 KB con el mismo proceso y formulario de solicitud de nueva versión que las compilaciones de 4 KB.

Lanzamientos certificados trimestrales

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 una versión base conocida del código fuente.

Cada trimestre, se selecciona una versión candidata para lanzamiento trimestral del GKI (sin certificación) después de la fecha límite de registro. Después de que se selecciona la versión candidata para lanzamiento trimestral, no se aceptarán cambios nuevos 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 las pruebas. La versión candidata para lanzamiento se somete a un control de calidad, como se describe en la sección de calificación de GKI, para verificar que las pruebas de cumplimiento se aprueben en una compilación de GSI+GKI con un dispositivo de referencia y Cuttlefish.

Figura 1: Cronograma de lanzamientos de GKI

Requisitos de GKI

Dónde obtener artefactos de compilación

Los OEM pueden obtener artefactos para todas las versiones desde 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 la GKI.

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

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

¿Es posible reproducir los objetos binarios de la 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 binario del GKI (incluido el parche de emergencia) en la base de código más reciente?

No. Los respins solo contienen los parches que se encuentran sobre los kernels certificados trimestrales que se eligieron. Estas versiones nuevas contienen todas las correcciones de errores que bloquean el lanzamiento y que informaron los OEM 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 de 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 objeto binario de noviembre de 2021 tienen correcciones que bloquean el lanzamiento informadas por OEM1 y OEM2 durante el período de nueva versión, pero nada más.
• Los problemas mencionados en la segunda viñeta también se incluyen en las versiones trimestrales posteriores de la GKI.

La nueva versió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?

Esto no es posible. Una ruta de respin para OEMs individuales no es escalable. En cambio, el equipo de GKI examina 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 verificar que el código agregado por el cambio se ejecute solo 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 versión base se benefician entre sí, especialmente si los errores que descubren son genéricos y aplicables a todos los usuarios. Los errores del kernel principal 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 respin hasta que el equipo de GKI comprenda el problema y recopile todos los detalles. Puedes ver esto 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.