Núcleos comunes de Android

Los kernels comunes de AOSP (también conocidos como kernels comunes de Android o ACK ) son posteriores a los kernels de kernel.org e incluyen parches de interés para la comunidad de Android que no se han fusionado con los kernels principales o con soporte a largo plazo (LTS). Estos parches pueden incluir:

• Backports y selecciones selectivas de la funcionalidad upstream necesaria para las características de Android
• Funciones listas para dispositivos Android pero aún en desarrollo (por ejemplo, optimizaciones de ubicación de tareas de Energy Aware Scheduler).
• Características de proveedores/OEM que son útiles para otros socios del ecosistema (por ejemplo, sdcardfs).

android-mainline es la rama de desarrollo principal para las funciones de Android. La línea principal de Linux se fusiona con android-mainline cada vez que Linus Torvalds publica una versión o una versión candidata. Antes de 2019, los núcleos comunes de Android se construyeron mediante la clonación del núcleo LTS declarado recientemente y la adición de parches específicos de Android. Este proceso cambió en 2019 para ramificar el nuevo kernel común de Android desde android-mainline . Este nuevo modelo evita el esfuerzo significativo de reenviar el puerto y probar los parches de Android al lograr el mismo resultado de forma incremental. android-mainline se somete a importantes pruebas continuas, este modelo garantiza un kernel de alta calidad desde el día de su publicación.

Cuando se declara un nuevo LTS en sentido ascendente, el kernel común correspondiente se bifurca desde android-mainline . Esto permite a los socios comenzar un proyecto antes de la declaración de la versión LTS, al fusionarse desde android-mainline . Una vez que se crea la nueva rama común del kernel, los socios pueden cambiar sin problemas la fuente de fusión a la nueva rama.

Otras ramas comunes del kernel reciben fusiones periódicas de su kernel LTS asociado. Estas fusiones normalmente se realizan inmediatamente después de que se publica el lanzamiento de LTS. Por ejemplo, cuando se publicó Linux 4.19.64, se fusionó con los núcleos comunes 4.19 (por ejemplo, android-4.19-q ). Se recomienda encarecidamente a los socios que fusionen regularmente los kernels comunes con los kernels de sus productos para mantenerse actualizados con las correcciones de errores específicas de LTS y Android.

Rama del núcleo ACK KMI

Los núcleos GKI tienen una interfaz de módulo de núcleo estable. El KMI se identifica de forma única por la versión del kernel y la versión de la plataforma Android, por lo que las ramas se denominan <androidRelease>-<kernel version> . Por ejemplo, el kernel 5.4 GKI para Android 11 se llama android11-5.4. Para Android 12, hay dos kernels GKI adicionales, android12-5.4 y android12-5.10 .

Ramas heredadas de granos de postre

Los kernels de postre heredados se crearon para garantizar que el desarrollo de nuevas funciones no interfiriera con la fusión del kernel común de Android. Las sucursales se crearon antes del lanzamiento del postre asociado y reciben fusiones periódicas de LTS, pero no nuevas características. Por ejemplo, android-4.9-q recibe combinaciones de la rama LTS 4.9.y.

Si una versión del kernel no era un kernel de lanzamiento, no se creaba un kernel de postre, pero el kernel asociado con la versión más reciente de la plataforma es válido para actualizar a futuras versiones de la plataforma Android. Por ejemplo, android-4.9-q fue la última de las ramas postre de android-4.9* , por lo que es compatible y probado con su versión original de la plataforma, Android 10. También es compatible y probado con las versiones de la plataforma que admiten actualizaciones de dispositivos que ejecutan 4.9. Núcleos: Android 11 y Android 12.

Debido a que el esquema de nombres de postres para las versiones de la plataforma Android se eliminó con Android 10, las últimas versiones de postres que se habrían llamado android-4.14-r y android-4.19-r se llamaron android-4.14-stable y android-4.19-stable .

Los kernels de postre son reemplazados por kernels GKI a partir de Android 11, por lo que la lista completa de kernels de postre admitidos se encuentra en esta tabla.

Ramas de kernel de versión heredada

Los kernels de versión se mantienen para proporcionar backports de parches citados en el Boletín de seguridad de Android mensual. Se crearon para cada kernel de lanzamiento cuando hubo una nueva versión de la plataforma Android. Quedan obsoletos cuando la versión del kernel o la plataforma asociada está obsoleta, como se describe en Vigencias del soporte y parches de seguridad .

Cada mes, cuando se publica el Boletín de seguridad de Android, estos kernels se actualizan con backports de los parches citados en el boletín que son relevantes para los kernels ascendentes y los kernels comunes de Android. No reciben parches LTS, por lo que el número de versión menor nunca cambia. No contienen backports para parches específicos del proveedor.

En Android 11 y versiones posteriores de la plataforma, los socios deben fusionarse desde kernels de postre o GKI para aplicar los parches citados en el Boletín de seguridad de Android. No se creará ningún kernel de versión para Android 11 o versiones posteriores de la plataforma.

Por lo tanto, la lista completa de 14 kernels de lanzamiento se muestra en esta tabla y no se agregará ninguno.

Núcleos de características y lanzamiento

Cada versión de la plataforma Android admite el lanzamiento de nuevos dispositivos basados ​​en cualquiera de las tres versiones del kernel de Linux. Como se muestra en la siguiente tabla, los kernels de lanzamiento para Android 11 son android-4.14-stable , android-4.19-stable y android11-5.4 .

Debido a que generalmente no se requieren actualizaciones del kernel cuando se actualiza la versión de la plataforma, los kernels que carecen de las funciones más recientes para una versión de la plataforma aún se pueden usar para iniciar dispositivos. Por lo tanto, los kernels que se diseñaron para Android 10, como android-4.19-q , se pueden usar en dispositivos incluso después de actualizar la versión de la plataforma a Android 11. A partir de Android 12, habrá menos kernels de funciones que kernels de lanzamiento para limitar la cantidad de KMI estables que deben ser compatibles.

Jerarquía de kernel común

Ramificación desde la línea principal de Android

El nivel superior de la jerarquía del kernel común se muestra en la Figura 1.

Figura 1. Creación de kernels comunes a partir del kernel principal de Android

Tenga en cuenta que el nuevo kernel común de Android android12-5.10 se ramificó de android-mainline en 2020. En 2021, cuando se declaró el próximo LTS, android13-5.15 se ramificó de android-mainline .

Como se muestra en la Figura 1, cada versión de kernel es la base para dos kernels GKI. Por ejemplo, los dos kernels v5.4 son android11-5.4 y android12-5.4 , ambos son kernels de características para sus respectivas versiones de plataforma. Este será el caso para 5.10 también; android12-5.10 se creó cuando se declaró el LTS y android13-5.10 se derivará de android12-5.10 en el hito de finalización de funciones del kernel en la primavera de 2021 para permitir el desarrollo de funciones para Android T (AOSP experimental).

Ciclo de vida de la rama ACK KMI

El ciclo de vida de una rama ACK KMI se muestra a continuación en la Figura 2.

Figura 2. 5.10 Ciclo de vida de la rama ACK KMI

Para aclarar el proceso de desarrollo y el ciclo de vida de la rama, la Figura 2 se centra en las ramas ACK KMI para 5.10.

Cada rama ACK KMI pasa por tres fases indicadas en la Figura 2 con diferentes colores en cada rama. Como se muestra, LTS se fusiona regularmente independientemente de la fase.

Fase de desarrollo

Cuando se crea, una rama ACK KMI ingresa a la fase de desarrollo ( dev en la Figura 2) y está abierta para contribuciones de funciones para la próxima versión de la plataforma Android. En la Figura 2, android12-5.10 se creó cuando se declaró 5.10 como el nuevo kernel LTS ascendente. La segunda rama ACK KMI para una versión del kernel podría crearse antes para permitir el desarrollo de la versión posterior. En la figura 2, android13-5.10 se crea cuando android12-5.10 sale de la fase de desarrollo.

Fase de estabilización

