Cette page a été traduite par l'API Cloud Translation.

Disposition des partitions

Sous Android 10, le système de fichiers racine n'est plus inclus dans ramdisk.img et est fusionné avec system.img (c'est-à-dire que system.img est toujours créé en tant que si BOARD_BUILD_SYSTEM_ROOT_IMAGE a été défini). Appareils lancement avec Android 10:

Utilisez une disposition de partition système en tant que racine (appliquée automatiquement par sans possibilité de modifier le comportement).
Vous devez utiliser un ramdisk, qui est obligatoire pour dm-linear.
Vous devez définir BOARD_BUILD_SYSTEM_ROOT_IMAGE sur false. Ce paramètre sert uniquement à différencier les appareils qui utilisent un ramdisk et les périphériques qui n'utilisent pas de disque RAM system.img).

La signification d'une configuration système en tant que racine diffère entre Android 9 et Android 10. Dans un système en tant que racine Android 9 configuration, BOARD_BUILD_SYSTEM_ROOT_IMAGE est défini sur true, qui force la compilation à fusionner le système de fichiers racine dans system.img, puis installe system.img en tant que fichier racine (rootfs). Cette configuration est obligatoire pour les appareils lancée sous Android 9. Cette fonctionnalité est facultative pour les appareils Android 9 et pour les appareils équipés de versions antérieures d'Android Sur un appareil Android 10 configurations système en tant que racine (système en tant que racine), fusionne $TARGET_SYSTEM_OUT et $TARGET_ROOT_OUT dans system.img; cette configuration est le comportement par défaut pour tous les appareils exécutant Android 10.

Android 10 apporte d'autres modifications à la compatibilité partitions dynamiques, un système de partitionnement de l'espace utilisateur qui permet des mises à jour Over The Air (OTA) créer, redimensionner ou détruire des partitions. Dans le cadre de ce changement, le noyau ne peut plus installer la partition système logique sur les périphériques exécutant Android 10. Cette opération est donc gérée par "stade init".

Les sections suivantes décrivent les exigences du système en tant que racine pour OTA uniquement du système, fournir des conseils sur la mise à jour des appareils pour qu'ils utilisent le système en tant que racine (y compris les modifications de la disposition des partitions et les exigences du noyau dm-verity). Pour pour en savoir plus sur les modifications apportées à ramdisk, Ramdisk Partitions.

À propos des OTA uniquement système

Les OTA uniquement du système, qui permettent de mettre à jour les versions Android system.img et product.img sans modifier les autres partitions, nécessitent une disposition de partition système en tant que racine. Tous les appareils fonctionnant sous Android 10 doit utiliser une structure de partition système en tant que racine pour activer les OTA uniquement du système.

Les périphériques A/B, qui installent la partition system en tant que rootfs, utilisent déjà le système en tant que racine et ne nécessitent aucune modification pour prendre en charge les OTA du système.
Les appareils non A/B, qui installent la partition system sur /system, doit être mis à jour pour pouvoir utiliser une structure de partition système en tant que racine pour prendre en charge les OTA du système.

Pour en savoir plus sur les appareils A/B et non-A/B, consultez Mises à jour du système A/B (fluides).

Utiliser la superposition de fournisseur (<=AOSP 14)

La superposition des fournisseurs vous permet de superposer les modifications apportées à vendor au moment du démarrage de l'appareil. Une superposition de fournisseur est un ensemble de modules de fournisseurs dans la partition product superposée à l'élément vendor. au démarrage de l'appareil, en remplaçant les modules existants et en les ajoutant.

Lorsque l'appareil démarre, le processus init termine la première l'installation de l'espace de création et lit les propriétés par défaut. Ensuite, il recherche /product/vendor_overlay/<target_vendor_version> et installations chaque sous-répertoire dans le répertoire de partition vendor correspondant, si les conditions suivantes sont remplies:

/vendor/<overlay_dir> existe.
/product/vendor_overlay/<target_vendor_version>/<overlay_dir> a le même contexte de fichier que /vendor/<overlay_dir>.
init est autorisé à être installé dans le contexte de fichier de /vendor/<overlay_dir>

Implémenter la superposition de fournisseur

Installer les fichiers de superposition de fournisseur dans /product/vendor_overlay/<target_vendor_version> Ces fichiers superposer la partition vendor au démarrage de l'appareil, remplaçant les fichiers du même nom et en ajoutant de nouveaux fichiers. La superposition des fournisseurs ne permet pas de supprimer des fichiers de la partition vendor.

