APEX en Android Q: ¿Qué podría ser lo más importante desde Project Treble?

La implementación de APEX es probablemente el mayor dolor de cabeza al que se ha enfrentado Google desde la introducción del Proyecto Treble. ¿Qué es APEX y cómo cambiará su introducción a Android?

La idea detrás de APEX en sí es bastante común en las distribuciones diarias 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 se almacenan todas las bibliotecas y marcos del sistema en comparación con las particiones RW (lectura-escritura) habituales que se usan en la mayoría de las distribuciones de Linux, representando el estándar. proceso de actualización 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 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, sino que 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 de /system.

En primer lugar, tenemos que especificar la diferencia entre una biblioteca compartida y una biblioteca estática. Una biblioteca compartida es una biblioteca (generalmente un archivo llamado libkind.so) que no incluye todo el código necesario para ejecutarse en sí misma, pero está vinculada a otras bibliotecas que realmente proporcionan el código, mientras que una biblioteca estática es, como puede adivinar , una biblioteca que no depende de ninguna otra biblioteca y tiene todo incluido estáticamente dentro del archivo.

Android ha configurado históricamente la ruta de la biblioteca (conocida como LD_LIBRARY_PATH en el mundo de 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 otra biblioteca. Estas rutas están codificadas en la configuración y no se pueden expandir. Este diseño, incluida la partición del sistema de solo lectura, conduce a bibliotecas no actualizables a menos que el usuario instale una actualización OTA de Android. Google solucionó este problema y permitió 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) contenidas en ellos.

Si bien este movimiento solucionó uno de los problemas principales, aún quedaban algunos problemas graves por superar. En primer lugar: estabilidad ABI (interfaz binaria de aplicación). Las bibliotecas siempre deben exportar un conjunto estable de interfaces para permitir que otras aplicaciones y bibliotecas sigan funcionando con el mismo protocolo, incluso con la biblioteca actualizada. Google está trabajando activamente en eso al intentar crear una interfaz C estable entre las bibliotecas APEXed.

Pero un APEX no se limita solo a bibliotecas y archivos 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).

Estos son algunos ejemplos de los paquetes APEX actuales proporcionados por AOSP:

• com.android.runtime: ART y bionic runtime (binarios y bibliotecas)
• com.android.tzdata: datos de TimeZone y ICU (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 ser instalado por nuestro práctico ADB (en este punto del desarrollo) y, más tarde, por el propio usuario a través de un administrador de paquetes (como Google Play o manualmente a través de Android). paquete de instalación).

El diseño ZIP es el siguiente:

Sumerjámonos en eso.

Apex_manifest.json especifica el nombre y la versión del paquete.

El 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, solo se está comprobando la extensión para diferenciarlos.

los META-INF / El directorio tiene el certificado del paquete y utiliza el mismo mecanismo que los APK normales. Por lo tanto, estos paquetes se verifican mediante un par de claves pública/privada en tiempo de ejecución antes de que el usuario pueda instalar una actualización. Pero eso no fue suficiente para Google, por lo que agregaron 2 capas más de seguridad. Están usando 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 por echar un vistazo a los APEX actualmente instalados en mi dispositivo (un emulador)

Como puede ver, los paquetes preinstalados se almacenan 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 brindan suficiente información para comprender el origen del paquete y dónde se instalará: /apex/, un nuevo directorio introducido en Android Q que se usará para almacenar los paquetes activados.

Una vez que el paquete se ha verificado correctamente con AVB y la clave pública coincide, el APEX se monta utilizando un dispositivo de bucle en /dev/block/loop0, lo que hace 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, lo que hace que el contenido de ese archivo sea accesible como un punto de montaje.

En este punto, el APEX todavía no se usa debido al sufijo @1 (que indica la versión del paquete). Para que el sistema sepa finalmente que nuestro paquete se activó con éxito, se vinculará a /apex/com.android.tzdata, donde Android espera activamente que viva tzdata. Un montaje de enlace se superpone a un directorio o archivo existente en un punto diferente. [1]

La implementación de APEX está completamente 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, todo lo que puedo hacer es especular. Mi mejor suposición es que Google está tratando de crear un conjunto básico de paquetes APEX que Google puede actualizar para crear posiblemente un núcleo base unificado de Android compartido entre proveedores, haciendo posible las actualizaciones del sistema, pero usando actualizaciones de paquetes únicos.

¿Todos los dispositivos serán compatibles con APEX?

No. Por ejemplo, apexd requiere que /data/apex esté disponible inmediatamente después del arranque 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 las variantes APEX del sistema se cargarán 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 al jugar con dispositivos de bucle). [3] [4]

---

Fuentes [0], [1], [2], [3], [4]