Google está trabajando en APEX: actualizar las bibliotecas del sistema como una distribución estándar de Linux. APEX, esperado en Android Q, puede ser lo más importante desde Project Treble.
La implementación de APEX es probablemente el mayor dolor de cabeza que ha enfrentado Google desde la introducción del Proyecto Treble. ¿Qué es APEX y cómo cambiará Android su introducción?
La idea detrás de APEX en sí misma es bastante común en las distribuciones cotidianas de GNU/Linux: actualizaciones de paquetes dirigidas a secciones específicas del conjunto de bibliotecas de Linux. Pero eso es algo que Google nunca intentó hacer dado que Android ha usado una partición RO (solo lectura) donde todas las bibliotecas del sistema y Los marcos se almacenan en comparación con las particiones RW (lectura-escritura) habituales utilizadas en la mayoría de las distribuciones de Linux, lo que representa el proceso de actualización estándar. inadecuado.
Las bibliotecas son código precompilado que se puede utilizar en otros programas. Los métodos comúnmente utilizados se pueden convertir en bibliotecas para que las aplicaciones de Android los llamen, lo que reduce el tamaño de los APK, ya que no será necesario volver a implementar el mismo código en varias aplicaciones. Puede encontrar muchas bibliotecas del sistema preinstaladas en los directorios /system/lib y /system/lib64. Las bibliotecas del sistema Android generalmente no se actualizan individualmente; más bien, se actualizan como parte de las actualizaciones de las plataformas Android a través de una actualización OTA. Por otro lado, las bibliotecas en las distribuciones de Linux pueden actualizarse individualmente. Con la introducción de APEX, las bibliotecas del sistema en Android se pueden actualizar individualmente como las aplicaciones de Android. El principal beneficio de esto es que los desarrolladores de aplicaciones podrán aprovechar las bibliotecas actualizadas sin esperar a que un OEM implemente una actualización completa del sistema. Profundicemos en más detalles técnicos sobre cómo funciona APEX.
¿Cómo cambiará APEX la forma en que se actualizan las bibliotecas?
APEX es un ecosistema que obligó (o mejor dicho, está obligando) a Google a reconsiderar la forma en que Android carga todas las bibliotecas y archivos desde una partición no estándar diferente a /system.
En primer lugar, debemos especificar la diferencia entre una biblioteca compartida y una biblioteca estática. Una biblioteca compartida es una biblioteca (normalmente un archivo llamado libkind.so) que no incluye todo el código necesario para ejecutarse en sí misma, pero que en realidad está "vinculada" a otras bibliotecas. proporcionar el código, mientras que una biblioteca estática es, como puedes adivinar, una biblioteca que no depende de ninguna otra biblioteca y tiene todo incluido estáticamente dentro del archivo.
Android históricamente ha configurado la ruta de la biblioteca (conocida como LD_LIBRARY_PATH en el mundo Linux) con un solo archivo llamado ld.config.txt [0] para configurar las rutas de búsqueda permitidas para las bibliotecas compartidas que necesita el binario u otro biblioteca. Estas rutas están codificadas en la configuración y no son ampliables. Este diseño, incluida la partición del sistema de solo lectura, genera bibliotecas que no se pueden actualizar a menos que el usuario instale una actualización OTA de Android. Google solucionó este problema permitiendo ampliar la ruta de búsqueda al permitir que los paquetes APEX individuales proporcionaran su propio ld.config.txt que incluía las rutas de biblioteca adicionales (y actualizadas) que contenían.
Si bien esta medida solucionó uno de los principales problemas, todavía quedaban algunos problemas graves por superar. En primer lugar: estabilidad de ABI (interfaz binaria de aplicación). Las bibliotecas siempre deben exportar un conjunto estable de interfaces para permitir que otras aplicaciones y bibliotecas continúen trabajando con el mismo protocolo incluso con la biblioteca actualizada. Google está trabajando activamente en ello intentando crear una interfaz C estable entre las bibliotecas APEXed.
Pero un APEX no se limita únicamente a bibliotecas y binarios. De hecho, puede contener archivos de configuración, actualizaciones de zona horaria y algunos marcos Java (conscrypt en el momento de escribir este artículo).
A continuación se muestran algunos ejemplos de los paquetes APEX actuales proporcionados por AOSP:
- com.android.runtime: ART y tiempo de ejecución biónico (binarios y bibliotecas)
- com.android.tzdata: datos de zona horaria y UCI (bibliotecas y datos de configuración)
- com.android.resolv: Biblioteca utilizada por Android para resolver solicitudes relacionadas con la red (bibliotecas)
- com.android.conscrypt: un proveedor de seguridad de Java (marco de Java)
¿Cómo se instala y estructura un paquete APEX?
Un paquete APEX es un archivo zip simple (como un APK) que puede instalarse mediante nuestro práctico ADB (en este punto de desarrollo). y, posteriormente, por el propio usuario a través de un administrador de paquetes (como Google Play o manualmente a través del paquete de Android instalador).
El diseño ZIP es el siguiente:
Profundicemos en eso.
Apex_manifest.json especifica el nombre y la versión del paquete.
apex_payload.img es una imagen de microsistema de archivos (formateada como EXT4).
Los otros archivos son parte del proceso de verificación utilizado para instalar el paquete. Echemos un vistazo.
La presencia de AndroidManifest.xml, incluso si se usa principalmente en aplicaciones, nos ayuda a comprender que la mayor parte de la implementación utilizada para una instalación de APK estándar se reutiliza incluso para estos paquetes. De hecho, sólo se está comprobando la extensión para diferenciarlas.
El META-INF/ El directorio tiene el certificado del paquete y utiliza el mismo mecanismo que los APK normales. Entonces estos paquetes se verifican mediante un par de claves pública y privada en tiempo de ejecución antes de que se permita al usuario instalar una actualización. Pero eso no fue suficiente para Google, por lo que agregaron 2 capas más de seguridad. Están utilizando dm-verity para verificar la integridad de la imagen y verificaciones AVB (Android Verified Boot) para asegurarse de que la imagen provenga de una fuente confiable. En el peor de los casos, el paquete APEX será rechazado.
Si todos los pasos de verificación son exitosos, la imagen se marcará como válida y reemplazará la variante del sistema en el próximo reinicio.
¿Cómo se instala una imagen en el arranque?
Comencemos echando un vistazo a los APEX instalados actualmente en mi dispositivo (un emulador)
Como puede ver, los paquetes preinstalados están almacenados en /system/apex/ y todos ellos se encuentran actualmente en la versión número 1. Pero, ¿qué sucede cuando se activa un APEX? Volveremos a utilizar com.android.tzdata como ejemplo.
Reiniciemos el dispositivo y analicemos el logcat.
Las primeras 2 líneas proporcionan suficiente información para comprender el origen del paquete y dónde estará. instalado: /apex/, un nuevo directorio introducido en Android Q que se utilizará para almacenar los archivos activados paquetes.
Después de que el paquete se haya verificado exitosamente con AVB y la clave pública coincida, APEX se monta usando un dispositivo de bucle en /dev/block/loop0, haciendo que el sistema de archivos EXT4 sea accesible para el sistema. Un dispositivo de bucle es un pseudodispositivo que hace que un archivo sea accesible como un dispositivo de bloque, haciendo que el contenido de ese archivo sea accesible como un punto de montaje.
En este punto, APEX todavía no se utiliza debido al sufijo @1 (que indica la versión del paquete). Para finalmente informarle al sistema que nuestro paquete se ha activado exitosamente, se montará vinculado en /apex/com.android.tzdata donde Android espera activamente que viva tzdata. Un montaje de enlace superpone un directorio o archivo existente en un punto diferente. [1]
La implementación de APEX está enteramente contenida en un único repositorio bajo AOSP. [2] El directorio apexd (demonio APEX) tiene el código ejecutándose en Android. El directorio apexer tiene el código utilizado por el sistema de compilación para crear los paquetes APEX.
¿Cuál es el propósito?
En este punto, lo único que puedo hacer es especular. Mi mejor suposición es que Google está intentando crear un conjunto central de paquetes APEX que Google pueda actualizar para posiblemente crear un núcleo base unificado de Android compartido entre proveedores, lo que hace posibles solo las actualizaciones del "sistema", pero utilizando un solo paquete actualizaciones.
¿Todos los dispositivos serán compatibles con APEX?
No. Por ejemplo, apexd requiere que /data/apex esté disponible inmediatamente después del inicio para actualizar todos los módulos de Android. Con FDE (cifrado de disco completo), /data/apex se cifra hasta que el usuario desbloquea el dispositivo, lo que hace que APEX sea básicamente inútil ya que solo se cargarán las variantes de APEX del sistema en el arranque. Aparte de eso, todos los dispositivos deberían ser compatibles con APEX, pero necesitan algunos parches del kernel (muchos de los cuales son correcciones encontradas por Google mientras jugaba con dispositivos de bucle). [3] [4]
Fuentes [0], [1], [2], [3], [4]