Les mises à jour système dynamiques (DSU) vous permettent de créer une image système Android que les utilisateurs peuvent télécharger sur Internet et essayer sans risquer de corrompre l'image système actuelle. Ce document explique comment prendre en charge DSU.
Exigences concernant le noyau
Pour connaître les exigences du noyau, consultez Implémenter des partitions dynamiques.
De plus, DSU s'appuie sur la fonctionnalité de noyau device-mapper-verity (dm-verity) pour vérifier l'image système Android. Vous devez donc activer les configurations de noyau suivantes :
CONFIG_DM_VERITY=yCONFIG_DM_VERITY_FEC=y
Exigences concernant les partitions
À partir d'Android 11, DSU exige que la partition /data utilise le système de fichiers F2FS ou ext4. F2FS offre de meilleures performances et est recommandé, mais la différence devrait être insignifiante.
Voici quelques exemples de la durée d'une mise à jour dynamique du système sur un appareil Pixel :
- Utiliser F2FS :
- 109s, 8G user, 867M system, type de système de fichiers : F2FS : encryption=aes-256-xts:aes-256-cts
- 104s, 8G user, 867M system, type de système de fichiers : F2FS : encryption=ice
- Utiliser ext4 :
- 135s, 8G user, 867M system, type de système de fichiers : ext4 : encryption=aes-256-xts:aes-256-cts
Si cela prend beaucoup plus de temps sur votre plate-forme, vous pouvez vérifier si l'indicateur de montage contient un indicateur qui effectue une écriture "sync", ou vous pouvez spécifier explicitement un indicateur "async" pour obtenir de meilleures performances.
La partition metadata (16 Mo ou plus) est requise pour stocker les données liées aux images installées. Il doit être monté lors du montage de la première étape.
La partition userdata doit utiliser le système de fichiers F2FS ou ext4. Lorsque vous utilisez F2FS, incluez tous les correctifs F2FS disponibles dans le noyau commun Android.
DSU a été développé et testé avec kernel/common 4.9. Nous vous recommandons d'utiliser le noyau 4.9 ou une version ultérieure pour cette fonctionnalité.
Comportement du HAL du fournisseur
Weaver HAL
Le HAL de tissage fournit un nombre fixe d'emplacements pour stocker les clés utilisateur. Le DSU consomme deux emplacements de clé supplémentaires. Si un OEM dispose d'une HAL weaver, il doit disposer de suffisamment d'emplacements pour une image système générique (GSI) et une image hôte.
Gatekeeper HAL
Le HAL Gatekeeper doit accepter les grandes valeurs USER_ID, car la GSI déplace les UID vers le HAL de +1 000 000.
Démarrage validé
Si vous souhaitez prendre en charge le démarrage des images GSI pour les développeurs en état VERROUILLÉ sans désactiver le démarrage sécurisé, incluez les clés GSI pour les développeurs en ajoutant la ligne suivante au fichier device/<device_name>/device.mk :
$(call inherit-product, $(SRC_TARGET_DIR)/product/developer_gsi_keys.mk)
Protection contre le rollback
Lorsque vous utilisez DSU, l'image système Android téléchargée doit être plus récente que l'image système actuelle sur l'appareil. Pour ce faire, comparez les niveaux de correctifs de sécurité dans le démarrage validé Android (AVB) descripteur de propriété AVB des deux images système : Prop: com.android.build.system.security_patch ->
'2019-04-05'.
Pour les appareils n'utilisant pas AVB, indiquez le niveau du correctif de sécurité de l'image système actuelle dans la ligne de commande du noyau ou la configuration de démarrage avec le bootloader : androidboot.system.security_patch=2019-04-05.
Configuration matérielle requise
Lorsque vous lancez une instance DSU, deux fichiers temporaires sont alloués :
- Une partition logique pour stocker
GSI.img(1 à 1,5 Go) - Une partition
/datavide de 8 Go servant de bac à sable pour exécuter la GSI
Nous vous recommandons de réserver au moins 10 Go d'espace libre avant de lancer une instance DSU. DSU prend également en charge l'allocation à partir d'une carte SD. Lorsqu'une carte SD est présente, elle a la priorité absolue pour l'allocation. La prise en charge des cartes SD est essentielle pour les appareils moins puissants qui ne disposent pas de suffisamment de mémoire de stockage interne. Si une carte SD est présente, assurez-vous qu'elle n'est pas adoptée. DSU ne prend pas en charge les cartes SD adoptées.
Interfaces disponibles
Vous pouvez lancer DSU à l'aide de adb, d'une application OEM ou du programme de chargement DSU en un clic (dans Android 11 ou version ultérieure).
Lancer DSU à l'aide d'adb
Pour lancer DSU à l'aide d'adb, saisissez les commandes suivantes :
$ simg2img out/target/product/.../system.img system.raw
$ gzip -c system.raw > system.raw.gz
$ adb push system.raw.gz /storage/emulated/0/Download
$ adb shell am start-activity \
-n com.android.dynsystem/com.android.dynsystem.VerificationActivity \
-a android.os.image.action.START_INSTALL \
-d file:///storage/emulated/0/Download/system.raw.gz \
--el KEY_SYSTEM_SIZE $(du -b system.raw|cut -f1) \
--el KEY_USERDATA_SIZE 8589934592
Lancer DSU à l'aide d'une application
Le principal point d'entrée de DSU est l'API android.os.image.DynamicSystemClient.java :
public class DynamicSystemClient {
...
...
/**
* Start installing DynamicSystem from URL with default userdata size.
*
* @param systemUrl A network URL or a file URL to system image.
* @param systemSize size of system image.
*/
public void start(String systemUrl, long systemSize) {
start(systemUrl, systemSize, DEFAULT_USERDATA_SIZE);
}
Vous devez regrouper/préinstaller cette application sur l'appareil. Étant donné que DynamicSystemClient est une API système, vous ne pouvez pas créer l'application avec l'API SDK habituelle ni la publier sur Google Play. L'objectif de cette application est le suivant :
- Récupérez une liste d'images et l'URL correspondante avec un schéma défini par le fournisseur.
- Faites correspondre les images de la liste à l'appareil et affichez les images compatibles que l'utilisateur peut sélectionner.
Appelez
DynamicSystemClient.startcomme suit :DynamicSystemClient aot = new DynamicSystemClient(...) aot.start( ...URL of the selected image..., ...uncompressed size of the selected image...);
L'URL pointe vers un fichier image système compressé au format gzip et non éparse, que vous pouvez créer à l'aide des commandes suivantes :
$ simg2img ${OUT}/system.img ${OUT}/system.raw
$ gzip ${OUT}/system.raw
$ ls ${OUT}/system.raw.gz
Le nom du fichier doit respecter le format suivant :
<android version>.<lunch name>.<user defined title>.raw.gz
Exemples :
o.aosp_taimen-userdebug.2018dev.raw.gzp.aosp_taimen-userdebug.2018dev.raw.gz
Chargeur DSU en un clic
Android 11 introduit le chargeur DSU en un clic, qui est un frontend dans les paramètres du développeur.
Figure 1 : Lancer le chargeur DSU
Lorsque le développeur clique sur le bouton DSU Loader, il récupère un descripteur JSON DSU préconfiguré sur le Web et affiche toutes les images applicables dans le menu flottant. Sélectionnez une image pour lancer l'installation de la mise à jour du système dynamique. La progression s'affiche dans la barre de notification.
Figure 2. Progression de l'installation de l'image DSU
Par défaut, le chargeur DSU charge un descripteur JSON contenant les images GSI. Les sections suivantes expliquent comment créer des packages DSU signés par l'OEM et les charger à partir du chargeur DSU.
Flag de fonctionnalité
La fonctionnalité DSU est associée au flag de fonctionnalité settings_dynamic_android. Avant d'utiliser DSU, assurez-vous que le flag de fonctionnalité correspondant est activé.
Figure 3. Activer le flag de fonctionnalité
L'UI des indicateurs de fonctionnalité peut ne pas être disponible sur un appareil exécutant une version utilisateur. Dans ce cas, utilisez plutôt la commande adb :
$ adb shell setprop persist.sys.fflag.override.settings_dynamic_system 1
Images système hôtes du fournisseur sur GCE (facultatif)
L'un des emplacements de stockage possibles pour les images système est le bucket Google Compute Engine (GCE). L'administrateur des versions utilise la console de stockage GCP pour ajouter, supprimer ou modifier l'image système publiée.
Les images doivent être accessibles au public, comme indiqué ci-dessous :
Figure 4. Accès public dans GCE
La procédure permettant de rendre un élément public est disponible dans la documentation Google Cloud.
DSU à partitions multiples dans un fichier ZIP
À partir d'Android 11, DSU peut comporter plusieurs partitions. Par exemple, il peut contenir un product.img en plus du system.img. Lorsque l'appareil démarre, la première étape init détecte les partitions DSU installées et remplace temporairement la partition sur l'appareil lorsque le DSU installé est activé. Le package DSU peut contenir une partition qui n'a pas de partition correspondante sur l'appareil.
Figure 5. Processus DSU avec plusieurs partitions
DSU signé par l'OEM
Pour s'assurer que toutes les images exécutées sur l'appareil sont autorisées par le fabricant de l'appareil, toutes les images d'un package DSU doivent être signées. Par exemple, supposons qu'il existe un package DSU contenant deux images de partition comme ci-dessous :
dsu.zip {
- system.img
- product.img
}
system.img et product.img doivent être signés par la clé OEM avant d'être placés dans le fichier ZIP. La pratique courante consiste à utiliser un algorithme asymétrique, par exemple RSA, où la clé secrète est utilisée pour signer le package et la clé publique pour le valider. Le ramdisk de la première étape doit inclure la clé publique d'association, par exemple /avb/*.avbpubkey. Si l'appareil a déjà adopté AVB, la procédure de signature existante suffira. Les sections suivantes illustrent le processus de signature et mettent en évidence l'emplacement de la clé publique AVB utilisée pour valider les images du package DSU.
Descripteur JSON DSU
Le descripteur JSON DSU décrit les packages DSU. Il est compatible avec deux primitives.
Tout d'abord, la primitive include inclut des descripteurs JSON supplémentaires ou redirige le chargeur DSU vers un nouvel emplacement. Exemple :
{
"include": ["https://.../gsi-release/gsi-src.json"]
}
Ensuite, la primitive image est utilisée pour décrire les packages DSU publiés. Le primitif d'image comporte plusieurs attributs :
Les attributs
nameetdetailssont des chaînes qui s'affichent dans la boîte de dialogue que l'utilisateur doit sélectionner.Les attributs
cpu_api,vndketos_versionsont utilisés pour les vérifications de compatibilité, qui sont décrites dans la section suivante.L'attribut
pubkeyfacultatif décrit la clé publique associée à la clé secrète utilisée pour signer le package DSU. Lorsqu'elle est spécifiée, le service DSU peut vérifier si l'appareil dispose de la clé utilisée pour valider le package DSU. Cela évite d'installer un package DSU non reconnu, par exemple un DSU signé par l'OEM-A sur un appareil fabriqué par l'OEM-B.L'attribut facultatif
tospointe vers un fichier texte qui décrit les conditions d'utilisation du package DSU correspondant. Lorsqu'un développeur sélectionne un package DSU avec l'attribut de conditions d'utilisation spécifié, la boîte de dialogue illustrée à la figure 6 s'ouvre et lui demande d'accepter les conditions d'utilisation avant d'installer le package DSU.
Figure 6. Boîte de dialogue des conditions d'utilisation
Pour référence, voici un descripteur JSON DSU pour le GSI :
{
"images":[
{
"name":"GSI+GMS x86",
"os_version":"10",
"cpu_abi": "x86",
"details":"exp-QP1A.190711.020.C4-5928301",
"vndk":[
27,
28,
29
],
"pubkey":"",
"tos": "https://dl.google.com/developers/android/gsi/gsi-tos.txt",
"uri":"https://.../gsi/gsi_gms_x86-exp-QP1A.190711.020.C4-5928301.zip"
},
{
"name":"GSI+GMS ARM64",
"os_version":"10",
"cpu_abi": "arm64-v8a",
"details":"exp-QP1A.190711.020.C4-5928301",
"vndk":[
27,
28,
29
],
"pubkey":"",
"tos": "https://dl.google.com/developers/android/gsi/gsi-tos.txt",
"uri":"https://.../gsi/gsi_gms_arm64-exp-QP1A.190711.020.C4-5928301.zip"
},
{
"name":"GSI ARM64",
"os_version":"10",
"cpu_abi": "arm64-v8a",
"details":"exp-QP1A.190711.020.C4-5928301",
"vndk":[
27,
28,
29
],
"pubkey":"",
"uri":"https://.../gsi/aosp_arm64-exp-QP1A.190711.020.C4-5928301.zip"
},
{
"name":"GSI x86_64",
"os_version":"10",
"cpu_abi": "x86_64",
"details":"exp-QP1A.190711.020.C4-5928301",
"vndk":[
27,
28,
29
],
"pubkey":"",
"uri":"https://.../gsi/aosp_x86_64-exp-QP1A.190711.020.C4-5928301.zip"
}
]
}
Gestion de la compatibilité
Plusieurs attributs permettent de spécifier la compatibilité entre un package DSU et l'appareil local :
cpu_apiest une chaîne qui décrit l'architecture de l'appareil. Cet attribut est obligatoire et est comparé à la propriété systèmero.product.cpu.abi. Leurs valeurs doivent correspondre exactement.os_versionest un entier facultatif qui spécifie une version d'Android. Par exemple, pour Android 10,os_versionest10et pour Android 11,os_versionest11. Lorsque cet attribut est spécifié, il doit être supérieur ou égal à la propriété systèmero.system.build.version.release. Cette vérification permet d'empêcher le démarrage d'une image GSI Android 10 sur un appareil fournisseur Android 11, ce qui n'est actuellement pas pris en charge. Il est autorisé de démarrer une image GSI Android 11 sur un appareil Android 10.vndkest un tableau facultatif qui spécifie tous les VNDK inclus dans le package DSU. Lorsqu'il est spécifié, le chargeur DSU vérifie si le numéro extrait de la propriété systèmero.vndk.versionest inclus.
Révoquer les clés DSU pour des raisons de sécurité
Dans le cas extrêmement rare où la paire de clés RSA utilisée pour signer les images DSU est compromise, le disque RAM doit être mis à jour dès que possible pour supprimer la clé compromise. En plus de mettre à jour la partition de démarrage, vous pouvez bloquer les clés compromises à l'aide d'une liste de révocation de clés DSU (liste noire de clés) à partir d'une URL HTTPS.
La liste de révocation des clés DSU contient une liste des clés publiques AVB révoquées. Lors de l'installation de DSU, les clés publiques à l'intérieur des images DSU sont validées avec la liste de révocation. Si les images contiennent une clé publique révoquée, le processus d'installation de DSU s'arrête.
L'URL de la liste de révocation des clés doit être une URL HTTPS pour garantir la sécurité. Elle est spécifiée dans une chaîne de ressource :
frameworks/base/packages/DynamicSystemInstallationService/res/values/strings.xml@key_revocation_list_url
La valeur de la chaîne est https://dl.google.com/developers/android/gsi/gsi-keyblacklist.json, qui est une liste de révocation pour les clés GSI publiées par Google. Cette chaîne de ressources peut être superposée et personnalisée, de sorte que les OEM qui adoptent la fonctionnalité DSU peuvent fournir et gérer leur propre liste noire de clés. Cela permet à l'OEM de bloquer certaines clés publiques sans mettre à jour l'image ramdisk de l'appareil.
Le format de la liste de révocation est le suivant :
{
"entries":[
{
"public_key":"bf14e439d1acf231095c4109f94f00fc473148e6",
"status":"REVOKED",
"reason":"Key revocation test key"
},
{
"public_key":"d199b2f29f3dc224cca778a7544ea89470cbef46",
"status":"REVOKED",
"reason":"Key revocation test key"
}
]
}
public_keycorrespond au résumé SHA-1 de la clé révoquée, au format décrit dans la section Générer la clé publique AVB.statusindique l'état de révocation de la clé. Actuellement, la seule valeur acceptée estREVOKED.reasonest une chaîne facultative décrivant le motif de la révocation.
Procédures DSU
Cette section explique comment effectuer plusieurs procédures de configuration DSU.
Générer une paire de clés
Utilisez la commande openssl pour générer une paire de clés RSA privée/publique au format .pem (par exemple, avec une taille de 2 048 bits) :
$ openssl genrsa -out oem_cert_pri.pem 2048
$ openssl rsa -in oem_cert_pri.pem -pubout -out oem_cert_pub.pem
Il est possible que la clé privée ne soit pas accessible et qu'elle soit conservée uniquement dans un module de sécurité matérielle (HSM). Dans ce cas, un certificat de clé publique x509 peut être disponible après la génération de la clé. Consultez la section Ajouter la clé publique d'association au ramdisk pour obtenir des instructions sur la génération de la clé publique AVB à partir d'un certificat x509.
Pour convertir un certificat x509 au format PEM :
$ openssl x509 -pubkey -noout -in oem_cert_pub.x509.pem > oem_cert_pub.pem
Ignorez cette étape si le certificat est déjà un fichier PEM.
Ajouter la clé publique d'association au disque RAM
Le oem_cert.avbpubkey doit être placé sous /avb/*.avbpubkey pour valider le package DSU signé. Commencez par convertir la clé publique au format PEM au format de clé publique AVB :
$ avbtool extract_public_key --key oem_cert_pub.pem --output oem_cert.avbpubkey
Incluez ensuite la clé publique dans le ramdisk de la première étape en procédant comme suit.
Ajoutez un module prédéfini pour copier le
avbpubkey. Par exemple, ajoutezdevice/<company>/<board>/oem_cert.avbpubkeyetdevice/<company>/<board>/avb/Android.mkavec un contenu comme celui-ci :include $(CLEAR_VARS) LOCAL_MODULE := oem_cert.avbpubkey LOCAL_MODULE_CLASS := ETC LOCAL_SRC_FILES := $(LOCAL_MODULE) ifeq ($(BOARD_USES_RECOVERY_AS_BOOT),true) LOCAL_MODULE_PATH := $(TARGET_RECOVERY_ROOT_OUT)/first_stage_ramdisk/avb else LOCAL_MODULE_PATH := $(TARGET_RAMDISK_OUT)/avb endif include $(BUILD_PREBUILT)Faites en sorte que la cible droidcore dépende de l'élément
oem_cert.avbpubkeyajouté :droidcore: oem_cert.avbpubkey
Générer l'attribut de clé publique AVB dans le descripteur JSON
Le oem_cert.avbpubkey est au format binaire de clé publique AVB. Utilisez SHA-1 pour le rendre lisible avant de l'insérer dans le descripteur JSON :
$ sha1sum oem_cert.avbpubkey | cut -f1 -d ' '
3e62f2be9d9d813ef5........866ac72a51fd20
Il s'agit du contenu de l'attribut pubkey du descripteur JSON.
"images":[
{
...
"pubkey":"3e62f2be9d9d813ef5........866ac72a51fd20",
...
},
Signer un package DSU
Utilisez l'une des méthodes suivantes pour signer un package DSU :
Méthode 1 : Réutiliser l'artefact créé par le processus de signature AVB d'origine pour créer un package DSU. Une autre approche consiste à extraire les images déjà signées du package de version et à utiliser les images extraites pour créer directement le fichier ZIP.
Méthode 2 : Utilisez les commandes suivantes pour signer les partitions DSU si la clé privée est disponible. Chaque
imgd'un package DSU (fichier ZIP) est signé séparément :$ key_len=$(openssl rsa -in oem_cert_pri.pem -text | grep Private-Key | sed -e 's/.*(\(.*\) bit.*/\1/') $ for partition in system product; do avbtool add_hashtree_footer \ --image ${OUT}/${partition}.img \ --partition_name ${partition} \ --algorithm SHA256_RSA${key_len} \ --key oem_cert_pri.pem done
Pour en savoir plus sur l'ajout de add_hashtree_footer à l'aide de avbtool, consultez Utiliser avbtool.
Valider le package DSU en local
Nous vous recommandons de valider toutes les images locales par rapport à la clé publique d'association à l'aide des commandes suivantes :
for partition in system product; do
avbtool verify_image --image ${OUT}/${partition}.img --key oem_cert_pub.pem
done
Le résultat attendu ressemble à ceci :
Verifying image dsu/system.img using key at oem_cert_pub.pem
vbmeta: Successfully verified footer and SHA256_RSA2048 vbmeta struct in dsu/system.img
: Successfully verified sha1 hashtree of dsu/system.img for image of 898494464 bytes
Verifying image dsu/product.img using key at oem_cert_pub.pem
vbmeta: Successfully verified footer and SHA256_RSA2048 vbmeta struct in dsu/product.img
: Successfully verified sha1 hashtree of dsu/product.img for image of 905830400 bytes
Créer un package DSU
L'exemple suivant crée un package DSU contenant un system.img et un product.img :
dsu.zip {
- system.img
- product.img
}
Une fois les deux images signées, utilisez la commande suivante pour créer le fichier ZIP :
$ mkdir -p dsu
$ cp ${OUT}/system.img dsu
$ cp ${OUT}/product.img dsu
$ cd dsu && zip ../dsu.zip *.img && cd -
Personnaliser la DSU en un clic
Par défaut, le chargeur DSU pointe vers des métadonnées d'images GSI qui sont https://...google.com/.../gsi-src.json.
Les OEM peuvent remplacer la liste en définissant la propriété persist.sys.fflag.override.settings_dynamic_system.list qui pointe vers leur propre descripteur JSON. Par exemple, un OEM peut fournir des métadonnées JSON qui incluent la GSI ainsi que des images propriétaires de l'OEM, comme ceci :
{
"include": ["https://dl.google.com/.../gsi-src.JSON"]
"images":[
{
"name":"OEM image",
"os_version":"10",
"cpu_abi": "arm64-v8a",
"details":"...",
"vndk":[
27,
28,
29
],
"spl":"...",
"pubkey":"",
"uri":"https://.../....zip"
},
}
Un OEM peut enchaîner les métadonnées DSU publiées, comme illustré à la figure 7.
Figure 7. Relier les métadonnées DSU publiées