APEX será la principal innovación de Android Q. ¿Qué es?

Google está trabajando en APEX: actualizar las bibliotecas del sistema como una distribución estándar de Linux. Esperado en Android Q, APEX puede ser lo más grande desde Project Treble.

Lectores como tú ayudan a apoyar a los desarrolladores de XDA. Cuando realiza una compra utilizando enlaces en nuestro sitio, podemos ganar una comisión de afiliado.

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 y escritura) habituales que se usan en la mayoría de las distribuciones de Linux, lo que representa la actualización estándar. proceso 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; 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 de /system.

READ
Samsung actualizó la cámara de los teléfonos inteligentes del año pasado y ya no se necesitan costosos teléfonos con cámara

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 supongo, una biblioteca que no depende de ninguna otra biblioteca y tiene todo incluido estáticamente dentro del archivo.

Históricamente, Android ha configurado 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 bibliotecas 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)
READ
El cronograma de actualización de HTC se filtró en línea

¿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:

Vamos a sumergirnos 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 los 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 programas 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? Nuevamente usaremos com.android.tzdata como ejemplo.

READ
Aprendiendo gestos de Android P

Reiniciemos el dispositivo y analicemos el logcat.

El primero comprende 2 líneas que brindan suficiente información sobre 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. [una]

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 conjetura es que Google está tratando de crear un conjunto básico de paquetes APEX que Google puede actualizar para posiblemente crear un núcleo base unificado de Android compartido entre proveedores, haciendo posibles solo actualizaciones del “sistema”, pero usando actualizaciones de paquetes individuales.

Ayer se lanzó otra actualización del sistema operativo para dispositivos móviles de Google. Una de las principales novedades de Android 10 fue el “Proyecto Mainline”. Trataré de averiguar qué es, por qué y cómo funciona.

READ
Cómo ha cambiado el aspecto de MIUI en el transcurso de siete años

Durante años, Google ha estado tratando de resolver el problema de las actualizaciones de seguridad de Android. Actualmente, Android está instalado en varios miles de millones de dispositivos, pero la mayoría de los fabricantes son muy reacios a admitir dispositivos después del lanzamiento. Esto da como resultado que muchos dispositivos en producción ejecuten una versión con vulnerabilidades conocidas.

El primer gran paso para facilitar la actualización de Android fue “Project Treble”, que “dividió” Android en dos partes: dependiente e independiente del hardware. Lo que facilitó el lanzamiento de actualizaciones a nuevas versiones de Android. El siguiente gran paso fue Project Mainline. Le permitirá actualizar componentes individuales del sistema operativo sin actualizar todo el sistema, de forma similar a la actualización de aplicaciones.

¿Por qué era necesario?

En la arquitectura de Android, el sistema operativo (a menudo denominado firmware) está estrechamente separado de los datos y las aplicaciones del usuario. Está ubicado en una sección separada de la memoria flash, es de solo lectura y, en las últimas versiones de Android, está firmado con una firma electrónica para el control de integridad. Las aplicaciones de Android que forman parte del sistema operativo se pueden actualizar para colocar nuevas versiones de aplicaciones en el área de almacenamiento del usuario. No era posible actualizar otras partes del sistema operativo (servicios, bibliotecas, etc.), por ejemplo, utilizando un administrador de paquetes, como en las distribuciones de Linux. Para tales correcciones, el fabricante se vio obligado a lanzar una actualización de todo el sistema. Al mismo tiempo, al usar Google Mobile Services (la gran mayoría de los dispositivos los usan), cada actualización requiere la certificación de Google. Y “Project Mainline” resuelve este problema, ahora los componentes del sistema se pueden actualizar por separado, de forma similar a las aplicaciones de Android. Además de las actualizaciones de seguridad, también facilita la actualización de la configuración y los datos del sistema, como las zonas horarias (tzdata).

¿Cómo funciona esto

En el corazón del “Proyecto Mainline” se encuentra el nuevo contenedor para aplicaciones del sistema APEX (abreviatura de Android Pony EXpress).

READ
Samsung presentó su primer teléfono inteligente Android Go

En Android 10, Google ha identificado 13 paquetes APEX en el sistema que se pueden actualizar de forma independiente:

  • Seguridad: códecs de medios, componentes de marco de medios, resolución de DNS, Conscrypt
  • Privacidad: interfaz de usuario de documentos, controlador de permisos, servicios externos
  • Coherencia: datos de zona horaria, ÁNGULO (opción de los desarrolladores), metadatos del módulo, componentes de red, inicio de sesión del portal cautivo, configuración de permisos de red

El archivo APEX es similar al que se usa para las aplicaciones APK de Andoird.

APEX es un archivo zip que contiene 4 archivos principales:

  • apex_manifest.json: contiene el nombre y la versión del paquete;
  • AndroidManifest.xml: metadatos del paquete (similar a APK);
  • apex_payload.img – imagen del sistema de archivos ext4;
  • apex_pubkey es la clave pública para verificar la firma de la imagen.

administrador de APEX

  • El instalador del paquete, habiendo determinado que se trata de un paquete APEX, lo pasa al administrador de APEX.
  • El administrador de APEX verifica el paquete y su versión.
  • Si pasan las comprobaciones, lo descomprime en la sección de memoria del usuario, actualiza la entrada en su base de datos y reinicia los dispositivos.
  • Al iniciar APEX, el administrador verifica todos los paquetes de la base de datos, crea un dispositivo de bucle para la imagen ext4 y lo monta en /apex/name@ver.
  • archivos ejecutables,
  • bibliotecas compartidas (.so),
  • bibliotecas JAR,
  • archivos de información,
  • Archivos de configuración.

Firma del paquete APEX

El paquete APEX se firma dos veces, con dos claves diferentes. La imagen ext4 se firma con una clave (se usa dm-verity, como en Android Verified Boot), el paquete APEX (archivo zip) se firma con la segunda clave, similar al paquete APK.

Kernel Linux

APEX utiliza una serie de mecanismos del kernel de Linux, como el dispositivo de bucle, DM-verity.
APEX es compatible con la versión de kernel 4.4 y superior. Para dispositivos con versiones de kernel anteriores, solo se admite el modo plano no actualizable.

Rating
( No ratings yet )
Like this post? Please share to your friends:
Leave a Reply

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!: