Kernels comunes de Android

Los kernels comunes del AOSP (también conocidos como kernels comunes de Android o ACKs) son derivados de los kernels de kernel.org y contienen parches de interés para la comunidad de Android que no se combinaron con los kernels principales o de soporte a largo plazo (LTS). Estos parches pueden incluir lo siguiente:

• Puertos traseros y cherry-picks de la funcionalidad upstream necesaria para las funciones de Android
• Funciones listas para dispositivos Android, pero aún en desarrollo upstream
• Funciones de proveedores o de OEM que son útiles para otros socios del ecosistema

android-mainline es la rama de desarrollo principal para las funciones de Android. La rama principal de Linux se combina en android-mainline cada vez que Linus Torvalds publica una versión o una versión candidata. Antes de 2019, los kernels comunes de Android se construían clonando el kernel de LTS declarado recientemente y agregando los parches específicos de Android. Este proceso cambió en 2019 para crear una rama del nuevo kernel común de Android a partir de android-mainline. Este nuevo modelo evita el esfuerzo significativo de portar y probar parches de Android, ya que logra el mismo resultado de forma incremental. android-mainline se somete a pruebas continuas significativas, por lo que este modelo incluye un kernel de alta calidad desde el día en que se publica.

Cuando se declara un nuevo LTS upstream, el kernel común correspondiente se bifurca desde android-mainline. Esto permite que los socios comiencen un proyecto antes de la declaración de la versión LTS, ya que pueden combinar desde android-mainline. Después de crear la nueva rama del kernel común, los socios pueden cambiar sin problemas la fuente de combinación a la nueva rama.

Otras ramas comunes del kernel reciben fusiones periódicas de su kernel LTS asociado. Por lo general, estas combinaciones se realizan inmediatamente después de que se publica la versión LTS. Por ejemplo, cuando se publicó Linux 6.1.75, se combinó con el kernel común 6.1 (android14-6.1). Se recomienda a los socios que actualicen sus kernels para mantenerse al día con las correcciones de errores específicas de LTS y Android.

Rama del kernel de KMI con ACK

Los kernels de GKI tienen una interfaz de módulo del kernel estable. La KMI se identifica de forma única por la versión del kernel y la versión de la plataforma de Android, por lo que las ramas se denominan ANDROID_RELEASE-KERNEL_VERSION. Por ejemplo, el kernel del GKI 6.1 para Android 14 se llama android14-6.1. Para Android 15, se introdujo el kernel de GKI android15-6.6.

Funciones y lanzamientos de kernels

Antes de Android 15, se podía usar cualquiera de los tres kernels más recientes para el lanzamiento del dispositivo. A partir de Android 15, se pueden usar las dos versiones del kernel más recientes para el lanzamiento de dispositivos. Los kernels de lanzamiento para Android 15 son android15-6.6 y android14-6.1.

Dado que no se requieren actualizaciones del kernel cuando se actualiza la versión de la plataforma, los kernels que no tienen las funciones más recientes para una versión de la plataforma se pueden seguir usando para lanzar dispositivos. Por lo tanto, los kernels diseñados para Android 14, como android14-6.1, se pueden usar en dispositivos incluso después de actualizar la versión de la plataforma a Android 15.

Jerarquía común del kernel

Crea una rama a partir de android-mainline

En la figura 1, se muestra el nivel superior de la jerarquía del kernel común.

Figura 1: Cómo crear kernels comunes a partir del kernel de android-mainline

Ten en cuenta que se creó una nueva rama del kernel común de Android android14-6.1 a partir de android-mainline en 2022. En 2023, cuando se declaró la siguiente versión LTS, android15-6.6 se bifurcó de android-mainline.

Como se muestra en la Figura 1, cada versión del kernel puede ser la base de dos kernels de GKI. Por ejemplo, los dos kernels de la versión 5.15 son android13-5.15 y android14-5.15, y ambos son kernels de funciones para sus respectivas versiones de la plataforma. Este también fue el caso de la versión 5.10; android12-5.10 se creó cuando se declaró la versión LTS y android13-5.10 se bifurcó 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 13. A partir de Android 15 (2024), solo habrá un kernel de GKI nuevo por versión del kernel (no habrá un kernel android15-6.1).

Ciclo de vida de la rama de KMI de ACK

En la figura 2, se muestra el ciclo de vida de una rama de KMI de ACK.

