Google travaille sur APEX: mise à jour des bibliothèques système comme une distribution Linux standard. Attendu dans Android Q, APEX pourrait être la nouveauté la plus importante depuis Project Treble.
La mise en œuvre de l'APEX est probablement le plus gros casse-tête auquel Google a été confronté depuis l'introduction du projet Treble. Qu’est-ce que l’APEX et comment son introduction va-t-elle changer Android ?
L'idée derrière APEX en elle-même est plutôt courante dans les distributions GNU/Linux quotidiennes: des mises à jour de paquets ciblant des sections spécifiques de l'ensemble des bibliothèques Linux. Mais c'est quelque chose que Google n'a jamais essayé de faire étant donné qu'Android a utilisé une partition RO (lecture seule) où toutes les bibliothèques système et les frameworks sont stockés par rapport aux partitions RW (lecture-écriture) habituelles utilisées dans la plupart des distributions Linux, ce qui rend le processus de mise à niveau standard inapproprié.
Les bibliothèques sont du code précompilé qui peut être utilisé dans d'autres programmes. Les méthodes couramment utilisées peuvent être transformées en bibliothèques que les applications Android peuvent appeler, réduisant ainsi la taille des APK, car le même code n'aura pas besoin d'être réimplémenté dans plusieurs applications. Vous pouvez trouver de nombreuses bibliothèques système préinstallées dans les répertoires /system/lib et /system/lib64. Les bibliothèques du système Android ne sont généralement pas mises à jour individuellement, mais plutôt dans le cadre des mises à niveau des plates-formes Android via une mise à jour OTA. D'un autre côté, les bibliothèques des distributions Linux peuvent être mises à jour individuellement. Avec l'introduction d'APEX, les bibliothèques système sous Android peuvent être mises à jour individuellement comme les applications Android. Le principal avantage est que les développeurs d’applications pourront profiter de bibliothèques mises à jour sans attendre qu’un OEM déploie une mise à niveau complète du système. Examinons plus en détail le fonctionnement de l'APEX.
Comment APEX va-t-il changer la façon dont les bibliothèques sont mises à jour?
APEX est un écosystème qui a forcé (ou plutôt oblige) Google à reconsidérer la façon dont Android charge toutes les bibliothèques et tous les fichiers à partir d'une partition non standard différente de /system.
Tout d’abord, il faut préciser la différence entre une bibliothèque partagée et une bibliothèque statique. Une bibliothèque partagée est une bibliothèque (généralement un fichier nommé libkind.so) qui n'inclut pas tout le code nécessaire à son exécution mais qui est en fait « liée » à d'autres bibliothèques. fournissant le code, alors qu'une bibliothèque statique est, comme vous pouvez le deviner, une bibliothèque qui ne dépend d'aucune autre bibliothèque et dont tout est inclus statiquement dans le déposer.
Android a historiquement configuré le chemin de la bibliothèque (appelé LD_LIBRARY_PATH dans le monde Linux) avec un seul fichier. appelé ld.config.txt [0] pour configurer les chemins de recherche autorisés pour les bibliothèques partagées nécessaires au binaire ou à un autre bibliothèque. Ces chemins sont codés en dur dans la configuration et ne sont pas extensibles. Cette disposition, y compris la partition système en lecture seule, conduit à des bibliothèques non mises à jour, à moins que l'utilisateur n'installe une mise à jour OTA Android. Google a résolu ce problème en permettant d'étendre le chemin de recherche en permettant aux packages APEX uniques de fournir leur propre ld.config.txt qui incluait les chemins de bibliothèques supplémentaires (et mis à jour) qu'ils contiennent.
Même si cette décision a résolu l’un des principaux problèmes, il restait encore quelques problèmes sérieux à surmonter. Tout d’abord: la stabilité de l’ABI (application binaire interface). Les bibliothèques doivent toujours exporter un ensemble stable d'interfaces pour permettre à d'autres applications et bibliothèques de continuer à fonctionner avec le même protocole, même avec la bibliothèque mise à niveau. Google y travaille activement en essayant de créer une interface C stable entre les bibliothèques APEX.
Mais un APEX ne se limite pas aux seules bibliothèques et binaires. En fait, il peut contenir des fichiers de configuration, des mises à jour de fuseau horaire et certains frameworks Java (conscrypt au moment de la rédaction).
Voici quelques exemples des packages APEX actuels fournis par AOSP :
- com.android.runtime: ART et bionic runtime (binaires et bibliothèques)
- com.android.tzdata: données TimeZone et ICU (bibliothèques et données de configuration)
- com.android.resolv: bibliothèque utilisée par Android pour résoudre les requêtes liées au réseau (bibliothèques)
- com.android.conscrypt: un fournisseur de sécurité Java (framework Java)
Comment un package APEX est-il installé et structuré?
Un package APEX est une simple archive zip (comme un APK) qui peut être installée par notre ADB pratique (à ce stade du développement) et, plus tard, par l'utilisateur lui-même via un gestionnaire de packages (comme Google Play ou manuellement via le package Android installateur).
La disposition ZIP est la suivante :
Allons-y.
Le apex_manifest.json spécifie le nom et la version du package.
Le apex_payload.img est une image de micro-système de fichiers (formatée en EXT4).
Les autres fichiers font partie du processus de vérification utilisé pour installer le package. Regardons.
La présence de AndroidManifest.xml, même s’il est principalement utilisé dans les applications, nous aide à comprendre que la plupart de l’implémentation utilisée pour une installation APK standard est réutilisée même pour ces packages. En fait, seule l’extension est vérifiée pour les différencier.
Le META-INF/ Le répertoire possède le certificat du package et utilise le même mécanisme que les APK normaux. Donc ces paquets sont vérifiés par une paire de clés privée/publique au moment de l'exécution avant que l'utilisateur ne soit autorisé à installer une mise à jour. Mais cela n’a pas suffi à Google, qui a donc ajouté 2 couches de sécurité supplémentaires. Ils utilisent dm-verity pour vérifier l'intégrité de l'image et les vérifications AVB (Android Verified Boot) pour s'assurer que l'image provient d'une source fiable. Dans le pire des cas, le paquet APEX sera rejeté.
Si toutes les étapes de vérification réussissent, l'image sera marquée comme valide et remplacera la variante du système au prochain redémarrage.
Comment une image est-elle installée au démarrage?
Commençons par jeter un œil aux APEX actuellement installés sur mon appareil (un émulateur)
Comme vous pouvez le voir, les packages préinstallés sont stockés dans /system/apex/ et tous sont actuellement sur la version numéro 1. Mais que se passe-t-il lorsqu’un APEX est activé? Nous utiliserons à nouveau com.android.tzdata comme exemple.
Redémarrons l'appareil et analysons le logcat.
Les 2 premières lignes fournissent suffisamment d’informations pour comprendre l’origine du colis et où il va se trouver installé: /apex/, un nouveau répertoire introduit dans Android Q qui sera utilisé pour stocker les fichiers activés. paquets.
Une fois que le package a été vérifié avec succès avec AVB et que les correspondances de clé publique, l'APEX est monté à l'aide d'un périphérique en boucle sur /dev/block/loop0, rendant le système de fichiers EXT4 accessible au système. Un périphérique en boucle est un pseudo-périphérique qui rend un fichier accessible en tant que périphérique bloc, rendant le contenu de ce fichier accessible en tant que point de montage.
À ce stade, l'APEX n'est toujours pas utilisé à cause du suffixe @1 (qui indique la version du package). Pour enfin faire savoir au système que notre package a été activé avec succès, il sera monté en liaison sur /apex/com.android.tzdata où Android s'attend activement à ce que tzdata vive. Un montage de liaison superpose un répertoire ou un fichier existant sous un point différent. [1]
La mise en œuvre d'APEX est entièrement contenue dans un référentiel unique sous AOSP. [2] Le répertoire apexd (démon APEX) contient le code exécuté sur Android. Le répertoire apexer contient le code utilisé par le système de build pour créer les packages APEX.
Quel est le but?
À ce stade, tout ce que je peux faire, c’est spéculer. Ma meilleure hypothèse est que Google essaie de créer un ensemble de base de packages APEX qui peuvent être mis à jour par Google pour éventuellement créer un noyau de base unifié d'Android partagé entre les fournisseurs, permettant uniquement les mises à jour du « système », mais en utilisant un seul package mises à jour.
Tous les appareils prendront-ils en charge APEX?
Non. Par exemple, apexd nécessite que /data/apex soit disponible juste après le démarrage pour mettre à jour tous les modules Android. Avec FDE (Full-disk Encryption), /data/apex est crypté jusqu'à ce que l'appareil soit déverrouillé par l'utilisateur, rendant APEX pratiquement inutile car seules les variantes APEX du système seront chargées au démarrage. En dehors de cela, tous les appareils devraient prendre en charge APEX, mais ils ont besoin de quelques correctifs de noyau (dont beaucoup sont des correctifs trouvés par Google en jouant avec des périphériques en boucle). [3] [4]
Sources [0], [1], [2], [3], [4]