Cuando la rama ACK KMI se declara completa, entra en la fase de estabilización , etiquetada como puñalada en la Figura 2. Las funciones de los socios y las correcciones de errores aún se aceptan, pero el seguimiento de KMI está habilitado para detectar cualquier cambio que afecte la interfaz. En esta fase, se aceptan los cambios importantes de KMI, pero la definición de KMI debe actualizarse según sea necesario. Consulte la descripción general de GKI para obtener detalles sobre la supervisión de KMI.

Fase congelada KMI

Antes de enviar una nueva versión de la plataforma a AOSP, la rama ACK KMI se congela y permanece congelada durante el tiempo de vida de la rama. Esto significa que no se aceptan cambios que rompan la KMI a menos que se identifique un problema de seguridad grave que no se pueda mitigar sin afectar la KMI estable. Para evitar interrupciones de KMI, algunos parches combinados de LTS pueden modificarse o eliminarse si la corrección no es necesaria para los dispositivos Android.

Cuando una rama ACK KMI está congelada, se pueden aceptar correcciones de errores y funciones de socios siempre que el kernel común KMI existente no esté dañado. El KMI se puede ampliar con nuevos símbolos exportados siempre que las interfaces que componen el KMI actual no se vean afectadas. Cuando se agregan nuevas interfaces al KMI, inmediatamente se vuelven estables y no se pueden romper con cambios futuros.

Por ejemplo, un cambio que agrega un campo a una estructura utilizada por un kernel común de interfaz KMI no está permitido porque cambia la definición de la interfaz:

struct foo {
  int original_field1;
  int original_field2;
  int new_field;  // Not allowed
};

int do_foo(struct foo &myarg)
{
  do_stuff(myarg);
}
EXPORT_SYMBOL_GPL(do_foo);

Sin embargo, agregar una nueva función está bien:

struct foo2 {
  struct foo orig_foo;
  int new_field;
};

int do_foo2(struct foo2 &myarg)
{
  do_stuff2(myarg);
}
EXPORT_SYMBOL_GPL(do_foo2);

Durante la vida útil del kernel GKI, se mantiene la compatibilidad con versiones anteriores del espacio de usuario para que el kernel se pueda usar de manera segura para la versión de la plataforma Android con la que se lanzó el dispositivo. Las pruebas continuas con versiones anteriores garantizan que se mantenga la compatibilidad. Entonces, en la Figura 2, el kernel android12-5.10 se puede usar para dispositivos Android 12 y dispositivos Android T (AOSP experimental). Debido a que el lanzamiento de la plataforma Android también es compatible con versiones anteriores, el kernel android12-5.4 se puede usar para dispositivos Android T (AOSP experimental), ya sea para el lanzamiento o la actualización.

Al ingresar a la fase congelada, la rama se etiqueta con git con la cadena de versión de KMI que contiene el número de generación de KMI. Por ejemplo, cuando se congeló android11-5.4 , se etiquetó con la cadena de versión de KMI 5.4-android11-0 donde el 0 final es el número de generación de KMI. Si hay un problema de seguridad u otro evento que requiere que se acepte un parche de cambio de KMI, el número de generación de KMI se incrementa y la rama se vuelve a etiquetar. Por ejemplo, si se acepta un cambio de este tipo en android11-5.4 , la rama se etiquetará con la nueva versión de KMI, 5.4-android11-1 . La generación actual de KMI se puede encontrar usando el comando uname :

$ uname -r
5.4.61-android11-0-00153-ga972f59040e4

El número después del lanzamiento de la plataforma es la generación KMI (0 en este caso).

Si la generación de KMI cambia, el kernel no es compatible con los módulos del proveedor que se ajustan a la generación de KMI anterior, por lo que los módulos deben reconstruirse y actualizarse sincrónicamente con el kernel. Se espera que los cambios de generación de KMI sean muy raros.

Compatibilidad entre núcleos

Los requisitos de compatibilidad entre kernels de la misma familia LTS están cambiando a partir de los nuevos kernels GKI.

Núcleos GKI

Los núcleos GKI mantienen la compatibilidad con versiones anteriores de todas las versiones de la plataforma Android que admiten la versión del núcleo. Además, las versiones de la plataforma Android son compatibles con versiones anteriores de kernels GKI de versiones anteriores. Por lo tanto, puede usar con seguridad el kernel android12-5.4 desarrollado para Android 12 en dispositivos que ejecutan Android T (AOSP experimental). La compatibilidad se verifica a través de pruebas continuas de VTS y CTS de los kernels GKI con todas las versiones compatibles.

