El proyecto de imagen genérica del kernel (GKI)

Un kernel de producto , también conocido como kernel de dispositivo o kernel OEM , es el kernel que usted incluye en su dispositivo. Antes de GKI, el kernel del producto se derivó de una serie de cambios de kernel ascendentes. La Figura 1 muestra cómo las adiciones de kernel producen un kernel de producto (OEM/kernel de dispositivo):

Construcción del núcleo del producto anterior a GKI

Figura 1. Construcción del núcleo del producto anterior a GKI.

  1. El kernel Linux Long Term Supported (LTS) de kernel.org se modificó con parches específicos de Android, lo que dio como resultado un Android Common Kernel (ACK) .
  2. El ACK fue modificado por proveedores que agregaron soporte para su System-on-a-Chip (SoC). Los proveedores también pueden agregar optimizaciones de rendimiento o energía. El kernel resultante se llama kernel del proveedor .
  3. Finalmente, los OEM modificaron aún más el kernel del proveedor con controladores de dispositivos adicionales y personalizaciones que consideraron necesarias. El núcleo resultante se denomina núcleo producto .

Todas estas modificaciones pueden dar como resultado que hasta el 50% del código del núcleo sea código fuera del árbol y no de los núcleos o ACK de Linux ascendentes. Antes de GKI, casi todos los dispositivos tenían un kernel personalizado que provocaba la fragmentación del kernel.

Los costes de la fragmentación

La fragmentación del kernel tiene varios efectos negativos en la comunidad de Android.

Las actualizaciones de seguridad requieren mucha mano de obra

Los parches de seguridad citados en el Boletín de seguridad de Android (ASB) deben adaptarse a cada uno de los kernels del dispositivo. Sin embargo, debido a la fragmentación del kernel, es prohibitivamente costoso propagar las correcciones de seguridad a los dispositivos Android en el campo.

Actualizaciones compatibles a largo plazo difíciles de fusionar

Las versiones con soporte a largo plazo (LTS) incluyen correcciones de seguridad y otras correcciones de errores críticos. Mantenerse al día con los lanzamientos de LTS ha demostrado ser la forma más efectiva de proporcionar soluciones de seguridad. En los dispositivos Pixel, se descubrió que el 90 % de los problemas de seguridad del kernel informados en ASB ya se habían solucionado para los dispositivos que se mantienen actualizados.

Sin embargo, con todas las modificaciones personalizadas en los núcleos de los dispositivos, es difícil fusionar las correcciones de LTS en los núcleos de los dispositivos.

Inhibe las actualizaciones de lanzamiento de la plataforma Android

La fragmentación dificulta que las nuevas funciones de Android que requieren cambios en el kernel se agreguen a los dispositivos en el campo. El código de Android Framework debe suponer que se admiten hasta cinco versiones de kernel y que no se realizaron cambios en el kernel para la nueva versión de la plataforma (Android 10 es compatible con los kernels 3.18, 4.4, 4.9, 4.14 y 4.19, que en algunos casos no han sido mejorado con nuevas funciones desde Android 8 en 2017).

Es difícil contribuir con los cambios del kernel de vuelta a Linux upstream

Con todos los cambios realizados en el kernel, la mayoría de los dispositivos emblemáticos se entregan con una versión del kernel que ya tiene al menos 18 meses. Por ejemplo, kernel.org lanzó el kernel 4.14 en noviembre de 2017 y los primeros teléfonos Android que usaban kernels 4.14 se enviaron en la primavera de 2019.

Esta larga demora entre el lanzamiento del kernel ascendente y los productos dificulta que la comunidad de Android proporcione las funciones y los controladores necesarios en los kernels ascendentes.

Arreglando la fragmentación: imagen genérica del kernel

El proyecto Generic Kernel Image (GKI) aborda la fragmentación del kernel al unificar el kernel central y trasladar el SoC y el soporte de la placa fuera del kernel central a módulos de proveedores cargables. GKI también presenta una interfaz de módulo de kernel (KMI) estable para módulos de proveedores, por lo que los módulos y el kernel se pueden actualizar de forma independiente. Algunas características del kernel GKI son:

  • El kernel GKI se construye a partir de las fuentes ACK.
  • El kernel GKI es un binario de un solo kernel más módulos cargables asociados por arquitectura, por versión LTS (actualmente solo arm64 para android11-5.4 y android12-5.4 ).
  • El kernel GKI se prueba con todas las versiones de la plataforma Android compatibles con el ACK asociado. No hay desactivación de funciones durante la vida útil de una versión del kernel de GKI.
  • El kernel GKI expone un KMI estable a los controladores dentro de un LTS determinado.
  • El kernel de GKI no contiene código específico de SoC o de placa.

Para obtener una imagen de la arquitectura GKI, consulte la descripción general del núcleo .

GKI es un cambio complejo que se implementó en varias etapas, comenzando con los kernels v5.4 en el lanzamiento de la plataforma Android 11.

Actualmente hay dos etapas de GKI:

  • GKI 1.0 se introdujo en Android 11 para dispositivos con kernels 5.4. GKI 1.0 se aplica a todos los dispositivos enviados con kernels 5.4, incluso aquellos lanzados con Android 12 o Android 13.
  • GKI 2.0 se introdujo en Android 12 para dispositivos con kernels 5.10 y es el nuevo estándar para todos los dispositivos que se envían con kernels 5.10 o posteriores.

GKI 1.0

En GKI 1.0, los dispositivos que se inician con la versión 5.4 del kernel deben pasar las pruebas de GKI (Android 11 y versiones posteriores de la plataforma). Los objetivos de GKI 1.0 incluyen lo siguiente:

  • Evite las regresiones en Vendor Test Suite (VTS) o Compatibility Test Suite (CTS) al reemplazar el kernel del producto con el kernel GKI.
  • Reduzca la carga de los socios de mantener su kernel actualizado con los kernels comunes de AOSP.
  • Incluya los cambios principales de Android en los kernels para actualizar y lanzar dispositivos con nuevas versiones de Android.
  • No rompa el espacio de usuario de Android.
  • Separe los componentes específicos del hardware del kernel central como módulos cargables.

Para la documentación de GKI 1.0, consulte la sección GKI 1.0 .

GKI 2.0

En GKI 2.0, los dispositivos que se inician con la versión de kernel 5.10 o superior deben enviarse con el kernel de GKI (a partir de Android 12). Las imágenes de arranque firmadas están disponibles y se actualizan regularmente con LTS y correcciones de errores críticos. Debido a que se mantiene la estabilidad binaria para el KMI, puede instalar estas imágenes de inicio sin realizar cambios en las imágenes del proveedor. Los objetivos de GKI 2.0 incluyen lo siguiente:

  • No introduzca regresiones significativas de rendimiento o energía al reemplazar el kernel del producto con el kernel GKI.
  • Permita que los socios proporcionen correcciones de seguridad del kernel y correcciones de errores sin la participación del proveedor.
  • Reduzca el costo de actualizar la versión principal del kernel para dispositivos (por ejemplo, de v5.10 al kernel 2021 LTS).
  • Mantenga un solo binario de kernel GKI por arquitectura actualizando las versiones del kernel con un proceso claro para la actualización.

GKI 2.0 representa el estado más actual de los núcleos de Android. La documentación del kernel fuera de las subsecciones GKI 1.0 y kernels anteriores (<=4.19) refleja la arquitectura GKI 2.0.

,

Un kernel de producto , también conocido como kernel de dispositivo o kernel OEM , es el kernel que usted incluye en su dispositivo. Antes de GKI, el kernel del producto se derivó de una serie de cambios de kernel ascendentes. La Figura 1 muestra cómo las adiciones de kernel producen un kernel de producto (OEM/kernel de dispositivo):

Construcción del núcleo del producto anterior a GKI

Figura 1. Construcción del núcleo del producto anterior a GKI.

  1. El kernel Linux Long Term Supported (LTS) de kernel.org se modificó con parches específicos de Android, lo que dio como resultado un Android Common Kernel (ACK) .
  2. El ACK fue modificado por proveedores que agregaron soporte para su System-on-a-Chip (SoC). Los proveedores también pueden agregar optimizaciones de rendimiento o energía. El kernel resultante se llama kernel del proveedor .
  3. Finalmente, los OEM modificaron aún más el kernel del proveedor con controladores de dispositivos adicionales y personalizaciones que consideraron necesarias. El núcleo resultante se denomina núcleo producto .

Todas estas modificaciones pueden dar como resultado que hasta el 50% del código del núcleo sea código fuera del árbol y no de los núcleos o ACK de Linux ascendentes. Antes de GKI, casi todos los dispositivos tenían un kernel personalizado que provocaba la fragmentación del kernel.

Los costes de la fragmentación

La fragmentación del kernel tiene varios efectos negativos en la comunidad de Android.

Las actualizaciones de seguridad requieren mucha mano de obra

Los parches de seguridad citados en el Boletín de seguridad de Android (ASB) deben adaptarse a cada uno de los kernels del dispositivo. Sin embargo, debido a la fragmentación del kernel, es prohibitivamente costoso propagar las correcciones de seguridad a los dispositivos Android en el campo.

Actualizaciones compatibles a largo plazo difíciles de fusionar

Las versiones con soporte a largo plazo (LTS) incluyen correcciones de seguridad y otras correcciones de errores críticos. Mantenerse al día con los lanzamientos de LTS ha demostrado ser la forma más efectiva de proporcionar soluciones de seguridad. En los dispositivos Pixel, se descubrió que el 90 % de los problemas de seguridad del kernel informados en ASB ya se habían solucionado para los dispositivos que se mantienen actualizados.

Sin embargo, con todas las modificaciones personalizadas en los núcleos de los dispositivos, es difícil fusionar las correcciones de LTS en los núcleos de los dispositivos.