Figura 2: 6.6 Ciclo de vida de la rama de KMI de ACK

Para aclarar el proceso de desarrollo y el ciclo de vida de las ramas, la Figura 2 se enfoca en las ramas de KMI de ACK para la versión 6.6.

Cada rama del KMI de ACK pasa por tres fases que se indican en la figura 2 con diferentes colores en cada rama. Como se muestra, la LTS se combina con regularidad, independientemente de la fase.

Fase de desarrollo

Cuando se crea, una rama de KMI de ACK ingresa en la fase de desarrollo (etiquetada como dev en la Figura 2) y está abierta para las contribuciones de funciones para la próxima versión de la plataforma de Android. En la figura 2, se creó android15-6.6 cuando se declaró la versión 6.6 como el nuevo kernel LTS upstream.

Fase de estabilización

Cuando se declara que la rama de KMI de ACK tiene todas las funciones, entra en la fase de estabilización (etiquetada como estable en la Figura 2). Aún se aceptan funciones para socios y correcciones de errores, pero el seguimiento del KMI está habilitado para detectar cualquier cambio que afecte la interfaz. En esta fase, se aceptan los cambios rotundos en la KMI y se actualiza la definición de la KMI con una cadencia predefinida (normalmente, cada dos semanas). Consulta la descripción general del GKI para obtener detalles sobre la supervisión del KMI.

Fase de congelación del KMI

Antes de que se envíe una nueva versión de la plataforma al AOSP, la rama de KMI de ACK se congela y permanece congelada durante toda la vida útil de la rama. Esto significa que no se aceptarán cambios que interrumpan 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 en la KMI, es posible que algunos parches combinados desde la LTS se modifiquen o se descarten si la corrección no es necesaria para los dispositivos Android.

Cuando se congela una rama del KMI de ACK, se pueden aceptar correcciones de errores y funciones para socios, siempre y cuando no se interrumpa el kernel común del KMI existente. El KMI se puede extender con nuevos símbolos exportados, siempre y cuando no se vean afectadas las interfaces que componen el KMI actual. Cuando se agregan interfaces nuevas al KMI, se vuelven estables de inmediato y los cambios futuros no pueden interrumpirlas.

Por ejemplo, no se permite un cambio que agregue un campo a una estructura que usa una interfaz de KMI de un kernel común, ya que 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 función nueva 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 de la GKI, se mantiene la retrocompatibilidad con el espacio del usuario para que el kernel se pueda usar de forma segura en la versión de la plataforma de Android con la que se lanzó el dispositivo. Las pruebas continuas con versiones anteriores mantienen la compatibilidad. Por lo tanto, en la figura 2, el kernel android15-6.6 se puede usar para dispositivos con Android 15 y versiones posteriores. Dado que la versión de la plataforma Android también es compatible con versiones anteriores, el kernel android14-6.1 se podría usar para dispositivos Android 15, ya sea para el lanzamiento o la actualización.

Número de generación del KMI

Si hay una combinación de LTS durante la fase de estabilización o un problema de seguridad o algún otro evento después de esto que requiera que se acepte un parche que cambie la KMI, se incrementa el número de generación de la KMI registrado en build.config.common. La generación actual de KMI se puede encontrar con el comando uname:

$ uname -r
6.6.30-android15-6-g86d10b30f51f

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

Si cambia la generación de la KMI, el kernel no es compatible con los módulos del proveedor que cumplen con la generación de la KMI anterior, por lo que los módulos se deben volver a compilar y actualizar de forma síncrona con el kernel. Después de la congelación del KMI, se espera que los cambios en la generación del KMI sean muy poco frecuentes.

Compatibilidad entre kernels

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

Kernels de GKI

Los kernels de GKI mantienen la retrocompatibilidad con todas las versiones de la plataforma de Android que admitían la versión del kernel. Además, las versiones de la plataforma de Android son retrocompatibles con los kernels de GKI de versiones anteriores. Por lo tanto, puedes usar de forma segura el kernel android14-6.1 desarrollado para Android 14 (2023) en dispositivos que ejecutan Android 15 (2024). La compatibilidad se verifica a través de pruebas continuas de VTS y CTS de los kernels de GKI con todas las versiones compatibles.

La KMI es estable, por lo que el kernel se puede actualizar sin necesidad de recompilar los módulos del kernel en la imagen del proveedor.