El KMI es estable para que el kernel se pueda actualizar sin necesidad de reconstruir los módulos del kernel en la imagen del proveedor.

La compatibilidad con KMI no se mantiene entre los diferentes kernels de GKI. Entonces, por ejemplo, un android12-5.10 no se puede reemplazar con un kernel android13-5.10 sin reconstruir todos los módulos.

Los núcleos GKI son compatibles solo con sus versiones iniciales y posteriores. No son compatibles con versiones anteriores. Por lo tanto, un kernel android13-5.10 no es compatible con dispositivos Android 12.

Núcleos heredados

Los kernels de postre heredados ( *-q y *-stable ) no son compatibles con las versiones anteriores de la plataforma Android, pero los kernels de las dos versiones anteriores de la plataforma Android son compatibles con la actualización. Por lo tanto, un dispositivo lanzado con Android 10 que usa un kernel basado en android-4.19-q puede continuar usando el kernel android-4.19-q al actualizar a Android 2020, o actualizar el código específico del proveedor para admitir android-4.19-stable .

Matriz de compatibilidad

Esta tabla muestra las versiones de kernel compatibles y probadas con cada versión de la plataforma Android.

Soporte de por vida y parches de seguridad.

Los kernels comunes de Android son compatibles hasta que el kernel LTS asociado o la versión de la plataforma Android dejen de ser compatibles. Si bien se admite un kernel, continúa recibiendo fusiones LTS de versiones anteriores y correcciones de errores para el código específico de Android. Estas correcciones incluyen todos los parches de seguridad del kernel citados en los boletines de seguridad de Android mensuales que son relevantes para los kernels comunes de Android.

Los socios pueden estar seguros de que al fusionarse regularmente desde los kernels comunes de Android, obtendrán todos los parches de seguridad del kernel posibles.

Pruebas comunes del kernel

Los núcleos comunes se prueban con varios sistemas de CI además de las pruebas posteriores realizadas por los proveedores.

Pruebas funcionales del núcleo de Linaro

Las pruebas Linaro Kernel Functional Testing (LKFT) inician varios conjuntos de pruebas, incluidos kselftest, LTP, VTS y CTS en un conjunto de dispositivos físicos arm32 y arm64. Los resultados de las pruebas recientes se pueden encontrar aquí .

Pruebas de KernelCI

Las pruebas de compilación y arranque de KernelCI se inician cada vez que se asigna un nuevo parche a una rama común del kernel. Varios cientos de configuraciones de compilación se prueban y se inician en varias placas. Los resultados recientes para los núcleos de Android se pueden encontrar aquí .

Pruebas de preenvío y postenvío de Android

Las pruebas previas al envío se utilizan para evitar que se introduzcan fallas en los núcleos comunes. Los resultados no están disponibles públicamente en este momento.

La prueba posterior al envío de Android se realiza cuando se asigna un nuevo parche a una rama común del kernel. Al ingresar aosp_kernel como un nombre de rama parcial, verá una lista de ramas del kernel con resultados disponibles. Por ejemplo, los resultados de android-mainline se pueden encontrar aquí .

prueba de 0 días

Las pruebas de 0 días realizan pruebas parche por parche en todas las ramas comunes del kernel de Android cuando se confirman nuevos parches. Se ejecutan varias pruebas de arranque, funcionales y de rendimiento. Únase al grupo público cros-kernel-buildreports

Matriz de prueba

Contribuyendo a los núcleos comunes de Android

En general, el desarrollo de funciones debe realizarse en la línea principal de Linux y no en los núcleos comunes de Android. Se recomienda encarecidamente el desarrollo ascendente y, una vez que se acepta el desarrollo allí, se puede transferir fácilmente a la rama ACK específica según sea necesario. El equipo de Android Kernel se complace en apoyar los esfuerzos de upstreaming en beneficio del ecosistema de Android.

Envíe parches a Gerrit y cumpla con estas pautas de contribución .