En esta página, se describe cómo se lanza GKI, incluidos los lanzamientos 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 GKI de desarrollo 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.
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
Consulta las fechas de lanzamiento de septiembre de 2024 en este anuncio.
| Compilaciones mensuales certificadas de GKI | Fecha límite para hacer el registro de entrada | Fecha de preparación de la precarga de GKI | ¿Confirmaste? |
|---|---|---|---|
| Noviembre | 11 de noviembre de 2024 | 27 de noviembre de 2024 | Sí |
| Enero | 17 de enero de 2025 | 31 de enero de 2025 | Sí |
| Febrero | 14 de febrero de 2025 | 28 de febrero de 2025 | Sí |
La siguiente tabla solo se aplica a android14-6.1 y android15-6.6.
Consulta las fechas de lanzamiento de septiembre de 2024 en este anuncio.
| 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 | 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, 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 | ¿Confirmado? |
|---|---|---|---|
| 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 Cuttlefish. para asegurarse de que pasen una barra de calidad mínima.Los objetos binarios de GKI están disponibles para autoservicio desde Android IC 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. Las compilaciones semanales no se pueden usar para compilaciones de dispositivos de producción para usuarios finales.
Versiones certificadas mensuales
Las versiones mensuales de GKI contienen un boot.img probado que incluye una suscripción
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 no se aceptarán cambios 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 lanzamientos 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 de 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 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 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 un reintento de
android12-5.10-2022-09, ya debe haberse fusionado enandroid12-5.10.Debes 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 revisión por separado para cada rama de lanzamiento. 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 proporcionar una compilación y marcar una solicitud de reenvío como corregida, no debes volver a abrir la solicitud de reenvío para agregar CL adicionales. 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 tres días hábiles, la prioridad se reduce en un nivel (por ejemplo, P0 cambia a P1). Si no respondes durante dos semanas, el error se marca 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 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 | 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, 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 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í, aquí te mostramos 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 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. Los reintentos solo contienen parches que se encuentran sobre los kernels mensuales certificados que se eligieron. 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 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 descubre que el problema es específico de un OEM, un dispositivo o , el equipo de GKI puede asegurarse de que el código agregado por el cambio solo se ejecute en el dispositivo, modelo o SKU afectado.
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. Los errores principales del kernel 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 de los 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.