Este documento describe cómo se publica GKI, incluidos los lanzamientos de emergencia semanales, mensuales y fuera de banda. El objetivo de este documento es brindar a los OEM una guía sobre dónde recoger el GKI, así como el proceso para reparaciones de emergencia fuera de banda. Los OEM también pueden utilizar la guía de 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 lanzamiento de GKI
GKI se publica con una cadencia mensual posterior a la congelación de KMI.
Lanzamiento de Android 13 y 14 GKI
La siguiente tabla solo se aplica a android13-5.10 , android13-5.15 y android14-6.1 .
| Construcciones certificadas mensuales de GKI | Fecha límite de check-in | Fecha de preparación de la precarga de GKI | ¿Confirmado? |
|---|---|---|---|
| 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í |
| Puede | 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í |
Lanzamiento de Android 12 GKI
Después de mayo de 2023, las versiones de android12-5.10 GKI tienen una cadencia de 2 meses y se publican a mediados de mes. La siguiente tabla es aplicable solo a android12-5.10 .
| Construcciones certificadas mensuales de GKI | Fecha límite de check-in | 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í |
Validez de compilación de GKI para OEM
Los OEM pueden utilizar un GKI de Android lanzado recientemente. Los OEM pueden realizar lanzamientos con compilaciones certificadas por GKI siempre que cumplan con los requisitos de LTS en el Boletín de seguridad de Android (ASB).
Lanzamientos de desarrollo semanales
Los lanzamientos se prueban con sepia para garantizar que pasan una barra de calidad mínima .Los binarios de GKI están disponibles para autoservicio en ci.android.com a medida que se fusionan los cambios. Las compilaciones semanales no se certificarán, aunque se pueden utilizar como base para el desarrollo y las pruebas. Las compilaciones semanales no se pueden utilizar para compilaciones de dispositivos de producción para usuarios finales.
Lanzamientos certificados mensuales
Las versiones mensuales de GKI contienen un boot.img probado que incluye un certificado insertado por Google para dar fe de que los archivos binarios se crearon a partir de una base de código fuente conocida.
Cada mes, se selecciona un candidato de lanzamiento mensual de GKI (no certificado) después de la fecha límite de registro, que suele ser la segunda compilación semanal de ese mes. Una vez seleccionada la versión candidata mensual, no se aceptarán nuevos cambios en la versión de ese mes. Durante el período de ventana cerrada, solo se pueden corregir errores que causan fallas en las pruebas. El candidato de lanzamiento 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 pasen en la compilación GSI+GKI con un dispositivo de referencia y también con sepia.
Figura 1. Cronograma de lanzamiento de GKI
Proceso de respin de emergencia
Un respin se refiere al proceso de volver a fusionar, reconstruir, volver a probar y recertificar un binario después de un lanzamiento público del kernel GKI . Puedes solicitar un respin de un binario certificado por cualquiera de las siguientes circunstancias:
- Para actualizar una lista de símbolos.
- Para aplicar una solución a un error, incluidos los errores encontrados durante la aprobación del laboratorio del operador.
- Para agregar un gancho de proveedor .
- Aplicar un parche a una característica existente.
- Aplicar un parche de seguridad (después de 6 meses).
Los parches de seguridad se fusionan automáticamente en una rama de lanzamiento hasta 6 meses después del lanzamiento de la rama. Después del límite de 6 meses, debes solicitar un nuevo giro para aplicar parches de seguridad a una sucursal.
Antes de solicitar un nuevo giro, tenga en cuenta las siguientes pautas:
Los dobles giros solo se permiten en las ramas de lanzamiento después de que se haya lanzado un lanzamiento público inicial de una compilación mensual .
Las solicitudes de respin se aceptan solo 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 sucursales son elegibles para volver a girar solo para los parches de seguridad citados en un Boletín de seguridad de Android .
Cuando los requisitos LTS , definidos por el Boletín de seguridad de Android (ASB), hacen que la rama no cumpla, la rama queda obsoleta. No se aceptan solicitudes de respin para ramas obsoletas. La fecha de desuso para una determinada rama de lanzamiento de GKI se incluye en las notas de compilación de la versión mensual de GKI 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 dobles giros después del 1 de mayo de 2024, porque la ramaandroid12-5.10-2023-07(5.10.177) no cumple con la Requisitos LTS de ASB-2024-05.Los dobles giros solo se aplican para correcciones de errores urgentes, actualizaciones de la lista de símbolos o para aplicar un parche para corregir una función existente.
Todos los parches que van a la rama de lanzamiento mensual ya deben estar fusionados en la rama de desarrollo principal de GKI. Por ejemplo, si se requiere un parche para volver a girar
android12-5.10-2022-09, ya debe estar fusionado enandroid12-5.10.Debe seleccionar parches de la rama principal de desarrollo de GKI y cargar el parche en la rama de lanzamiento mensual.
En la solicitud de respin, debes asignar una prioridad (urgencia) a la solicitud. Esta prioridad ayuda al equipo de GKI a ayudar mejor a los socios de manera oportuna. Para solicitudes críticas o urgentes, marque la prioridad como P0 . Para solicitudes P0 y P1, también deberá justificar la urgencia. La siguiente tabla proporciona una asignación de prioridad de errores y tiempo de resolución (ESRT):
Prioridad ESRT P0 2 días hábiles P1 5 días hábiles P2 10 días hábiles P3 15 días hábiles
Debes enviar una solicitud de doble giro por separado por rama de lanzamiento. Por ejemplo, si se necesita un nuevo giro tanto para
android12-5.10-2022-08como paraandroid12-5.10-2022-09, debes crear dos solicitudes de nuevo giro.Después de proporcionar una compilación y una solicitud de doble giro se marca como arreglada, no debes volver a abrir la solicitud de nuevo giro para agregar CL adicionales. Debes enviar una nueva solicitud de giro doble si hay parches adicionales que deben fusionarse.
Para cada CL bajo consideración, agregue las siguientes etiquetas. Sin esta información, el progreso de la solicitud de doble giro se bloquea.
-
Bug: el ID del error debe agregarse al mensaje de confirmación para cada CL. -
Change-Id: debe ser idéntico al Change-Id del cambio de rama base.
-
Si una solicitud de repetición de giro requiere su respuesta y usted no responde dentro de los tres días hábiles, la prioridad se reduce en un nivel (por ejemplo, P0 se reduce a P1 ). Si no responde durante dos semanas, el error se marca como No se solucionará (obsoleto) .
Enviar una solicitud de doble giro
El siguiente diagrama muestra el proceso de doble giro. El proceso comienza cuando el socio OEM (usted) envía la solicitud de repetición de giro.
Figura 2. El proceso de volver a girar
Para ingresar al proceso de respin:
- Complete el formulario de solicitud de GKI Respin . y comuníquese con su administrador técnico de cuentas de Google de inmediato. Este formulario crea un error de solicitud de respin de GKI. Los errores de solicitud de respin son visibles para usted (el solicitante), el equipo de GKI y las personas específicas que agrega a la lista de CC del error.
- Si ya tiene una solución, la solicitud debe apuntar al envío del parche en AOSP para que Google pueda revisarla. Si no es posible enviar el parche, el parche debe adjuntarse como un archivo de texto a la solicitud.
- Si no tiene una solución, la solicitud debe contener tanta información como sea posible, incluido el número de versión del kernel y los registros, para que Google pueda ayudar a depurar el problema.
- El equipo de Google GKI revisa la solicitud y la aprueba o se la asigna nuevamente si se necesita más información.
- Una vez que se acuerda una solución, el código del equipo GKI de Google revisa (CR+2) el cambio. La revisión comienza el período de tiempo de ESRT. El equipo de GKI fusiona, construye, prueba la regresión y certifica el cambio.
- El binario se publica en ci.android.com . El plazo de ESRT finaliza y el equipo de Google GKI marca la solicitud como fija 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 Imagen genérica del kernel (GKI) .
Cualificaciones GKI
| Tipos de compilaciones de GKI | Aplicación de la calidad | Notas |
|---|---|---|
| Semanalmente | Prueba de sepia
|
|
| Mensual (certificado) | Prueba de sepia
| |
| Respins (certificados) | Prueba de sepia
|
|
Dónde obtener artefactos de construcción
Los artefactos para todas las versiones se pueden obtener en ci.android.com .
Puede encontrar más información sobre el CI, incluidos los resultados de las pruebas, en el panel de integración continua de Android .
Preguntas frecuentes
¿Es posible construir un nuevo binario GKI basado en un GKI ya lanzado?
Sí, esto se conoce como respin. El proceso de repetición de giro se admite siempre que la compilación GKI publicada (en la que se solicita la repetición de giro) cumpla con los requisitos de LTS en el Boletín de seguridad de Android (ASB).
¿Es posible reproducir binarios de GKI?
Sí, consulte el ejemplo siguiente.
GKI 2.0
5.10 kernel prebuilts from build 7364300
https://ci.android.com/builds/submitted/7364300/kernel_aarch64/latest
Para reproducir el ejemplo, descargue manifest_$id.xml y ejecute 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
Puede recuperar su copia del artefacto GKI desde out/.../dist .
¿Se ha creado el binario GKI (incluido el parche de giro de emergencia) en la base de código más reciente?
No. Los respins solo contienen parches que se encuentran además de los núcleos certificados mensuales que se han elegido. Estos dobles giros contienen todas las correcciones de errores de bloqueo de lanzamiento reportadas hasta un momento dado por los OEM utilizando la versión mensual base correspondiente. Vea el siguiente ejemplo de cómo ocurre este tipo de escenario.
- OEM1 y OEM2 deciden utilizar la versión binaria GKI a partir de noviembre de 2021.
- OEM1 y OEM2 encuentran problemas que requieren parches para obtener soporte. Estos parches pueden ser diferentes o iguales.
- Los dobles giros superiores al binario de noviembre de 2021 tienen correcciones de bloqueo de lanzamiento informadas tanto por OEM1 como por OEM2 durante la ventana de nuevos giros, pero nada más.
- Los problemas mencionados en el segundo punto también se incluyen en las versiones mensuales posteriores de GKI.
El respin de octubre tiene todos los parches enviados por OEM, pero otros parches OEM nos afectan porque no han sido probados específicamente con nuestros productos. ¿Es posible incluir sólo nuestro parche?
Esto no es posible. Actualmente, una ruta de doble giro "por OEM" no es escalable. En cambio, el equipo de GKI examina cada cambio que se realiza en las compilaciones de respin y prueba los cambios con todo el hardware disponible antes de crear una nueva compilación. Si el equipo de GKI descubre que el problema es específico de un OEM/dispositivo/modelo, el equipo de GKI puede garantizar que el código agregado por el cambio solo se ejecute en el dispositivo/modelo/SKU afectado.
El principal beneficio de los dobles giros unificados es que todos los dispositivos que utilizan la misma base de lanzamiento se benefician entre sí, especialmente si los errores que descubren son genéricos y aplicables a todos los usuarios. Los errores centrales del kernel encontrados en las pruebas de operadores son un ejemplo específico de este concepto.
¿Existen situaciones en las que Google proporciona información específica sobre parches OEM y escenarios 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 configuración de respin hasta que se comprenda el problema y se hayan recopilado 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 del problema y la solución en el registro de cambios.
,Este documento describe cómo se publica GKI, incluidos los lanzamientos de emergencia semanales, mensuales y fuera de banda. El objetivo de este documento es brindar a los OEM una guía sobre dónde recoger el GKI, así como el proceso para reparaciones de emergencia fuera de banda. Los OEM también pueden utilizar la guía de 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 lanzamiento de GKI
GKI se publica con una cadencia mensual posterior a la congelación de KMI.
Lanzamiento de Android 13 y 14 GKI
La siguiente tabla solo se aplica a android13-5.10 , android13-5.15 y android14-6.1 .
| Construcciones certificadas mensuales de GKI | Fecha límite de check-in | Fecha de preparación de la precarga de GKI | ¿Confirmado? |
|---|---|---|---|
| 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í |
| Puede | 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í |
Lanzamiento de Android 12 GKI
Después de mayo de 2023, las versiones de android12-5.10 GKI tienen una cadencia de 2 meses y se publican a mediados de mes. La siguiente tabla es aplicable solo a android12-5.10 .
| Construcciones certificadas mensuales de GKI | Fecha límite de check-in | 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í |
Validez de compilación de GKI para OEM
Los OEM pueden utilizar un GKI de Android lanzado recientemente. Los OEM pueden realizar lanzamientos con compilaciones certificadas por GKI siempre que cumplan con los requisitos de LTS en el Boletín de seguridad de Android (ASB).
Lanzamientos de desarrollo semanales
Los lanzamientos se prueban con sepia para garantizar que pasan una barra de calidad mínima .Los binarios de GKI están disponibles para autoservicio en ci.android.com a medida que se fusionan los cambios. Las compilaciones semanales no se certificarán, aunque se pueden utilizar como base para el desarrollo y las pruebas. Las compilaciones semanales no se pueden utilizar para compilaciones de dispositivos de producción para usuarios finales.
Lanzamientos certificados mensuales
Las versiones mensuales de GKI contienen un boot.img probado que incluye un certificado insertado por Google para dar fe de que los archivos binarios se crearon a partir de una base de código fuente conocida.
Cada mes, se selecciona un candidato de lanzamiento mensual de GKI (no certificado) después de la fecha límite de registro, que suele ser la segunda compilación semanal de ese mes. Una vez seleccionada la versión candidata mensual, no se aceptarán nuevos cambios en la versión de ese mes. Durante el período de ventana cerrada, solo se pueden corregir errores que causan fallas en las pruebas. El candidato de lanzamiento 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 pasen en la compilación GSI+GKI con un dispositivo de referencia y también con sepia.
Figura 1. Cronograma de lanzamiento de GKI
Proceso de respin de emergencia
Un respin se refiere al proceso de volver a fusionar, reconstruir, volver a probar y recertificar un binario después de un lanzamiento público del kernel GKI . Puedes solicitar un respin de un binario certificado por cualquiera de las siguientes circunstancias:
- Para actualizar una lista de símbolos.
- Para aplicar una solución a un error, incluidos los errores encontrados durante la aprobación del laboratorio del operador.
- Para agregar un gancho de proveedor .
- Aplicar un parche a una característica existente.
- Aplicar un parche de seguridad (después de 6 meses).
Los parches de seguridad se fusionan automáticamente en una rama de lanzamiento hasta 6 meses después del lanzamiento de la rama. Después del límite de 6 meses, debes solicitar un nuevo giro para aplicar parches de seguridad a una sucursal.
Antes de solicitar un nuevo giro, tenga en cuenta las siguientes pautas:
Los dobles giros solo se permiten en las ramas de lanzamiento después de que se haya lanzado un lanzamiento público inicial de una compilación mensual .
Las solicitudes de respin se aceptan solo 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 sucursales son elegibles para volver a girar solo para los parches de seguridad citados en un Boletín de seguridad de Android .
Cuando los requisitos LTS , definidos por el Boletín de seguridad de Android (ASB), hacen que la rama no cumpla, la rama queda obsoleta. No se aceptan solicitudes de respin para ramas obsoletas. La fecha de desuso para una determinada rama de lanzamiento de GKI se incluye en las notas de compilación de la versión mensual de GKI 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 dobles giros después del 1 de mayo de 2024, porque la ramaandroid12-5.10-2023-07(5.10.177) no cumple con la Requisitos LTS de ASB-2024-05.Los dobles giros solo se aplican para correcciones de errores urgentes, actualizaciones de la lista de símbolos o para aplicar un parche para corregir una función existente.
Todos los parches que van a la rama de lanzamiento mensual ya deben estar fusionados en la rama de desarrollo principal de GKI. Por ejemplo, si se requiere un parche para volver a girar
android12-5.10-2022-09, ya debe estar fusionado enandroid12-5.10.Debe seleccionar parches de la rama principal de desarrollo de GKI y cargar el parche en la rama de lanzamiento mensual.
En la solicitud de respin, debes asignar una prioridad (urgencia) a la solicitud. Esta prioridad ayuda al equipo de GKI a ayudar mejor a los socios de manera oportuna. Para solicitudes críticas o urgentes, marque la prioridad como P0 . Para solicitudes P0 y P1, también deberá justificar la urgencia. La siguiente tabla proporciona una asignación de prioridad de errores y tiempo de resolución (ESRT):
Prioridad ESRT P0 2 días hábiles P1 5 días hábiles P2 10 días hábiles P3 15 días hábiles
Debes enviar una solicitud de doble giro por separado por rama de lanzamiento. Por ejemplo, si se necesita un nuevo giro tanto para
android12-5.10-2022-08como paraandroid12-5.10-2022-09, debes crear dos solicitudes de nuevo giro.Después de proporcionar una compilación y una solicitud de doble giro se marca como arreglada, no debes volver a abrir la solicitud de nuevo giro para agregar CL adicionales. Debes enviar una nueva solicitud de giro doble si hay parches adicionales que deben fusionarse.
Para cada CL bajo consideración, agregue las siguientes etiquetas. Sin esta información, el progreso de la solicitud de doble giro se bloquea.
-
Bug: el ID del error debe agregarse al mensaje de confirmación para cada CL. -
Change-Id: debe ser idéntico al Change-Id del cambio de rama base.
-
Si una solicitud de repetición de giro requiere su respuesta y usted no responde dentro de los tres días hábiles, la prioridad se reduce en un nivel (por ejemplo, P0 se reduce a P1 ). Si no responde durante dos semanas, el error se marca como No se solucionará (obsoleto) .
Enviar una solicitud de doble giro
El siguiente diagrama muestra el proceso de doble giro. El proceso comienza cuando el socio OEM (usted) envía la solicitud de repetición de giro.
Figura 2. El proceso de volver a girar
Para ingresar al proceso de respin:
- Complete el formulario de solicitud de GKI Respin . y comuníquese con su administrador técnico de cuentas de Google de inmediato. Este formulario crea un error de solicitud de respin de GKI. Los errores de solicitud de respin son visibles para usted (el solicitante), el equipo de GKI y las personas específicas que agrega a la lista de CC del error.
- Si ya tiene una solución, la solicitud debe apuntar al envío del parche en AOSP para que Google pueda revisarla. Si no es posible enviar el parche, el parche debe adjuntarse como un archivo de texto a la solicitud.
- Si no tiene una solución, la solicitud debe contener tanta información como sea posible, incluido el número de versión del kernel y los registros, para que Google pueda ayudar a depurar el problema.
- El equipo de Google GKI revisa la solicitud y la aprueba o se la asigna nuevamente si se necesita más información.
- Una vez que se acuerda una solución, el código del equipo GKI de Google revisa (CR+2) el cambio. La revisión comienza el período de tiempo de ESRT. El equipo de GKI fusiona, construye, prueba la regresión y certifica el cambio.
- El binario se publica en ci.android.com . El plazo de ESRT finaliza y el equipo de Google GKI marca la solicitud como fija 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 Imagen genérica del kernel (GKI) .
Cualificaciones GKI
| Tipos de compilaciones de GKI | Aplicación de la calidad | Notas |
|---|---|---|
| Semanalmente | Prueba de sepia
|
|
| Mensual (certificado) | Prueba de sepia
| |
| Respins (certificados) | Prueba de sepia
|
|
Dónde obtener artefactos de construcción
Los artefactos para todas las versiones se pueden obtener en ci.android.com .
Puede encontrar más información sobre el CI, incluidos los resultados de las pruebas, en el panel de integración continua de Android .
Preguntas frecuentes
¿Es posible construir un nuevo binario GKI basado en un GKI ya lanzado?
Sí, esto se conoce como respin. El proceso de repetición de giro se admite siempre que la compilación GKI publicada (en la que se solicita la repetición de giro) cumpla con los requisitos de LTS en el Boletín de seguridad de Android (ASB).
¿Es posible reproducir binarios de GKI?
Sí, consulte el ejemplo siguiente.
GKI 2.0
5.10 kernel prebuilts from build 7364300
https://ci.android.com/builds/submitted/7364300/kernel_aarch64/latest
Para reproducir el ejemplo, descargue manifest_$id.xml y ejecute 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
Puede recuperar su copia del artefacto GKI desde out/.../dist .
¿Se ha creado el binario GKI (incluido el parche de giro de emergencia) en la base de código más reciente?
No. Los respins solo contienen parches que se encuentran además de los núcleos certificados mensuales que se han elegido. Estos dobles giros contienen todas las correcciones de errores de bloqueo de lanzamiento reportadas hasta un momento dado por los OEM utilizando la versión mensual base correspondiente. Vea el siguiente ejemplo de cómo ocurre este tipo de escenario.
- OEM1 y OEM2 deciden utilizar la versión binaria GKI a partir de noviembre de 2021.
- OEM1 y OEM2 encuentran problemas que requieren parches para obtener soporte. Estos parches pueden ser diferentes o iguales.
- Los dobles giros superiores al binario de noviembre de 2021 tienen correcciones de bloqueo de lanzamiento informadas tanto por OEM1 como por OEM2 durante la ventana de nuevos giros, pero nada más.
- Los problemas mencionados en el segundo punto también se incluyen en las versiones mensuales posteriores de GKI.
El respin de octubre tiene todos los parches enviados por OEM, pero otros parches OEM nos afectan porque no han sido probados específicamente con nuestros productos. ¿Es posible incluir sólo nuestro parche?
Esto no es posible. Actualmente, una ruta de doble giro "por OEM" no es escalable. En cambio, el equipo de GKI examina cada cambio que se realiza en las compilaciones de respin y prueba los cambios con todo el hardware disponible antes de crear una nueva compilación. Si el equipo de GKI descubre que el problema es específico de un OEM/dispositivo/modelo, el equipo de GKI puede garantizar que el código agregado por el cambio solo se ejecute en el dispositivo/modelo/SKU afectado.
El principal beneficio de los dobles giros unificados es que todos los dispositivos que utilizan la misma base de lanzamiento se benefician entre sí, especialmente si los errores que descubren son genéricos y aplicables a todos los usuarios. Los errores centrales del kernel encontrados en las pruebas de operadores son un ejemplo específico de este concepto.
¿Existen situaciones en las que Google proporciona información específica sobre parches OEM y escenarios 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 configuración de respin hasta que se comprenda el problema y se hayan recopilado 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 del problema y la solución en el registro de cambios.