Les fichiers de superposition des fournisseurs doivent avoir le même contexte de fichier que les fichiers cibles. qu'ils remplacent dans la partition vendor. Par défaut, les fichiers du dossier Annuaire /product/vendor_overlay/<target_vendor_version> incluent le contexte vendor_file. En cas de disparités de contexte de fichier entre les fichiers de superposition des fournisseurs et les fichiers qu'ils remplacent, indiquez que dans le champ sepolicy spécifique à l'appareil. Le contexte du fichier est défini au niveau du répertoire. Si le le contexte du fichier d'un répertoire de superposition de fournisseur ne correspond pas au répertoire cible, et que le bon contexte de fichier n'est pas spécifié dans la sepolicy spécifique à l'appareil, ce répertoire de superposition du fournisseur n'est pas superposé au répertoire cible.

Pour utiliser la superposition de fournisseur, le noyau doit activer OverlayFS en définissant CONFIG_OVERLAY_FS=y De plus, le noyau doit être fusionné noyau commun 4.4 ou version ultérieure, ou corrigé avec "overlayfs: override_creds=off option bypass creator_cred".

Exemple d'implémentation d'une superposition de fournisseur

Cette procédure illustre l'implémentation d'une superposition de fournisseur qui se superpose à la les répertoires /vendor/lib/*, /vendor/etc/* et /vendor/app/*

Ajoutez des fichiers de fournisseurs prédéfinis dans device/<vendor>/<target>/vendor_overlay/<target_vendor_version>/:

device/google/device/vendor_overlay/28/lib/libfoo.so
device/google/device/vendor_overlay/28/lib/libbar.so
device/google/device/vendor_overlay/28/etc/baz.xml
device/google/device/vendor_overlay/28/app/qux.apk

Installez les fichiers de fournisseurs prédéfinis product/vendor_overlay po device/google/device/device.mk:

PRODUCT_COPY_FILES += \
    $(call find-copy-subdir-files,*,device/google/device/vendor_overlay,$(TARGET_COPY_OUT_PRODUCT)/vendor_overlay)

Définissez des contextes de fichiers si les fichiers de partition vendor cibles ont des contextes autres que vendor_file. En effet, /vendor/lib/* utilise le contexte vendor_file, ce qui exemple n'inclut pas ce répertoire.

Ajoutez le code suivant à device/google/device-sepolicy/private/file_contexts:
```
/(product|system/product)/vendor_overlay/[0-9]+/etc(/.*)?   u:object_r:vendor_configs_file:s0
/(product|system/product)/vendor_overlay/[0-9]+/app(/.*)?   u:object_r:vendor_app_file:s0
```
Autoriser le processus init à installer la superposition de fournisseur sur le fichier des contextes autres que vendor_file. Étant donné que init a déjà l'autorisation d'être installé sur le contexte vendor_file, cet exemple ne définit pas la règle pour vendor_file.

Ajoutez le code suivant à device/google/device-sepolicy/public/init.te:
```
allow init vendor_configs_file:dir mounton;
allow init vendor_app_file:dir mounton;
```

Valider la superposition du fournisseur

Pour valider la configuration de la superposition de fournisseur, ajoutez des fichiers dans /product/vendor_overlay/<target_vendor_version>/<overlay_dir> et vérifiez si les fichiers sont superposés sur les fichiers dans /vendor/<overlay_dir>

Pour les builds userdebug, il existe un module de test pour Atest:

$ atest -v fs_mgr_vendor_overlay_test

Mettre à jour vers le système en tant que racine

Pour mettre à jour les appareils autres que A/B afin qu'ils utilisent le système en tant que racine, vous devez mettre à jour le schéma de partitionnement pour boot.img et system.img, défini up dm-verity et supprimer les dépendances de démarrage sur la racine spécifique à l'appareil. dossiers.

Mettre à jour des partitions

Contrairement aux appareils A/B qui redéfinissent /boot en tant que la partition recovery, Les appareils non-A/B doivent conserver la partition /recovery. car ils ne disposent pas de la partition des emplacements de remplacement (par exemple, entre boot_a et boot_b). Si /recovery correspond à sur un appareil non-A/B et rendu similaire au schéma A/B, le mode Recovery peut être interrompue en cas d'échec de la mise à jour de la partition /boot. Pour pour cette raison, la partition /recovery doit être un une partition distincte de /boot pour les périphériques non A/B, ce qui implique que l'image de récupération continue d'être mise à jour de manière différée comme pour les appareils équipés d'Android 8.1.0 ou version antérieure).

Le tableau suivant répertorie les différences de partition d'image pour les appareils non A/B. avant et après Android 9.

Image	Ramdisk (avant 9)	Système en tant que racine (après 9)
`boot.img`	Contient un noyau et un `ramdisk.img`: ramdisk.img -/ - init.rc - init - etc -> /system/etc - system/ (mount point) - vendor/ (mount point) - odm/ (mount point) ...	Ne contient qu'un noyau de démarrage normal.
`recovery.img`	Contient un noyau de récupération et un ensemble de clés `ramdisk.img`
`system.img`	Contient les éléments suivants: system.img -/ - bin/ - etc - vendor -> /vendor - ...	Contient le contenu fusionné des `system.img` originaux et `ramdisk.img`: system.img -/ - init.rc - init - etc -> /system/etc - system/ - bin/ - etc/ - vendor -> /vendor - ... - vendor/ (mount point) - odm/ (mount point) ...

Les partitions elles-mêmes ne changent pas ; que ramdisk et le système en tant que racine utilisent le schéma de partitionnement suivant:

/boot
/system
/system
/recovery
/vendor, etc.

Configurer dm-verity

Dans le système en tant que racine, le noyau doit installer system.img sous / (point d'accès) avec dm-verity. AOSP est compatible avec les dm-verity implémentations pour system.img.

vboot 1.0

Pour vboot 1.0, le noyau doit analyser Propre à Android métadonnées activées /system, puis convertir en Paramètres dm-verity pour configurer dm-verity (nécessite correctifs du noyau). L'exemple suivant montre les paramètres liés à dm-verity pour le système en tant que racine dans Ligne de commande du noyau:

ro root=/dev/dm-0 rootwait skip_initramfs init=/init
dm="system none ro,0 1 android-verity /dev/sda34"
veritykeyid=id:7e4333f9bba00adfe0ede979e28ed1920492b40f

Vboot 2.0

Pour Vboot 2.0 (AVB), le bootloader doit s'intégrer external/avb/libavb, qui analyse ensuite le descripteur hashtree pour /system, convertit jusqu'à paramètres dm-verity, puis transmet les paramètres au noyau via la ligne de commande du noyau. (Descripteurs Hashtree de /system peut se trouver sur /vbmeta ou sur /system lui-même.)

vboot 2.0 nécessite les correctifs de noyau suivants:

L'exemple suivant montre les paramètres liés à dm-verity pour le système en tant que racine dans Ligne de commande du noyau:

ro root=/dev/dm-0 rootwait  skip_initramfs init=/init

dm="1 vroot none ro 1,0 5159992 verity 1
PARTUUID=00000016-0000-0000-0000-000000000000
PARTUUID=00000016-0000-0000-0000-000000000000 4096 4096 644999 644999
sha1 d80b4a8be3b58a8ab86fad1b498640892d4843a2
8d08feed2f55c418fb63447fec0d32b1b107e42c 10 restart_on_corruption
ignore_zero_blocks use_fec_from_device
PARTUUID=00000016-0000-0000-0000-000000000000 fec_roots 2 fec_blocks
650080 fec_start 650080"

Utiliser des dossiers racines spécifiques à l'appareil

Avec le système en tant que racine, après l'image système générique (GSI) clignote sur l'appareil (et avant d'exécuter (tests de la suite de test fournisseur), tout dossiers racines propres à l'appareil ajoutés avec BOARD_ROOT_EXTRA_FOLDERS ont disparu, car tout le contenu du répertoire racine a été remplacé par les GSI système en tant que racine. La suppression de ces dossiers peut entraîner deviennent impossibles à démarrer s'il existe une dépendance aux dossiers racines spécifiques à l'appareil. (elles servent par exemple de points d'installation).

Pour éviter ce problème, n'utilisez pas BOARD_ROOT_EXTRA_FOLDERS pour ajouter des dossiers racines spécifiques à l’appareil. Si vous devez spécifier une installation spécifique à l'appareil utilisez /mnt/vendor/<mount point> (ajouté les listes de modifications). Ces points d'installation spécifiques au fournisseur directement spécifié dans l'arborescence des appareils fstab (pour la première étape monte) et le fichier /vendor/etc/fstab.{ro.hardware} sans configuration supplémentaire (car fs_mgr les crée sous /mnt/vendor/* automatiquement).