La imagen genérica del kernel de Google tiene como objetivo resolver el problema de la fragmentación en Android, aunque es un tema complicado. Así es como funciona.
Google ha estado trabajando para reducir la fragmentación en Android durante años, aunque parte de la causa es la naturaleza inherente de Android y el arma de doble filo de la elección y la libertad. Hay innumerables fabricantes de equipos originales activos en el sector y todos quieren realizar sus propias modificaciones para sus propios dispositivos. El problema entonces es que parece que las actualizaciones del sistema operativo Android tardan en implementarse en todos los ámbitos, pero no hay mucho que Google pueda hacer para obligar a los OEM a actualizar sus dispositivos. Como tal, lo mejor que puede hacer Google es hacer que el proceso de actualización sea lo más fácil y sencillo posible.
Aliviar el dolor de la actualización de Android
La primera iniciativa importante en el proyecto a largo plazo de Google para reducir la carga de desarrollo fue
Proyecto agudos. Anunciado junto con Android 8.0 Oreo en 2017, Project Treble modularizó Android al separar el marco del sistema operativo de la implementación del proveedor (HAL y la bifurcación del kernel de Linux específica del dispositivo). Esto facilitó que los OEM de Android cambiaran la base de sus sistemas operativos sobre el último marco AOSP, ya que podían iniciar la última versión sin necesidad de actualizar el código de los proveedores. Como resultado, los OEM podrían preparar sus bifurcaciones personalizadas de Android más rápido que antes y, por extensión, implementar actualizaciones importantes del sistema operativo más rápidamente.El siguiente paso en los planes de Google era agilizar la entrega de actualizaciones a componentes clave de Android. Google llamó a esta iniciativa Línea principal del proyecto cuando lo presentó junto con Android 10 en 2019. Básicamente, Google tomó el control de los componentes clave del sistema operativo y prohibió a los OEM modificarlos. Luego configuraron un mecanismo de entrega a través de Google Play para poder implementar de forma remota actualizaciones para estos componentes clave sin tener que esperar a que los OEM apliquen los parches ellos mismos. Mainline mejoró enormemente la rapidez con la que los dispositivos reciben versiones actualizadas de componentes importantes del sistema operativo, lo que a su vez mejoró la seguridad del ecosistema de Android en su conjunto.
Sin embargo, cuando se trata de Treble, el kernel de Linux, de manera realista, no debería agruparse con el código de proveedor de fuente cerrada. Todd Kjos en Conferencia de fontaneros de Linux de este año ha explicado en el pasado las dificultades que se enfrentan cuando se trata de fragmentación en Android, y gran parte ahora se centra en el kernel de Linux que los OEM incluyen con sus dispositivos. Para contextualizar, Google bifurca cada kernel de Linux principal en un "Núcleo común de Android”(ACK), que sigue de cerca la versión principal pero agrega algunos parches específicos de Android. Los proveedores de SoC como Qualcomm, MediaTek y Samsung luego se bifurcan eso kernel para cada SoC que fabrican. Luego, los OEM toman ese kernel específico de SoC y agregan parches adicionales para implementar soporte para el hardware específico que desean distribuir.
El diagrama anterior muestra cómo el kernel de un dispositivo pasa por varias capas de cambios que lo abstraen del kernel LTS de Linux. Para simplificarlo, comenzamos con el kernel de Linux y se fusiona con el kernel común de Android con algunos cambios. A partir de ahí, el kernel común de Android se fusiona con el kernel de un proveedor (Qualcomm, MediaTek, etc.) con sus propias modificaciones y cambios. Finalmente, el kernel del proveedor se fusiona con el kernel específico del dispositivo de un OEM. En esta etapa, el kernel de cualquier dispositivo está muy alejado del kernel LTS de Linux con el que comenzó.
Como resultado de todas esas bifurcaciones, hasta el 50% del código que se ejecuta en un dispositivo Android es código fuera del árbol, lo que significa que no proviene de núcleos comunes de Linux o AOSP. Esto hace que sea increíblemente difícil (sin mencionar que consume mucho tiempo y es costoso) fusionar los cambios anteriores. Para los OEM, no hay ningún incentivo para hacerlo, pero esa práctica puede ser perjudicial para la seguridad del dispositivo. Esta es también la razón por la que muchos dispositivos Android permanecen con versiones anteriores del kernel LTS, lo que tiene el efecto secundario de que los dispositivos pierdan el acceso a las nuevas funciones del kernel de Linux.
Android está fragmentado y Google lo sabe
Google sabe muy bien que esto es un problema, e incluso tiene una sección llamada "Los costos de la fragmentación" en la documentación para desarrolladores de Android. Google dice que "La mayoría de los dispositivos emblemáticos se entregan con una versión del kernel que ya tiene al menos 18 meses". Peor aún, Google también dice que "Android 10 es compatible con los kernels 3.18, 4.4, 4.9, 4.14 y 4.19, que en algunos casos no se han mejorado con nuevas funciones desde Android 8 en 2017". Esto dificulta agregar funciones que requieren nuevas versiones del kernel de Linux. El kernel de Linux 3.18 se lanzó en diciembre de 2014, cuando Android 5.0 Lollipop era la última versión de Android. Eso es claramente un problema y puede frenar la plataforma.
Por ejemplo, Code Aurora Forum, o CAF para abreviar, aloja el código fuente de varios SoC Qualcomm Snapdragon. Qualcomm, como SoC proveedor, distribuye una versión bifurcada del kernel de Linux a OEM/ODM, y esas empresas luego agregan cambios específicos del dispositivo en el envío dispositivos. Esto es lo que añade varias capas de fragmentación. Además, Qualcomm realiza cambios en el marco AOSP para optimizar Android para cada una de las plataformas móviles Snapdragon de la empresa. Qualcomm distribuye de forma privada su kernel Linux modificado, su marco AOSP y otras herramientas de software a sus socios como parte de un Board Support Package (BSP). CAF es donde Qualcomm publica públicamente estos cambios en el kernel de Linux y los cambios en el marco de AOSP.
Esta versión CAF puede ser útil para los desarrolladores de ROM personalizados que deseen utilizarla como punto de partida en lugar de AOSP puro, razón por la cual a veces se ve ROMs “basadas en CAF” en nuestros foros. ¿Recuerda el Snapdragon 625 que pareció impulsar tantos teléfonos inteligentes de gama media durante años? Se lanzó con Linux Kernel 3.18, y solo hacia fines de 2018 (dos años después del lanzamiento del chipset) Qualcomm actualizó las fuentes del kernel y las publicó en c y f para msm8953 (el nombre del chipset del Snapdragon 625) que brinda soporte para el kernel de Linux 4.9. El problema es que la mayoría de los OEM no actualizará los teléfonos a esta nueva versión del kernel de Linux, especialmente los teléfonos de gama media dos años después de que se lanzó el chip liberado. Es cierto que es muy raro que una actualización importante del kernel como esa ocurra en primer lugar, pero el punto es que tiene sucedió, por lo que no es sólo un escenario imposible.
Considerándolo todo, la fragmentación actual en Android es un desastre, por decirlo a la ligera. Los últimos intentos de Google para solucionar esa fragmentación se presentan en forma de Imagen de Kernel Genérica, o GKI.
Presentamos la imagen genérica del kernel
Para abordar esta fragmentación, Google trabajó en la imagen de kernel genérica de Android (GKI). Este es esencialmente un kernel compilado directamente desde una rama ACK. GKI aísla las personalizaciones de fabricantes de SoC y OEM en módulos de complementos, eliminando el código fuera del árbol y permitiendo a Google enviar actualizaciones del kernel directamente al usuario final. Durante más de un año, Google ha estado trabajando en una forma de ofrecer actualizaciones de GKI a través de Play Store. mediante el uso de un módulo Mainline.
Como resultado, los dispositivos que se inician con Android 12 y ejecutan el kernel de Linux 5.10.43 o superior deben realizar una de las siguientes acciones: según Mishaal Rahman.
- Implementar una imagen de inicio firmada por Google
O
- Implemente una imagen de arranque con un kernel que exporte una KMI (interfaz del módulo del kernel) que es un subconjunto del KMI exportado por GKI. exporta una API de espacio de usuario que es un superconjunto de la UAPI expuesta por GKI y admite todas las características de la GKI correspondiente. versión
Los proveedores pueden crear módulos que se conecten a GKI, pero la idea de GKI es que Google asuma la responsabilidad de manejar los cambios del kernel. La interfaz del módulo kernel (o KMI, más sobre esto en las últimas partes del artículo) es efectivamente donde se espera que vaya el código fuera del árbol.
La serie Google Pixel 6 se lanzó con Android 12 listo para usar y se envía con el kernel de Linux 5.10, y es el primer teléfono que se envía con un GKI. Debido a que Google podría actualizar el kernel a través de Play Store, es posible que incluso veamos actualizaciones frecuentes del kernel. ya que las actualizaciones del kernel LTS normalmente se publican semanalmente. De cualquier manera, es un sistema mucho mejor que el método actualmente engorroso de actualización vía OTA, aunque esto significa que está inherentemente ligado al marco GMS.
Google simplemente define el GKI de la siguiente manera:
- Está construido a partir de fuentes ACK.
- Es un binario de un solo núcleo más módulos cargables asociados por arquitectura, por versión LTS (actualmente solo arm64 para
android11-5.4
yandroid12-5.4
). - Se ha probado con todas las versiones de la plataforma Android compatibles con el ACK asociado. No hay ninguna característica obsoleta durante la vida útil de una versión del kernel GKI
- Expone un KMI estable a los conductores dentro de un LTS determinado.
- No contiene SoC ni código específico de la placa.
Google incluso quiere estar en una posición para 2023 en la que pueda adoptar un modelo de desarrollo "upstream first". Esto ayudará a Google a garantizar que el nuevo código llegue primero al kernel principal de Linux, reduciendo la "deuda técnica" acumulada en el código fuera del árbol en los dispositivos Android.
La interfaz del módulo kernel (KMI)
La interfaz del módulo kernel, o KMI, es parte de la solución de Google a la fragmentación actual en Android. En esencia, el soporte para SoC y placa ya no se encuentra en el núcleo central y, en cambio, se traslada a módulos cargables. Tanto el kernel como los módulos se pueden actualizar de forma independiente, ya que los módulos se actualizan en /lib/modules
. Se supone que el GKI en sí es lo más limpio y genérico posible, lo que es posible descargando lo que ahora está fuera del código del árbol en módulos separados.
Como Ted Kjos explicado en En la Conferencia de Plomeros de Linux de este año, "el gran impulso de varios años es sacar todo el código específico del hardware del núcleo genérico y colocarlo en los módulos del proveedor. Tenemos que tener una interfaz estable entre los módulos del proveedor y el kernel genérico para que puedan enviarse de forma asincrónica". GKI 1.0 es esencialmente una "prueba de cumplimiento".
De hecho, la compatibilidad GKI significa que el dispositivo pasa las pruebas VTS y CTS-on-GSI+GKI con la Imagen Genérica del Sistema (GSI). y el kernel GKI instalado al actualizar la imagen de inicio de GKI en la partición de inicio y la imagen del sistema GSI en el sistema dividir. Vendor Test Suite, o VTS, es una prueba automatizada que todos los dispositivos deben pasar para ser considerados compatibles con Project Treble. Se requiere el conjunto de pruebas de compatibilidad, o CTS, para poder acceder al conjunto de aplicaciones de Google.
Los dispositivos pueden enviarse con un kernel de producto diferente y pueden usar módulos cargables que GKI no proporciona. Sin embargo, tanto el producto como el kernel GKI deben cargar módulos desde las mismas particiones de proveedor y de arranque_proveedor. Por lo tanto, todos los núcleos del producto deben tener la misma interfaz de módulo de núcleo binario (KMI).
El diagrama anterior muestra lo que Google quiere hacer y explica cómo piensa lograrlo. Los módulos Generic Kernel y GKI formarán parte de AOSP, y GKI puede comunicarse con el marco de Android y la capa de abstracción de hardware (HAL) que un proveedor puede implementar. El código propietario específico que un proveedor desea en el kernel (por ejemplo, controladores de cámara) se insertará en un módulo del proveedor que se convierte en una extensión de GKI a través del KMI.
Cómo GKI puede ayudar a resolver el problema de fragmentación de Android
Google ha estado trabajando mucho para agilizar el proceso de desarrollo de teléfonos inteligentes. Cada OEM quiere su propia identidad de marca y cada OEM quiere poder ser propietario de sus dispositivos. A diferencia del programa Android One, los teléfonos inteligentes Android pueden ser prácticamente lo que quieran, siempre que cumplan con el conjunto de reglas que establece Google para recibir una licencia GMS. Sin embargo, en el pasado, Google no ha hecho mucho para reinar en el desarrollo de dispositivos Android, con cambios como Project Treble, Mainline y ahora que GKI es mucho más reciente en Android historia.
¿Pero ayudará? Debería ser así, aunque es probable que sea un asunto de varios años que dé frutos visibles más adelante. Esto solo se aplicará a los dispositivos que se lanzan con Android 12, lo que significa que veremos dispositivos que no tienen GKI en los próximos años. Esa también fue una crítica al Proyecto Treble cuando se anunció, aunque obviamente todos los dispositivos lanzados hoy en día lo admiten. Estas cosas toman tiempo y, a medida que Google toma lentamente las riendas de Android, el proceso de desarrollo se facilita para todos los OEM en el ecosistema de Android, incluso si algunos de ellos prefieren conservar el control total sobre el kernel de Linux que se utiliza en Android teléfonos inteligentes.