Google ha estado trabajando para reducir la fragmentación en Android durante años, aunque esto se debe en parte a la naturaleza inherente de Android y la espada de doble filo de elección y libertad. Hay innumerables OEM activos en el espacio, y todos quieren hacer sus propios cambios en sus propios dispositivos. Entonces, el problema 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 fluido posible.
Aliviar el dolor de actualización de Android
La primera iniciativa importante en el proyecto a largo plazo de Google para reducir la carga de desarrollo fue Project Treble. 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 en el marco AOSP más reciente, ya que podían arrancar con la última versión sin necesidad de actualizar el código de los proveedores. Como resultado, los fabricantes de equipos originales podrían preparar sus versiones personalizadas de Android más rápido que antes y, por extensión, implementar las principales actualizaciones del sistema operativo más rápido.
El próximo paso en los planes de Google fue agilizar la entrega de actualizaciones a los principales componentes de Android. Google llamó a esta iniciativa Project Mainline cuando la presentó junto con Android 10 en 2019. Básicamente, Google tomó el control de los componentes clave del sistema operativo y prohibió que los OEM los modificaran. Luego configuraron un mecanismo de entrega a través de Google Play para que pudieran implementar actualizaciones de forma remota a estos componentes clave sin tener que esperar a que los OEM aplicaran los parches por sí mismos. Mainline ha mejorado drásticamente la velocidad con la que los dispositivos reciben versiones actualizadas de componentes importantes del sistema operativo, mejorando la seguridad del ecosistema de Android en su conjunto.
Sin embargo, en lo que respecta a Treble, el kernel de Linux no debe incluirse con un código de proveedor de código cerrado. Todd Kjos en la Linux Plumbers Conference de este año explicó los desafíos de la fragmentación de Android en el pasado, y gran parte ahora se enfoca en el kernel de Linux que los OEM envían con sus dispositivos. Para el contexto, Google bifurca cada núcleo principal de Linux en una rama de «Android Common Kernel» (ACK), que sigue de cerca el lanzamiento de la línea principal pero agrega algunas correcciones específicas de Android. Los proveedores de SoC como Qualcomm, MediaTek y Samsung se bifurcan a continuación este núcleo 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 enviar.
El diagrama anterior muestra cómo el núcleo de un dispositivo atraviesa varias capas de cambios que lo abstraen del núcleo LTS de Linux. Para hacerlo simple, comenzamos con el kernel de Linux y se fusiona con el kernel común de Android con algunos cambios. A partir de ahí, el núcleo común de Android se fusiona con un núcleo de proveedor (Qualcomm, MediaTek, etc.) con sus propios ajustes y cambios. Finalmente, el kernel del proveedor se fusiona con el kernel específico del dispositivo de un OEM. En este punto, el kernel de cualquier dispositivo está muy lejos del kernel LTS de Linux con el que comenzó.
Como resultado de todas estas 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 los núcleos ascendentes comunes de Linux o AOSP. Esto hace que sea extremadamente difícil (sin mencionar el tiempo y el dinero que consume) fusionar los cambios anteriores. Para los OEM, no hay ningún incentivo para hacerlo, pero esta práctica puede comprometer la seguridad del dispositivo. Esta es también la razón por la que muchos dispositivos Android permanecen en versiones anteriores del kernel LTS, lo que tiene el efecto secundario de hacer que los dispositivos pierdan el acceso a las funciones más nuevas 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 envían 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. Esto es claramente un problema y puede retrasar la plataforma.
Por ejemplo, Code Aurora Forum, o CAF para abreviar, aloja el código fuente de varios SoC Qualcomm Snapdragon. Qualcomm, como proveedor de SoC, distribuye una versión bifurcada del kernel de Linux a los OEM/ODM, y estas empresas luego agregan modificaciones específicas del dispositivo a los dispositivos de envío. Esto es lo que agrega varias capas de fragmentación. Además, Qualcomm está realizando 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 de Linux modificado, el marco AOSP y otras herramientas de software a sus socios como parte de un Paquete de soporte de placa o BSP. CAF es donde Qualcomm publica públicamente estos cambios en el kernel de Linux y los cambios en el marco AOSP.
Esta compilación de CAF puede ser útil para los desarrolladores de ROM personalizadas que desean usarla como punto de partida en lugar de AOSP puro, razón por la cual a veces se ven ROM «basadas en CAF» en nuestros foros. ¿Recuerdas el Snapdragon 625 que pareció alimentar a tantos teléfonos inteligentes de gama media durante años? Esto se lanzó con el kernel de Linux 3.18, y no fue hasta finales de 2018 (dos años después del lanzamiento del conjunto de chips) que Qualcomm actualizó las fuentes del kernel y las lanzó a CAF para msm8953 (el nombre del conjunto de chips Snapdragon 625) brindando soporte para el núcleo Linux 4.9. El problema es que la mayoría de los OEM no actualizarán los teléfonos a esta nueva versión del kernel de Linux, especialmente los teléfonos de gama media dos años después del lanzamiento del chip. Es cierto que es muy raro que una actualización importante del kernel como esta suceda en primer lugar, pero el hecho es que en sucedió, por lo que no es solo un escenario imposible.
En general, la fragmentación actual de Android es un desastre, por decirlo suavemente. Los últimos intentos de Google para solucionar esta fragmentación se presentan en forma de imagen genérica del núcleo o GKI.
Presentamos la imagen genérica del kernel
Para remediar esta fragmentación, Google ha trabajado en Android Generic Kernel Image (GKI). Es esencialmente un núcleo compilado directamente desde una rama ACK. El GKI aísla las personalizaciones de fabricantes de equipos originales y proveedores de SoC en módulos complementarios, lo que elimina el código fuera del árbol y permite que Google envíe actualizaciones del kernel directamente al usuario final. Durante más de un año, Google ha estado trabajando en una forma de entregar actualizaciones de GKI a través de Play Store, mediante el uso de un módulo Mainline.
Por lo tanto, los dispositivos que se inician con Android 12 que ejecutan Linux kernel 5.10.43 o superior deben realizar una de las siguientes acciones: según Mishaal Rahman.
- Implementar una imagen de arranque firmada por Google
DONDE
- Implemente una imagen de arranque con un kernel que exporte una interfaz de módulo de kernel (KMI) que es un subconjunto de la KMI exportada por GKI, exporta una API de espacio de usuario que es un superconjunto de UAPI expuesto por GKI y es compatible con todos las características de la versión GKI correspondiente
Los proveedores pueden crear módulos que se conectan a la GKI, pero la idea de la GKI es que Google asuma la responsabilidad de administrar los cambios del kernel. La interfaz del módulo del kernel (o KMI, más sobre eso en partes posteriores del artículo) es efectivamente donde se supone que debe ir el código fuera del árbol.
La serie Google Pixel 6 se lanzó con Android 12 listo para usar y viene con Linux kernel 5.10, y es el primer teléfono que viene con un GKI. Dado 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 generalmente se publican semanalmente. De cualquier manera, es un sistema mucho mejor que el engorroso método actual de actualización a través de OTA, aunque eso significa que está intrínsecamente ligado al marco GMS.
Google simplemente define el GKI de la siguiente manera:
- Está construido a partir de fuentes ACK.
- Este es un binario de un solo núcleo y cargables asociados por arquitectura, por versión LTS (actualmente solo arm64 para
android11-5.4yandroid12-5.4). - Se prueba con todas las versiones de la plataforma Android que son compatibles con el ACK asociado. No hay abandonos de funciones durante la vigencia de una versión del kernel de GKI
- Expone un KMI estable a los controladores dentro de un LTS dado.
- No contiene ningún SoC o 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 núcleo principal de Linux, lo que reducirá la «deuda técnica» acumulada en el código externo en los dispositivos Android.
La interfaz del módulo del kernel (KMI)
La interfaz del módulo del kernel, o KMI, es parte de la solución de Google a la fragmentación en curso de Android. Esencialmente, el SoC y el soporte de la placa ya no están en el núcleo central y en su lugar se trasladaron a módulos cargables. El núcleo y los módulos se pueden actualizar de forma independiente, mientras que los módulos se actualizan en /lib/modules. El GKI en sí está destinado a ser lo más limpio y genérico posible, lo que es posible al volcar lo que ahora es código fuera del árbol en módulos separados.
Como explicó Ted Kjos en la Linux Plumbers Conference de este año, “el gran impulso de varios años es obtener todo el código específico del hardware del núcleo genérico y en los módulos del proveedor. Necesitamos tener una interfaz estable entre estos módulos de proveedores y el kernel genérico para que puedan entregarse de forma asíncrona. GKI 1.0 es esencialmente una «prueba de conformidad».
De hecho, la compatibilidad con 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 instalados mediante la instalación de la imagen de arranque GKI en la partición de arranque y la imagen del sistema GSI en la partición del sistema. 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 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 los kernels de GKI deben cargar módulos desde las mismas particiones de proveedor_arranque y proveedor. Por lo tanto, todos los kernels de productos deben tener la misma interfaz de módulo de kernel binario (KMI).
El diagrama anterior muestra lo que Google quiere hacer y explica cómo se propone lograrlo. Los módulos Generic Kernel y GKI será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 quiere en el kernel (por ejemplo, controladores de cámara) se insertará en un módulo de proveedor que se convierte en una extensión de GKI a través de KMI.
Cómo GKI puede ayudar a resolver el problema de fragmentación de Android
Google ha trabajado duro para agilizar el proceso de desarrollo de teléfonos inteligentes. Cada OEM quiere su propia identidad de marca y cada OEM quiere poder poseer sus dispositivos. A diferencia del programa Android One, los teléfonos inteligentes Android pueden ser prácticamente lo que quieran, siempre y cuando sigan el conjunto de reglas que establece Google para recibir una licencia GMS. Sin embargo, en el pasado, Google ha hecho poco para reinar en el desarrollo de dispositivos Android, con cambios como Project Treble, Mainline y ahora el GKI es mucho más reciente en la historia de Android.
¿Pero ayudará? Debería hacerlo, aunque probablemente será un asunto de varios años que dará frutos visibles más adelante. Esto solo se aplicará a los dispositivos que se inicien con Android 12, lo que significa que veremos dispositivos que no tienen GKI en los próximos años. También fue una revisión de Project Treble cuando se anunció, aunque obviamente todos los dispositivos que se lanzan hoy lo admiten. Estas cosas toman tiempo y, a medida que Google toma lentamente las riendas de Android, el proceso de desarrollo se vuelve más fácil para todos los OEM en el ecosistema de Android, aunque algunos de ellos prefieren mantener el control total del kernel de Linux que se usa en los teléfonos inteligentes con Android.
