En este documento, se describe cómo se lanza GKI, incluidas las actualizaciones semanales, mensuales y de lanzamientos de emergencia de la banda. El objetivo de este documento es brindarles a los OEM lineamientos sobre dónde retirar el GKI, así como el proceso para salir de la banda soluciones de emergencia. 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 Kernel de Android 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 indica 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
publicado 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 lanzar Las construcciones cuentan con la certificación de GKI, siempre y cuando cumplan con los requisitos de LTS de la Boletín de seguridad de Android (ASB)
Versiones de desarrollo semanales
Las versiones se prueban con sepia. para asegurarse de que pasen una barra de calidad mínima.Los objetos binarios de GKI están disponibles para autoservicio desde ci.android.com a medida que se combinan los cambios. Las compilaciones semanales no se certificarán, aunque se pueden usar como un modelo de referencia para el desarrollo y las pruebas. No se pueden usar las compilaciones semanales compilaciones de dispositivos de producción para usuarios finales.
Versiones certificadas mensuales
Las versiones mensuales de GKI contienen un boot.img probado que incluye un
se insertó un certificado para certificar que los objetos binarios se compilaron a partir de una fuente conocida
del modelo de referencia del código.
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. Después de seleccionar el candidato mensual, nuevo los cambios no se aceptarán en el lanzamiento de ese mes. Durante la ventana cerrada solo se pueden solucionar los errores que causan fallas en las pruebas. El de versiones candidatas se somete a un control de calidad, como se describe en el documento de calificación, para garantizar que se aprueben las pruebas de cumplimiento GSI+GKI compila con un dispositivo de referencia y sepia.
Figura 1: Cronograma de lanzamiento de GKI
Proceso de relanzamiento de emergencias
Un relanzamiento se refiere al proceso de reubicación, recompilación, prueba y renovar la certificación de un objeto binario después de una versión pública del kernel de GKI. Puedes solicitar que se vuelva a configurar un objeto binario certificado para cualquiera de las siguientes acciones: 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 para un máximo de 6 meses después del lanzamiento de la rama. Después del límite de 6 meses, debes solicitar un nuevo cambio para aplicar parches de seguridad a una rama.
Lineamientos para las solicitudes de relanzamiento
Antes de solicitar una nueva operación, ten en cuenta los siguientes lineamientos:
Las reposiciones solo se permiten en las ramas de la versión después del lanzamiento público inicial de una compilación mensual lanzamiento.
Las solicitudes de relanzamiento solo se aceptan para una rama de lanzamiento determinada de un como máximo seis meses después del lanzamiento público inicial. Después de seis meses, las ramas son elegibles para repinar solo para los parches de seguridad citados en un Boletín de seguridad de Android
Cuando se cumplen los requisitos de LTS , definido por el Boletín de seguridad de Android (ASB) hace que la rama no cumpla con los requisitos, significa que la rama quedó obsoleta. Volver a fijar solicitudes para ramas obsoletas. La fecha de baja de un GKI determinado de la versión se incluye en las notas de compilación de la versión de GKI mensuales Lanzamientos Para la planificación futura, los requisitos de LTS se actualizan en mayo y noviembre anualmente. Por ejemplo,
android12-5.10-2023-07(5.10.177) no es compatible con las respins después del 1 de mayo de 2024, debido a queandroid12-5.10-2023-07(5.10.177) no cumple con los requisitos de LTS de ASB-2024-05.Las reposiciones solo se aplican en el caso de correcciones de errores urgentes, actualizaciones de la lista de símbolos o para aplicar un parche y arreglar una función existente.
Todos los parches que se incluirán en la rama de la versión mensual ya deben combinarse la rama principal de desarrollo de GKI. Por ejemplo, si se requiere un parche para una respin de
android12-5.10-2022-09, ya debe estar combinado conandroid12-5.10Debes seleccionar los parches de la rama principal de desarrollo de GKI y sube 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 P0 y P1 solicitudes, también debe justificar la urgencia. En la siguiente tabla, se proporciona un asignación de prioridad de errores y 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, se necesita una relanzamiento de
android12-5.10-2022-08yandroid12-5.10-2022-09, debes crear dos solicitudes de relanzamiento.Después de que se proporciona una compilación y se marca la solicitud de relanzamiento como corregida, puedes no deberías volver a abrir la solicitud de relanzamiento para agregar más CL. Debe enviar un nuevo volver a fijar si hay parches adicionales que deban combinarse.
Para cada CL en consideración, agrega las siguientes etiquetas.
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 para volver a fijar requiere tu respuesta, y no respondes en un plazo tres días hábiles, la prioridad se reducirá en un nivel (por ejemplo, P0 cambia a P1). Si no respondes durante dos semanas, el error marcado como No se corregirá (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:
- Complete 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 que se producen en la solicitud para volver a fijar.
(el solicitante), el equipo de GKI y las personas específicas que agregues al
en la lista de Cc del error.
- Si ya tienes una corrección, la solicitud debería apuntar al parche. del AOSP para que Google pueda revisarlo. Si enviar el parche no es posible, el parche debe adjuntarse como un archivo de texto a la solicitud.
- Si no tienes una corrección, la solicitud debe contener tanto información como sea posible, incluido el número de versión de kernel y los registros, para que Google puede ayudar a depurar el problema.
- El equipo de GKI de Google revisa la solicitud y la aprueba o vuelve a asignarla a 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) cambio. La revisión comienza en el período de ESRT. El equipo de GKI combina, compila y prueba de regresión y certifica el cambio.
- El objeto binario se lanza para ci.android.com El Cuando finaliza el plazo de ESRT, 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 el 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 | Notas |
|---|---|---|
| Semanal | Prueba de Cuttlefish
|
|
| Mensual (certificado) | Prueba de Cuttlefish
|
|
| Vuelve a activar (certificado) | Prueba de Cuttlefish
|
|
Dónde obtener artefactos de compilación
Se pueden obtener los artefactos de todas las versiones ci.android.com
Puedes encontrar más información sobre la CI, incluida la prueba resultados de la Integración continua de Android o un panel dinámico más robusto.
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 y cuando La compilación de GKI lanzada (en la que se solicita la relanzamiento) cumple con la 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 lo siguiente:
:
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 además de los certificados mensuales certificados. kernels que se hayan elegido. Estas reposiciones contienen todos los errores que bloquean el lanzamiento correcciones informadas hasta un momento determinado por los OEM mediante la base correspondiente lanzamiento mensual. 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 un bloqueo del lanzamiento. correcciones informadas por OEM1 y OEM2 durante la ventana de relanzamiento, pero no más.
- Los problemas mencionados en el segundo punto también se incluyen en las versiones posteriores de GKI. lanzamientos mensuales.
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. Una estrategia "por OEM" la ruta de relanzamiento no es escalable. En cambio, el equipo de GKI analiza cada cambio que se redefine compila y prueba los cambios con todo el hardware disponible antes de crear un nuevo compilar. Si el equipo de GKI descubre que el problema es específico de un OEM, dispositivo o modelo, el equipo de GKI puede asegurarse de que el código agregado por el cambio solo se ejecute en el dispositivo, modelo o SKU afectados.
El principal beneficio de las respins unificadas es que todos los dispositivos que usan la misma base de versiones se benefician mutuamente, en especial si que descubran son genéricos y aplicables a todos los usuarios. Se encontraron errores principales en el kernel. en las pruebas de proveedores es 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 recopilaron 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 y la solución del problema en el registro de cambios.