Le format de conteneur Android Pony EXpress (APEX) a été introduit dans Android 10 et il est utilisé dans le flux d'installation des modules système de niveau inférieur. Ce format facilite les mises à jour des composants du système qui ne correspondent pas au modèle d'application Android standard. Certains exemples de composants sont les services et bibliothèques natifs, les couches d'abstraction matérielles ( HAL ), le runtime ( ART ) et les bibliothèques de classes.
Le terme "APEX" peut également faire référence à un fichier APEX.
Arrière-plan
Bien qu'Android prenne en charge les mises à jour de modules qui correspondent au modèle d'application standard (par exemple, services, activités) via des applications d'installation de packages (telles que l'application Google Play Store), l'utilisation d'un modèle similaire pour les composants de système d'exploitation de niveau inférieur présente les inconvénients suivants :
- Les modules basés sur APK ne peuvent pas être utilisés au début de la séquence de démarrage. Le gestionnaire de packages est le référentiel central d'informations sur les applications et ne peut être démarré qu'à partir du gestionnaire d'activités, qui devient prêt à une étape ultérieure de la procédure de démarrage.
- Le format APK (en particulier le manifeste) est conçu pour les applications Android et les modules système ne sont pas toujours adaptés.
Conception
Cette section décrit la conception de haut niveau du format de fichier APEX et du gestionnaire APEX, qui est un service qui gère les fichiers APEX.
Pour plus d'informations sur la raison pour laquelle cette conception pour APEX a été sélectionnée, voir Alternatives envisagées lors du développement d'APEX .
Format Apex
C'est le format d'un fichier APEX.
Figure 1. Format de fichier APEX
Au niveau supérieur, un fichier APEX est un fichier zip dans lequel les fichiers sont stockés non compressés et situés à des limites de 4 Ko.
Les quatre fichiers d'un fichier APEX sont :
-
apex_manifest.json
-
AndroidManifest.xml
-
apex_payload.img
-
apex_pubkey
Le fichier apex_manifest.json
contient le nom et la version du package, qui identifient un fichier APEX. Il s'agit d'un tampon de protocole ApexManifest
au format JSON.
Le fichier AndroidManifest.xml
permet au fichier APEX d'utiliser des outils et une infrastructure liés à APK tels que ADB, PackageManager et des applications d'installation de packages (telles que Play Store). Par exemple, le fichier APEX peut utiliser un outil existant tel que aapt
pour inspecter les métadonnées de base du fichier. Le fichier contient le nom du package et les informations de version. Ces informations sont généralement également disponibles dans apex_manifest.json
.
apex_manifest.json
est recommandé sur AndroidManifest.xml
pour le nouveau code et les systèmes qui traitent APEX. AndroidManifest.xml
peut contenir des informations de ciblage supplémentaires pouvant être utilisées par les outils de publication d'applications existants.
apex_payload.img
est une image de système de fichiers ext4 soutenue par dm-verity. L'image est montée au moment de l'exécution via un périphérique de bouclage. Plus précisément, l'arbre de hachage et le bloc de métadonnées sont créés à l'aide de la bibliothèque libavb
. La charge utile du système de fichiers n'est pas analysée (car l'image doit pouvoir être montée sur place). Les fichiers normaux sont inclus dans le fichier apex_payload.img
.
apex_pubkey
est la clé publique utilisée pour signer l'image du système de fichiers. Lors de l'exécution, cette clé garantit que l'APEX téléchargé est signé avec la même entité qui signe le même APEX dans les partitions intégrées.
Directives de dénomination APEX
Pour aider à éviter les conflits de nom entre les nouveaux APEX à mesure que la plate-forme progresse, utilisez les directives de nommage suivantes :
-
com.android.*
- Réservé aux APEX AOSP. Pas unique à une entreprise ou à un appareil.
-
com.<companyname>.*
- Réservé à une entreprise. Potentiellement utilisé par plusieurs appareils de cette société.
-
com.<companyname>.<devicename>.*
- Réservé aux APEX propres à un appareil spécifique (ou sous-ensemble d'appareils).
Responsable APEX
Le gestionnaire APEX (ou apexd
) est un processus natif autonome responsable de la vérification, de l'installation et de la désinstallation des fichiers APEX. Ce processus est lancé et prêt au début de la séquence de démarrage. Les fichiers APEX sont normalement préinstallés sur l'appareil sous /system/apex
. Le gestionnaire APEX utilise par défaut ces packages si aucune mise à jour n'est disponible.
La séquence de mise à jour d'un APEX utilise la classe PackageManager et est la suivante.
- Un fichier APEX est téléchargé via une application d'installation de package, ADB ou une autre source.
- Le gestionnaire de paquets lance la procédure d'installation. Dès qu'il reconnaît que le fichier est un APEX, le gestionnaire de packages transfère le contrôle au gestionnaire APEX.
- Le gestionnaire APEX vérifie le fichier APEX.
- Si le fichier APEX est vérifié, la base de données interne du gestionnaire APEX est mise à jour pour indiquer que le fichier APEX est activé au prochain démarrage.
- Le demandeur d'installation reçoit une diffusion lors de la vérification réussie du package.
- Pour poursuivre l'installation, le système doit être redémarré.
Au prochain démarrage, le gestionnaire APEX démarre, lit la base de données interne et effectue les opérations suivantes pour chaque fichier APEX répertorié :
- Vérifie le fichier APEX.
- Crée un périphérique de bouclage à partir du fichier APEX.
- Crée un périphérique de bloc mappeur de périphérique au-dessus du périphérique de bouclage.
- Monte le périphérique de bloc du mappeur de périphérique sur un chemin unique (par exemple,
/apex/ name @ ver
).
Lorsque tous les fichiers APEX répertoriés dans la base de données interne sont montés, le gestionnaire APEX fournit un service de classeur permettant aux autres composants du système de demander des informations sur les fichiers APEX installés. Par exemple, les autres composants du système peuvent interroger la liste des fichiers APEX installés sur l'appareil ou interroger le chemin exact où un APEX spécifique est monté, afin que les fichiers soient accessibles.
Les fichiers APEX sont des fichiers APK
Les fichiers APEX sont des fichiers APK valides, car ce sont des archives zip signées (utilisant le schéma de signature APK) contenant un fichier AndroidManifest.xml
. Cela permet aux fichiers APEX d'utiliser l'infrastructure pour les fichiers APK, comme une application d'installation de package, l'utilitaire de signature et le gestionnaire de packages.
Le fichier AndroidManifest.xml
à l'intérieur d'un fichier APEX est minime, composé du name
du package , versionCode
et facultatif targetSdkVersion
, minSdkVersion
et maxSdkVersion
pour un ciblage précis. Ces informations permettent aux fichiers APEX d'être livrés via des canaux existants tels que les applications d'installation de packages et ADB.
Types de fichiers pris en charge
Le format APEX prend en charge ces types de fichiers :
- Bibliothèques partagées natives
- Exécutables natifs
- Fichiers JAR
- Fichiers de données
- Fichiers de configuration
Cela ne signifie pas qu'APEX peut mettre à jour tous ces types de fichiers. La possibilité de mettre à jour un type de fichier dépend de la plate-forme et de la stabilité des définitions des interfaces pour les types de fichiers.
Options de signature
Les fichiers APEX sont signés de deux manières. Tout d'abord, le fichier apex_payload.img
(en particulier, le descripteur vbmeta ajouté à apex_payload.img
) est signé avec une clé. Ensuite, l'intégralité de l'APEX est signée à l'aide du schéma de signature APK v3 . Deux clés différentes sont utilisées dans ce processus.
Côté appareil, une clé publique correspondant à la clé privée utilisée pour signer le descripteur vbmeta est installée. Le gestionnaire APEX utilise la clé publique pour vérifier les APEX dont l'installation est demandée. Chaque APEX doit être signé avec des clés différentes et est appliqué à la fois au moment de la génération et de l'exécution.
APEX dans les cloisons intégrées
Les fichiers APEX peuvent être situés dans des partitions intégrées telles que /system
. La partition est déjà sur dm-verity, donc les fichiers APEX sont montés directement sur le périphérique de bouclage.
Si un APEX est présent dans une partition intégrée, l'APEX peut être mis à jour en fournissant un package APEX avec le même nom de package et un code de version supérieur ou égal à. Le nouvel APEX est stocké dans /data
et, comme pour les APK, la version nouvellement installée masque la version déjà présente dans la partition intégrée. Mais contrairement aux APK, la version nouvellement installée de l'APEX n'est activée qu'après le redémarrage.
Exigences du noyau
Pour prendre en charge les modules principaux APEX sur un appareil Android, les fonctionnalités suivantes du noyau Linux sont requises : le pilote de bouclage et dm-verity. Le pilote de bouclage monte l'image du système de fichiers dans un module APEX et dm-verity vérifie le module APEX.
Les performances du pilote de bouclage et de dm-verity sont importantes pour obtenir de bonnes performances système lors de l'utilisation de modules APEX.
Versions de noyau prises en charge
Les modules principaux APEX sont pris en charge sur les appareils utilisant les versions de noyau 4.4 ou supérieures. Les nouveaux appareils lancés avec Android 10 ou supérieur doivent utiliser la version 4.9 ou supérieure du noyau pour prendre en charge les modules APEX.
Correctifs de noyau requis
Les correctifs de noyau requis pour la prise en charge des modules APEX sont inclus dans l'arborescence commune d'Android. Pour obtenir les correctifs pour prendre en charge APEX, utilisez la dernière version de l'arborescence commune Android.
Version du noyau 4.4
Cette version est uniquement prise en charge pour les appareils mis à niveau d'Android 9 vers Android 10 et qui souhaitent prendre en charge les modules APEX. Pour obtenir les correctifs requis, une fusion descendante à partir de la branche android-4.4
est fortement recommandée. Voici une liste des correctifs individuels requis pour la version 4.4 du noyau.
- AMONT : boucle : ajoutez ioctl pour modifier la taille du bloc logique ( 4.4 )
- BACKPORT : bloc/boucle : définir hw_sectors ( 4.4 )
- AMONT : boucle : ajouter LOOP_SET_BLOCK_SIZE dans l'ioctl compatible ( 4.4 )
- ANDROID : mnt : correction de next_descendent ( 4.4 )
- ANDROID : mnt : le remontage doit se propager aux esclaves des esclaves ( 4.4 )
- ANDROID : mnt : Propager le remontage correctement ( 4.4 )
- Rétablir "ANDROID : dm verity : ajouter une taille de prélecture minimale" ( 4.4 )
- AMONT : boucle : supprimer les caches si l'offset ou la taille de bloc sont modifiés ( 4.4 )
Versions du noyau 4.9/4.14/4.19
Pour obtenir les correctifs requis pour les versions de noyau 4.9/4.14/4.19, effectuez une fusion descendante à partir de la branche android-common
.
Options de configuration du noyau requises
La liste suivante indique les exigences de configuration de base pour la prise en charge des modules APEX qui ont été introduits dans Android 10. Les éléments suivis d'un astérisque (*) sont les exigences existantes d'Android 9 et des versions antérieures.
(*) CONFIG_AIO=Y # AIO support (for direct I/O on loop devices)
CONFIG_BLK_DEV_LOOP=Y # for loop device support
CONFIG_BLK_DEV_LOOP_MIN_COUNT=16 # pre-create 16 loop devices
(*) CONFIG_CRYPTO_SHA1=Y # SHA1 hash for DM-verity
(*) CONFIG_CRYPTO_SHA256=Y # SHA256 hash for DM-verity
CONFIG_DM_VERITY=Y # DM-verity support
Configuration requise pour les paramètres de ligne de commande du noyau
Pour prendre en charge APEX, assurez-vous que les paramètres de ligne de commande du noyau répondent aux exigences suivantes :
-
loop.max_loop
ne doit PAS être défini -
loop.max_part
doit être <= 8
Construire un APEX
Cette section décrit comment créer un APEX à l'aide du système de génération Android. Voici un exemple d' Android.bp
pour un APEX nommé apex.test
.
apex {
name: "apex.test",
manifest: "apex_manifest.json",
file_contexts: "file_contexts",
// libc.so and libcutils.so are included in the apex
native_shared_libs: ["libc", "libcutils"],
binaries: ["vold"],
java_libs: ["core-all"],
prebuilts: ["my_prebuilt"],
compile_multilib: "both",
key: "apex.test.key",
certificate: "platform",
}
Exemple apex_manifest.json
:
{
"name": "com.android.example.apex",
"version": 1
}
exemple file_contexts
:
(/.*)? u:object_r:system_file:s0
/sub(/.*)? u:object_r:sub_file:s0
/sub/file3 u:object_r:file3_file:s0
Types de fichiers et emplacements dans APEX
Type de fichier | Emplacement dans l'APEX |
---|---|
Bibliothèques partagées | /lib et /lib64 ( /lib/arm pour le bras traduit en x86) |
Exécutables | /bin |
Bibliothèques Java | /javalib |
Préconstruits | /etc |
Dépendances transitives
Les fichiers APEX incluent automatiquement les dépendances transitives des bibliothèques partagées natives ou des exécutables. Par exemple, si libFoo
dépend de libBar
, les deux bibliothèques sont incluses lorsque seul libFoo
est répertorié dans la propriété native_shared_libs
.
Gérer plusieurs ABI
Installez la propriété native_shared_libs
pour les interfaces binaires d'application (ABI) principale et secondaire du périphérique. Si un APEX cible des périphériques avec un seul ABI (c'est-à-dire 32 bits uniquement ou 64 bits uniquement), seules les bibliothèques avec l'ABI correspondant sont installées.
Installez la propriété binaries
uniquement pour l'ABI principal de l'appareil, comme décrit ci-dessous :
- Si le périphérique est uniquement 32 bits, seule la variante 32 bits du binaire est installée.
- Si le périphérique est uniquement 64 bits, seule la variante 64 bits du binaire est installée.
Pour ajouter un contrôle précis sur les ABI des bibliothèques natives et des binaires, utilisez les propriétés multilib.[first|lib32|lib64|prefer32|both].[native_shared_libs|binaries]
.
-
first
: correspond à l'ABI principal de l'appareil. C'est la valeur par défaut pour les binaires. -
lib32
: correspond à l'ABI 32 bits de l'appareil, si pris en charge. -
lib64
: correspond à l'ABI 64 bits de l'appareil, il est pris en charge. -
prefer32
: correspond à l'ABI 32 bits de l'appareil, si pris en charge. Si l'ABI 32 bits n'est pas pris en charge, correspond à l'ABI 64 bits. -
both
: Correspond aux deux ABI. C'est la valeur par défaut pournative_shared_libraries
.
Les propriétés java
, libraries
et prebuilts
sont indépendantes de l'ABI.
Cet exemple concerne un appareil qui prend en charge 32/64 et ne préfère pas 32 :
apex {
// other properties are omitted
native_shared_libs: ["libFoo"], // installed for 32 and 64
binaries: ["exec1"], // installed for 64, but not for 32
multilib: {
first: {
native_shared_libs: ["libBar"], // installed for 64, but not for 32
binaries: ["exec2"], // same as binaries without multilib.first
},
both: {
native_shared_libs: ["libBaz"], // same as native_shared_libs without multilib
binaries: ["exec3"], // installed for 32 and 64
},
prefer32: {
native_shared_libs: ["libX"], // installed for 32, but not for 64
},
lib64: {
native_shared_libs: ["libY"], // installed for 64, but not for 32
},
},
}
signature vbmeta
Signez chaque APEX avec des clés différentes. Lorsqu'une nouvelle clé est requise, créez une paire de clés publique-privée et créez un module apex_key
. Utilisez la propriété key
pour signer l'APEX à l'aide de la clé. La clé publique est automatiquement incluse dans l'APEX avec le nom avb_pubkey
.
# create an rsa key pairopenssl genrsa -out foo.pem 4096
# extract the public key from the key pairavbtool extract_public_key --key foo.pem --output foo.avbpubkey
# in Android.bpapex_key { name: "apex.test.key", public_key: "foo.avbpubkey", private_key: "foo.pem", }
Dans l'exemple ci-dessus, le nom de la clé publique ( foo
) devient l'ID de la clé. L'ID de la clé utilisée pour signer un APEX est écrit dans l'APEX. Lors de l'exécution, apexd
vérifie l'APEX à l'aide d'une clé publique avec le même ID dans l'appareil.
Signature APEX
Signez les APEX de la même manière que vous signez les APK. signer les APEX deux fois ; une fois pour le mini système de fichiers (fichier apex_payload.img
) et une fois pour le fichier entier.
Pour signer un APEX au niveau du fichier, définissez la propriété certificate
de l'une des trois manières suivantes :
- Non défini : si aucune valeur n'est définie, l'APEX est signé avec le certificat situé dans
PRODUCT_DEFAULT_DEV_CERTIFICATE
. Si aucun indicateur n'est défini, le chemin par défaut estbuild/target/product/security/testkey
. -
<name>
: L'APEX est signé avec le certificat<name>
dans le même répertoire quePRODUCT_DEFAULT_DEV_CERTIFICATE
. -
:<name>
: L'APEX est signé avec le certificat défini par le module Soong nommé<name>
. Le module de certificat peut être défini comme suit.
android_app_certificate {
name: "my_key_name",
certificate: "dir/cert",
// this will use dir/cert.x509.pem (the cert) and dir/cert.pk8 (the private key)
}
Installer un APEX
Pour installer un APEX, utilisez ADB.
adb install apex_file_name
adb reboot
Si supportsRebootlessUpdate
est défini sur true
dans apex_manifest.json
et que l'APEX actuellement installé n'est pas utilisé (par exemple, tous les services qu'il contient ont été arrêtés), un nouvel APEX peut être installé sans redémarrage avec l'indicateur --force-non-staged
.
adb install --force-non-staged apex_file_name
Utiliser un APEX
Après le redémarrage, l'APEX est monté dans le répertoire /apex/<apex_name>@<version>
. Plusieurs versions du même APEX peuvent être montées en même temps. Parmi les chemins de montage, celui qui correspond à la dernière version est monté en liaison sur /apex/<apex_name>
.
Les clients peuvent utiliser le chemin d'accès monté sur liaison pour lire ou exécuter des fichiers à partir d'APEX.
Les APEX sont généralement utilisés comme suit :
- Un OEM ou un ODM précharge un APEX sous
/system/apex
lorsque l'appareil est expédié. - Les fichiers dans l'APEX sont accessibles via le chemin
/apex/<apex_name>/
. - Lorsqu'une version mise à jour de l'APEX est installée dans
/data/apex
, le chemin pointe vers le nouvel APEX après le redémarrage.
Mettre à jour un service avec un APEX
Pour mettre à jour un service à l'aide d'un APEX :
Marquez le service dans la partition système comme pouvant être mis à jour. Ajoutez l'option
updatable
à la définition de service./system/etc/init/myservice.rc: service myservice /system/bin/myservice class core user system ... updatable
Créez un nouveau fichier
.rc
pour le service mis à jour. Utilisez l'optionoverride
pour redéfinir le service existant./apex/my.apex/etc/init.rc: service myservice /apex/my.apex/bin/myservice class core user system ... override
Les définitions de service ne peuvent être définies que dans le fichier .rc
d'un APEX. Les déclencheurs d'action ne sont pas pris en charge dans les APEX.
Si un service marqué comme pouvant être mis à jour démarre avant l'activation des APEX, le démarrage est retardé jusqu'à ce que l'activation des APEX soit terminée.
Configurer le système pour prendre en charge les mises à jour APEX
Définissez la propriété système suivante sur true
pour prendre en charge les mises à jour de fichiers APEX.
<device.mk>:
PRODUCT_PROPERTY_OVERRIDES += ro.apex.updatable=true
BoardConfig.mk:
TARGET_FLATTEN_APEX := false
ou juste
<device.mk>:
$(call inherit-product, $(SRC_TARGET_DIR)/product/updatable_apex.mk)
APEX aplati
Pour les appareils hérités, il est parfois impossible ou infaisable de mettre à jour l'ancien noyau pour prendre pleinement en charge APEX. Par exemple, le noyau peut avoir été construit sans CONFIG_BLK_DEV_LOOP=Y
, ce qui est crucial pour monter l'image du système de fichiers dans un APEX.
L'APEX aplati est un APEX spécialement conçu qui peut être activé sur les appareils avec un noyau hérité. Les fichiers d'un APEX aplati sont directement installés dans un répertoire sous la partition intégrée. Par exemple, lib/libFoo.so
dans un APEX aplati my.apex
est installé sur /system/apex/my.apex/lib/libFoo.so
.
L'activation d'un APEX aplati n'implique pas le périphérique de boucle. L'ensemble du répertoire /system/apex/my.apex
est directement monté en liaison sur /apex/name@ver
.
Les APEX aplatis ne peuvent pas être mis à jour en téléchargeant des versions mises à jour des APEX à partir du réseau, car les APEX téléchargés ne peuvent pas être aplatis. Les APEX aplatis ne peuvent être mis à jour que via un OTA standard.
APEX aplati est la configuration par défaut. Cela signifie que tous les APEX sont aplatis par défaut, sauf si vous configurez explicitement votre appareil pour créer des APEX non aplatis afin de prendre en charge les mises à jour APEX (comme expliqué ci-dessus).
Le mélange d'APEX aplatis et non aplatis dans un appareil n'est PAS pris en charge. Les APEX d'un appareil doivent être soit tous non aplatis, soit tous aplatis. Ceci est particulièrement important lors de l'expédition de pré-construits APEX pré-signés pour des projets tels que Mainline. Les APEX qui ne sont pas pré-signés (c'est-à-dire construits à partir de la source) doivent également être non aplatis et signés avec les clés appropriées. L'appareil doit hériter de updatable_apex.mk
comme expliqué dans Mise à jour d'un service avec un APEX .
APEX compressés
Android 12 et versions ultérieures disposent de la compression APEX pour réduire l'impact sur le stockage des packages APEX pouvant être mis à jour. Après l'installation d'une mise à jour d'un APEX, bien que sa version préinstallée ne soit plus utilisée, elle occupe toujours la même quantité d'espace. Cet espace occupé reste indisponible.
La compression APEX minimise cet impact sur le stockage en utilisant un ensemble hautement compressé de fichiers APEX sur des partitions en lecture seule (telles que la partition /system
). Android 12 et versions ultérieures utilisent un algorithme de compression zip DEFLATE.
La compression n'optimise pas les éléments suivants :
Bootstrap APEX qui doivent être montés très tôt dans la séquence de démarrage.
APEX non modifiables. La compression n'est utile que si une version mise à jour d'un APEX est installée sur la partition
/data
. Une liste complète des APEX pouvant être mis à jour est disponible sur la page Composants du système modulaire .Bibliothèques partagées dynamiques APEX. Étant donné que
apexd
active toujours les deux versions de ces APEX (préinstallées et mises à niveau), les compresser n'ajoute aucune valeur.
Format de fichier APEX compressé
Il s'agit du format d'un fichier APEX compressé.
Figure 2. Format de fichier APEX compressé
Au niveau supérieur, un fichier APEX compressé est un fichier zip contenant le fichier apex d'origine sous forme dégonflée avec un niveau de compression de 9, et avec d'autres fichiers stockés non compressés.
Quatre fichiers composent un fichier APEX :
-
original_apex
: dégonflé avec un niveau de compression de 9 Il s'agit du fichier APEX d'origine non compressé . -
apex_manifest.pb
: stocké uniquement -
AndroidManifest.xml
: stocké uniquement -
apex_pubkey
: stocké uniquement
Les fichiers apex_manifest.pb
, AndroidManifest.xml
et apex_pubkey
sont des copies de leurs fichiers correspondants dans original_apex
.
Construire APEX compressé
L'APEX compressé peut être créé à l'aide de l'outil apex_compression_tool.py
situé dans system/apex/tools
.
Plusieurs paramètres liés à la compression APEX sont disponibles dans le système de construction.
Dans Android.bp
, le fait qu'un fichier APEX soit compressible est contrôlé par la propriété compressible
:
apex {
name: "apex.test",
manifest: "apex_manifest.json",
file_contexts: "file_contexts",
compressible: true,
}
Un indicateur de produit PRODUCT_COMPRESSED_APEX
contrôle si une image système créée à partir de la source doit contenir des fichiers APEX compressés.
Pour une expérimentation locale, vous pouvez forcer une build à compresser les APEX en définissant OVERRIDE_PRODUCT_COMPRESSED_APEX=
sur true
.
Les fichiers APEX compressés générés par le système de génération ont l'extension .capex
. L'extension facilite la distinction entre les versions compressées et non compressées d'un fichier APEX.
Algorithmes de compression pris en charge
Android 12 ne prend en charge que la compression deflate-zip.
Activer un fichier APEX compressé au démarrage
Avant qu'un APEX compressé puisse être activé, le fichier original_apex
qu'il contient est décompressé dans le répertoire /data/apex/decompressed
. Le fichier APEX décompressé résultant est lié en dur au répertoire /data/apex/active
.
Considérez l'exemple suivant comme une illustration du processus décrit ci-dessus.
Considérez /system/apex/com.android.foo.capex
comme un APEX compressé activé, avec versionCode 37.
- Le fichier
original_apex
dans/system/apex/com.android.foo.capex
est décompressé en/data/apex/decompressed/com.android.foo@37.apex
. -
restorecon /data/apex/decompressed/com.android.foo@37.apex
est exécuté pour vérifier qu'il a une étiquette SELinux correcte. - Des contrôles de vérification sont effectués sur
/data/apex/decompressed/com.android.foo@37.apex
pour garantir sa validité :apexd
vérifie la clé publique fournie dans/data/apex/decompressed/com.android.foo@37.apex
pour vérifiez qu'il est égal à celui fourni dans/system/apex/com.android.foo.capex
. - Le fichier
/data/apex/decompressed/com.android.foo@37.apex
est lié en dur au répertoire/data/apex/active/com.android.foo@37.apex
. - La logique d'activation régulière pour les fichiers APEX non compressés est effectuée sur
/data/apex/active/com.android.foo@37.apex
.
Interaction avec OTA
Les fichiers APEX compressés ont des implications sur la livraison et l'application OTA. Étant donné qu'une mise à jour OTA peut contenir un fichier APEX compressé avec un niveau de version supérieur à celui qui est actif sur un appareil, une certaine quantité d'espace libre doit être réservée avant qu'un appareil ne soit redémarré pour appliquer une mise à jour OTA.
Pour prendre en charge le système OTA, apexd
expose ces deux API de classeur :
-
calculateSizeForCompressedApex
- calcule la taille requise pour décompresser les fichiers APEX dans un package OTA. Cela peut être utilisé pour vérifier qu'un appareil dispose de suffisamment d'espace avant qu'un OTA ne soit téléchargé. -
reserveSpaceForCompressedApex
- réserve de l'espace sur le disque pour une utilisation future parapexd
pour décompresser les fichiers APEX compressés à l'intérieur du package OTA.
Dans le cas d'une mise à jour OTA A/B, apexd
tente une décompression en arrière-plan dans le cadre de la routine OTA post-installation. Si la décompression échoue, apexd
effectue la décompression lors du démarrage qui applique la mise à jour OTA.
Alternatives envisagées lors du développement d'APEX
Voici quelques options prises en compte par AOSP lors de la conception du format de fichier APEX, et pourquoi elles ont été incluses ou exclues.
Systèmes de gestion de colis réguliers
Les distributions Linux ont des systèmes de gestion de paquets comme dpkg
et rpm
, qui sont puissants, matures et robustes. Cependant, ils n'ont pas été adoptés pour APEX car ils ne peuvent pas protéger les packages après l'installation. La vérification est effectuée uniquement lorsque les packages sont en cours d'installation. Les attaquants peuvent briser l'intégrité des packages installés, sans être remarqués. Il s'agit d'une régression pour Android où tous les composants du système étaient stockés dans des systèmes de fichiers en lecture seule dont l'intégrité est protégée par dm-verity pour chaque E/S. Toute altération des composants du système doit soit être interdite, soit être détectable afin que l'appareil puisse refuser de démarrer s'il est compromis.
dm-crypt pour l'intégrité
Les fichiers d'un conteneur APEX proviennent de partitions intégrées (par exemple, la partition /system
) qui sont protégées par dm-verity, où toute modification des fichiers est interdite même après le montage des partitions. Pour fournir le même niveau de sécurité aux fichiers, tous les fichiers d'un APEX sont stockés dans une image de système de fichiers associée à un arbre de hachage et à un descripteur vbmeta. Sans dm-verity, un APEX dans la partition /data
est vulnérable aux modifications involontaires apportées après avoir été vérifié et installé.
En fait, la partition /data
est également protégée par des couches de chiffrement telles que dm-crypt. Bien que cela offre un certain niveau de protection contre la falsification, son objectif principal est la confidentialité et non l'intégrité. Lorsqu'un attaquant accède à la partition /data
, il ne peut plus y avoir de protection supplémentaire, et il s'agit là encore d'une régression par rapport à chaque composant système se trouvant dans la partition /system
. L'arbre de hachage à l'intérieur d'un fichier APEX avec dm-verity fournit le même niveau de protection du contenu.
Rediriger les chemins de /system vers /apex
Les fichiers de composants système empaquetés dans un APEX sont accessibles via de nouveaux chemins comme /apex/<name>/lib/libfoo.so
. Lorsque les fichiers faisaient partie de la partition /system
, ils étaient accessibles via des chemins tels que /system/lib/libfoo.so
. Un client d'un fichier APEX (autres fichiers APEX ou la plateforme) doit utiliser les nouveaux chemins. Vous devrez peut-être mettre à jour le code existant à la suite du changement de chemin.
Bien qu'une façon d'éviter le changement de chemin consiste à superposer le contenu du fichier dans un fichier APEX sur la partition /system
, l'équipe Android a décidé de ne pas superposer les fichiers sur la partition /system
car cela pourrait avoir un impact sur les performances car le nombre de fichiers superposés ( peut-être même empilés les uns après les autres) augmenté.
Une autre option consistait à détourner les fonctions d'accès aux fichiers telles que open
, stat
et readlink
, afin que les chemins commençant par /system
soient redirigés vers leurs chemins correspondants sous /apex
. L'équipe Android a rejeté cette option car il est impossible de modifier toutes les fonctions qui acceptent les chemins. Par exemple, certaines applications lient statiquement Bionic, qui implémente les fonctions. Dans de tels cas, ces applications ne sont pas redirigées.