Inhibe las actualizaciones de lanzamiento de la plataforma Android

La fragmentación dificulta que las nuevas funciones de Android que requieren cambios en el kernel se agreguen a los dispositivos en el campo. El código de Android Framework debe suponer que se admiten hasta cinco versiones de kernel y que no se realizaron cambios en el kernel para la nueva versión de la plataforma (Android 10 es compatible con los kernels 3.18, 4.4, 4.9, 4.14 y 4.19, que en algunos casos no han sido mejorado con nuevas funciones desde Android 8 en 2017).

Es difícil contribuir con los cambios del kernel de vuelta a Linux upstream

Con todos los cambios realizados en el kernel, la mayoría de los dispositivos emblemáticos se entregan con una versión del kernel que ya tiene al menos 18 meses. Por ejemplo, kernel.org lanzó el kernel 4.14 en noviembre de 2017 y los primeros teléfonos Android que usaban kernels 4.14 se enviaron en la primavera de 2019.

Esta larga demora entre el lanzamiento del kernel ascendente y los productos dificulta que la comunidad de Android proporcione las funciones y los controladores necesarios en los kernels ascendentes.

Arreglando la fragmentación: imagen genérica del kernel

El proyecto Generic Kernel Image (GKI) aborda la fragmentación del kernel al unificar el kernel central y trasladar el SoC y el soporte de la placa fuera del kernel central a módulos de proveedores cargables. GKI también presenta una interfaz de módulo de kernel (KMI) estable para módulos de proveedores, por lo que los módulos y el kernel se pueden actualizar de forma independiente. Algunas características del kernel GKI son:

  • El kernel GKI se construye a partir de las fuentes ACK.
  • El kernel GKI es un binario de un solo kernel más módulos cargables asociados por arquitectura, por versión LTS (actualmente solo arm64 para android11-5.4 y android12-5.4 ).
  • El kernel GKI se prueba con todas las versiones de la plataforma Android compatibles con el ACK asociado. No hay desactivación de funciones durante la vida útil de una versión del kernel de GKI.
  • El kernel GKI expone un KMI estable a los controladores dentro de un LTS determinado.
  • El kernel de GKI no contiene código específico de SoC o de placa.

Para obtener una imagen de la arquitectura GKI, consulte la descripción general del núcleo .

GKI es un cambio complejo que se implementó en varias etapas, comenzando con los kernels v5.4 en el lanzamiento de la plataforma Android 11.

Actualmente hay dos etapas de GKI:

  • GKI 1.0 se introdujo en Android 11 para dispositivos con kernels 5.4. GKI 1.0 se aplica a todos los dispositivos enviados con kernels 5.4, incluso aquellos lanzados con Android 12 o Android 13.
  • GKI 2.0 se introdujo en Android 12 para dispositivos con kernels 5.10 y es el nuevo estándar para todos los dispositivos que se envían con kernels 5.10 o posteriores.

GKI 1.0

En GKI 1.0, los dispositivos que se inician con la versión 5.4 del kernel deben pasar las pruebas de GKI (Android 11 y versiones posteriores de la plataforma). Los objetivos de GKI 1.0 incluyen lo siguiente:

  • Evite las regresiones en Vendor Test Suite (VTS) o Compatibility Test Suite (CTS) al reemplazar el kernel del producto con el kernel GKI.
  • Reduzca la carga de los socios de mantener su kernel actualizado con los kernels comunes de AOSP.
  • Incluya los cambios principales de Android en los kernels para actualizar y lanzar dispositivos con nuevas versiones de Android.
  • No rompa el espacio de usuario de Android.
  • Separe los componentes específicos del hardware del kernel central como módulos cargables.

Para la documentación de GKI 1.0, consulte la sección GKI 1.0 .

GKI 2.0

En GKI 2.0, los dispositivos que se inician con la versión de kernel 5.10 o superior deben enviarse con el kernel de GKI (a partir de Android 12). Las imágenes de arranque firmadas están disponibles y se actualizan regularmente con LTS y correcciones de errores críticos. Debido a que se mantiene la estabilidad binaria para el KMI, puede instalar estas imágenes de inicio sin realizar cambios en las imágenes del proveedor. Los objetivos de GKI 2.0 incluyen lo siguiente:

  • No introduzca regresiones significativas de rendimiento o energía al reemplazar el kernel del producto con el kernel GKI.
  • Permita que los socios proporcionen correcciones de seguridad del kernel y correcciones de errores sin la participación del proveedor.
  • Reduzca el costo de actualizar la versión principal del kernel para dispositivos (por ejemplo, de v5.10 al kernel 2021 LTS).
  • Mantenga un solo binario de kernel GKI por arquitectura actualizando las versiones del kernel con un proceso claro para la actualización.

GKI 2.0 representa el estado más actual de los núcleos de Android. La documentación del kernel fuera de las subsecciones GKI 1.0 y kernels anteriores (<=4.19) refleja la arquitectura GKI 2.0.