La compatibilidad con la KMI no se mantiene entre los diferentes kernels del GKI. Por ejemplo, un kernel android14-6.1 no se puede reemplazar por un kernel android15-6.6 sin volver a compilar todos los módulos.

Los kernels de GKI solo son compatibles con sus versiones iniciales y posteriores. No se admiten en versiones anteriores. Por lo tanto, no se admite un kernel android15-6.6 para los dispositivos que ejecutan Android 14 (2023).

Matriz de compatibilidad

En esta tabla, se muestran las versiones del kernel compatibles y probadas con cada versión de la plataforma de Android.

Vida útil y parches de seguridad

Los ACK reciben combinaciones de LTS de la versión upstream y correcciones de errores para el código específico de Android. Estas correcciones incluyen todos los parches de seguridad del kernel que se citan en los Boletines de seguridad de Android mensuales que son relevantes para ACK.

Es posible que los ACK se admitan durante más tiempo que el kernel estable upstream correspondiente en kernel.org. En este caso, Google proporciona asistencia extendida hasta la fecha de final del ciclo de vida (EOL) que se muestra en esta sección. Cuando los kernels alcanzan el final de su ciclo de vida, Google ya no los admite y los dispositivos que los ejecutan se consideran vulnerables.

A partir del kernel 6.6, el ciclo de vida de asistencia para los kernels estables es de 4 años.

En esta tabla, se muestran los tiempos de actividad de los ACK admitidos:

Pruebas comunes del kernel

Los kernels comunes se prueban con varios sistemas de CI, además de las pruebas posteriores que realizan los proveedores.

Prueba funcional del kernel de Linux

Las pruebas de Linux Kernel Functional Test (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 en la página android-lkft.

Pruebas de KernelCI

Las pruebas de compilación y arranque de KernelCI se inician cada vez que se confirma un parche nuevo en una rama de kernel común. Se prueban y se inician varios cientos de configuraciones de compilación en diversas placas. Los resultados recientes de los kernels de Android se pueden encontrar en el sitio de KernelCL.

Pruebas previas al envío y posteriores al envío en Android

Las pruebas previas al envío se usan para evitar que se introduzcan fallas en los kernels comunes de Android. El resumen de los resultados de la prueba se puede encontrar en la pestaña "Checks" del cambio de código en el kernel común de Android Gerrit.

Las pruebas posteriores al envío de Android se realizan en las nuevas compilaciones publicadas en las ramas de kernel comunes de Android cuando se confirman parches nuevos en una rama de kernel común de Android en ci.android.com. Si ingresas aosp_kernel como nombre de rama parcial en ci.android.com, verás una lista de ramas de kernel con resultados disponibles. Por ejemplo, los resultados de android-mainline se pueden encontrar en el panel de integración continua de compilaciones de Android (Android CI). Haz clic en una compilación específica para encontrar el estado de la prueba en la pestaña Test Results.

Las pruebas definidas por test-mapping con el grupo de pruebas kernel-presubmit en el árbol de código fuente de la plataforma de Android se ejecutan como pruebas previas a la confirmación para las ramas del kernel de Android. Por ejemplo, la siguiente configuración en test/vts/tests/kernel_proc_file_api_test/TEST_MAPPING habilita vts_kernel_proc_file_api_test como prueba previa a la confirmación en el registro de código del kernel común de Android.

{
  "kernel-presubmit": [
    {
      "name": "vts_kernel_proc_file_api_test"
    }
  ]
}

Pruebas de día cero

Las pruebas de día cero realizan pruebas parche por parche en todas las ramas del kernel común de Android cuando se confirman parches nuevos. Se ejecutan varias pruebas de inicio, funcionales y de rendimiento. Únete al grupo público cros-kernel-buildreports.

Matriz de pruebas

Cómo colaborar con los kernels comunes de Android

En general, el desarrollo de funciones debe realizarse en el kernel de Linux principal y no en los kernels comunes de Android. Se recomienda encarecidamente el desarrollo upstream y, después de que se acepte el desarrollo allí, se puede realizar un backport a la rama específica de ACK según sea necesario. El equipo del kernel de Android se complace en respaldar los esfuerzos de upstreaming en beneficio del ecosistema de Android.

Envía parches a Gerrit y cumple con estos lineamientos de contribución.