Implémenter des partitions dynamiques

Le partitionnement dynamique est implémenté à l'aide du module dm-linear device-mapper dans le noyau Linux. La partition super contient des métadonnées répertoriant les noms et les plages de blocs de chaque partition dynamique dans super. Lors de la première étape de init, ces métadonnées sont analysées et validées, et des périphériques de blocs virtuels sont créés pour représenter chaque partition dynamique.

Lors de l'application d'une OTA, les partitions dynamiques sont automatiquement créées, redimensionnées ou supprimées si nécessaire. Pour les appareils A/B, il existe deux copies des métadonnées, et les modifications ne sont appliquées qu'à la copie représentant l'emplacement cible.

Étant donné que les partitions dynamiques sont implémentées dans l'espace utilisateur, les partitions nécessaires au bootloader ne peuvent pas être rendues dynamiques. Par exemple, boot, dtbo et vbmeta sont lus par le bootloader et doivent donc rester des partitions physiques.

Chaque partition dynamique peut appartenir à un groupe de mises à jour. Ces groupes limitent l'espace maximal que les partitions de ce groupe peuvent consommer. Par exemple, system et vendor peuvent appartenir à un groupe qui limite la taille totale de system et vendor.

Implémenter des partitions dynamiques sur de nouveaux appareils

Cette section explique comment implémenter des partitions dynamiques sur les nouveaux appareils lancés avec Android 10 ou version ultérieure. Pour mettre à jour les appareils existants, consultez Mettre à niveau les appareils Android.

Modifications de partition

Pour les appareils lancés avec Android 10, créez une partition appelée super. La partition super gère les emplacements A/B en interne. Les appareils A/B n'ont donc pas besoin de partitions super_a et super_b distinctes. Toutes les partitions AOSP en lecture seule qui ne sont pas utilisées par le bootloader doivent être dynamiques et doivent être supprimées de la table de partitionnement GUID (GPT). Les partitions spécifiques au fournisseur ne doivent pas nécessairement être dynamiques et peuvent être placées dans le GPT.

Pour estimer la taille de super, ajoutez la taille des partitions supprimées du GPT. Pour les périphériques A/B, cette valeur doit inclure la taille des deux emplacements. La Figure 1 montre un exemple de table de partition avant et après la conversion en partitions dynamiques.

Mise en page de la table de partitionnement
Figure 1 Nouvelle mise en page de la table de partitionnement physique lors de la conversion en partitions dynamiques

Les partitions dynamiques acceptées sont les suivantes:

  • Système
  • Fournisseur
  • Produit
  • Ext. système
  • ODM

Pour les appareils équipés d'Android 10, l'option de ligne de commande du noyau androidboot.super_partition doit être vide de sorte que la commande sysprop ro.boot.super_partition soit vide.

Alignement des partitions

Le module device-mapper peut fonctionner moins efficacement si la partition super n'est pas correctement alignée. La partition super DOIT être alignée sur la taille minimale de la requête d'E/S, comme déterminé par la couche de blocs. Par défaut, le système de compilation (via lpmake, qui génère l'image de partition super) suppose qu'un alignement de 1 Mo est suffisant pour chaque partition dynamique. Toutefois, les fournisseurs doivent s'assurer que la partition super est correctement alignée.

Vous pouvez déterminer la taille de requête minimale d'un appareil de bloc en inspectant sysfs. Exemple : 

# ls -l /dev/block/by-name/super
lrwxrwxrwx 1 root root 16 1970-04-05 01:41 /dev/block/by-name/super -> /dev/block/sda17
# cat /sys/block/sda/queue/minimum_io_size
786432

Vous pouvez vérifier l'alignement de la partition super de la même manière: 

# cat /sys/block/sda/sda17/alignment_offset

Le décalage d'alignement DOIT être de 0.

Modifications de la configuration de l'appareil

Pour activer le partitionnement dynamique, ajoutez l'indicateur suivant dans device.mk: 

PRODUCT_USE_DYNAMIC_PARTITIONS := true

Modifications de la configuration du tableau

Vous devez définir la taille de la partition super: 

BOARD_SUPER_PARTITION_SIZE := <size-in-bytes>

Sur les appareils A/B, le système de compilation génère une erreur si la taille totale des images de partition dynamique dépasse la moitié de la taille de la partition super.

Vous pouvez configurer la liste des partitions dynamiques comme suit. Pour les appareils utilisant des groupes de mises à jour, listez les groupes dans la variable BOARD_SUPER_PARTITION_GROUPS. Chaque nom de groupe comporte alors une variable BOARD_group_SIZE et une variable BOARD_group_PARTITION_LIST. Pour les appareils A/B, la taille maximale d'un groupe ne doit couvrir qu'un seul emplacement, car les noms de groupe sont associés à un suffixe d'emplacement en interne.

Voici un exemple d'appareil qui place toutes les partitions dans un groupe appelé example_dynamic_partitions: 

BOARD_SUPER_PARTITION_GROUPS := example_dynamic_partitions
BOARD_EXAMPLE_DYNAMIC_PARTITIONS_SIZE := 6442450944
BOARD_EXAMPLE_DYNAMIC_PARTITIONS_PARTITION_LIST := system vendor product

Voici un exemple d'appareil qui place les services système et produits dans group_foo, et vendor, product et odm dans group_bar: 

BOARD_SUPER_PARTITION_GROUPS := group_foo group_bar
BOARD_GROUP_FOO_SIZE := 4831838208
BOARD_GROUP_FOO_PARTITION_LIST := system product_services
BOARD_GROUP_BAR_SIZE := 1610612736
BOARD_GROUP_BAR_PARTITION_LIST := vendor product odm
  • Pour les appareils de lancement A/B virtuels, la somme des tailles maximales de tous les groupes ne doit pas dépasser:
    BOARD_SUPER_PARTITION_SIZE - dépenses
    Consultez Implémenter le test A/B virtuel.
  • Pour les appareils de lancement A/B, la somme des tailles maximales de tous les groupes doit être:
    BOARD_SUPER_PARTITION_SIZE / 2 - charges indirectes
  • Pour les appareils non-A/B et les appareils équipés d'une fonctionnalité A/B après installation, la somme des tailles maximales de tous les groupes doit être la suivante:
    BOARD_SUPER_PARTITION_SIZE - frais généraux
  • Au moment de la compilation, la somme des tailles des images de chaque partition d'un groupe de mises à jour ne doit pas dépasser la taille maximale du groupe.
  • Des frais généraux sont requis dans le calcul pour prendre en compte les métadonnées, les alignements, etc. Un coût supplémentaire raisonnable est de 4 Mo, mais vous pouvez choisir un coût supplémentaire plus élevé si nécessaire pour l'appareil.

Taille des partitions dynamiques

Avant les partitions dynamiques, les tailles de partition étaient surallouées pour s'assurer qu'elles avaient suffisamment d'espace pour les futures mises à jour. La taille réelle a été prise telle quelle, et la plupart des partitions en lecture seule disposaient d'une certaine quantité d'espace libre dans leur système de fichiers. Dans les partitions dynamiques, cet espace libre est inutilisable et peut être utilisé pour augmenter les partitions lors d'une mise à jour OTA. Il est essentiel de s'assurer que les partitions ne gaspillent pas d'espace et qu'elles sont allouées à la taille minimale possible.

Pour les images ext4 en lecture seule, le système de compilation alloue automatiquement la taille minimale si aucune taille de partition codée en dur n'est spécifiée. Le système de compilation ajuste l'image afin que le système de fichiers dispose d'un espace inutilisé aussi petit que possible. Cela garantit que l'appareil ne gaspille pas d'espace pouvant être utilisé pour les mises à jour OTA.

De plus, les images ext4 peuvent être compressées davantage en activant la déduplication au niveau des blocs. Pour l'activer, utilisez la configuration suivante: 

BOARD_EXT4_SHARE_DUP_BLOCKS := true

Si l'allocation automatique d'une taille minimale de partition n'est pas souhaitable, vous pouvez contrôler la taille de la partition de deux manières. Vous pouvez spécifier une quantité minimale d'espace libre avec BOARD_partitionIMAGE_PARTITION_RESERVED_SIZE ou BOARD_partitionIMAGE_PARTITION_SIZE pour forcer les partitions dynamiques à une taille spécifique. Aucune de ces options n'est recommandée, sauf si nécessaire.

Exemple : 

BOARD_PRODUCTIMAGE_PARTITION_RESERVED_SIZE := 52428800

Cela oblige le système de fichiers de product.img à disposer de 50 Mio d'espace inutilisé.

Modifications du système en tant que root

Les appareils lancés avec Android 10 ne doivent pas utiliser le système en tant que racine.

Les appareils avec des partitions dynamiques (qu'ils soient lancés avec ou rétrofittés avec des partitions dynamiques) ne doivent pas utiliser le système en tant que racine. Le noyau Linux ne peut pas interpréter la partition super et ne peut donc pas installer system lui-même. system est désormais installé par le init de première étape, qui se trouve dans le ramdisk.

Ne définissez pas BOARD_BUILD_SYSTEM_ROOT_IMAGE. Dans Android 10, l'option BOARD_BUILD_SYSTEM_ROOT_IMAGE n'est utilisée que pour déterminer si le système est installé par le noyau ou par le init de premier étage dans ramdisk.

Définir BOARD_BUILD_SYSTEM_ROOT_IMAGE sur true entraîne une erreur de compilation lorsque PRODUCT_USE_DYNAMIC_PARTITIONS est également true.

Lorsque BOARD_USES_RECOVERY_AS_BOOT est défini sur "true", l'image de récupération est créée sous le nom boot.img et contient le ramdisk de récupération. Auparavant, le bootloader utilisait le paramètre de ligne de commande du noyau skip_initramfs pour décider dans quel mode démarrer. Pour les appareils Android 10, le bootloader NE DOIT PAS transmettre skip_initramfs à la ligne de commande du noyau. À la place, le bootloader doit transmettre androidboot.force_normal_boot=1 pour ignorer la récupération et démarrer Android en mode normal. Les appareils qui démarrent avec Android 12 ou version ultérieure doivent utiliser bootconfig pour transmettre androidboot.force_normal_boot=1.

Modifications de la configuration AVB

Lorsque vous utilisez Android Verified Boot 2.0, si l'appareil n'utilise pas de descripteurs de partition en chaîne, aucune modification n'est nécessaire. Toutefois, si vous utilisez des partitions en chaîne et que l'une des partitions validées est dynamique, des modifications sont nécessaires.

Voici un exemple de configuration pour un appareil qui enchaîne vbmeta pour les partitions system et vendor. 

BOARD_AVB_SYSTEM_KEY_PATH := external/avb/test/data/testkey_rsa2048.pem
BOARD_AVB_SYSTEM_ALGORITHM := SHA256_RSA2048
BOARD_AVB_SYSTEM_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP)
BOARD_AVB_SYSTEM_ROLLBACK_INDEX_LOCATION := 1

BOARD_AVB_VENDOR_KEY_PATH := external/avb/test/data/testkey_rsa2048.pem
BOARD_AVB_VENDOR_ALGORITHM := SHA256_RSA2048
BOARD_AVB_VENDOR_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP)
BOARD_AVB_VENDOR_ROLLBACK_INDEX_LOCATION := 1

Avec cette configuration, le bootloader s'attend à trouver un pied de page vbmeta à la fin des partitions system et vendor. Comme ces partitions ne sont plus visibles par le bootloader (elles résident dans super), deux modifications sont nécessaires.

  • Ajoutez des partitions vbmeta_system et vbmeta_vendor à la table de partitions de l'appareil. Pour les appareils A/B, ajoutez vbmeta_system_a, vbmeta_system_b, vbmeta_vendor_a et vbmeta_vendor_b. Si vous ajoutez une ou plusieurs de ces partitions, elles doivent être de la même taille que la partition vbmeta.
  • Renommez les indicateurs de configuration en ajoutant VBMETA_ et spécifiez les partitions auxquelles s'applique le chaînage: 
    BOARD_AVB_VBMETA_SYSTEM := system
BOARD_AVB_VBMETA_SYSTEM_KEY_PATH := external/avb/test/data/testkey_rsa2048.pem
BOARD_AVB_VBMETA_SYSTEM_ALGORITHM := SHA256_RSA2048
BOARD_AVB_VBMETA_SYSTEM_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP)
BOARD_AVB_VBMETA_SYSTEM_ROLLBACK_INDEX_LOCATION := 1

BOARD_AVB_VBMETA_VENDOR := vendor
BOARD_AVB_VBMETA_VENDOR_KEY_PATH := external/avb/test/data/testkey_rsa2048.pem
BOARD_AVB_VBMETA_VENDOR_ALGORITHM := SHA256_RSA2048
BOARD_AVB_VBMETA_VENDOR_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP)
BOARD_AVB_VBMETA_VENDOR_ROLLBACK_INDEX_LOCATION := 1

Un appareil peut utiliser une ou plusieurs de ces partitions, ou aucune. Les modifications ne sont nécessaires que lors de l'association à une partition logique.

Modifications apportées au bootloader AVB

Si le bootloader intègre libavb, incluez les correctifs suivants:

Si vous utilisez des partitions en série, incluez un correctif supplémentaire:

  • 49936b4c0109411fdd38bd4ba3a32a01c40439a9 — "libavb: prise en charge des blobs vbmeta au début de la partition."

Modifications de la ligne de commande du noyau

Un nouveau paramètre, androidboot.boot_devices, doit être ajouté à la ligne de commande du noyau. init l'utilise pour activer les liens symboliques /dev/block/by-name. Il doit s'agir du composant de chemin d'accès de l'appareil vers le lien symbolique sous-jacent créé par ueventd, à savoir /dev/block/platform/device-path/by-name/partition-name. Les appareils qui démarrent avec Android 12 ou version ultérieure doivent utiliser bootconfig pour transmettre androidboot.boot_devices à init.

Par exemple, si le lien symbolique de la super partition par nom est /dev/block/platform/soc/100000.ufshc/by-name/super, vous pouvez ajouter le paramètre de ligne de commande dans le fichier BoardConfig.mk comme suit: 

BOARD_KERNEL_CMDLINE += androidboot.boot_devices=soc/100000.ufshc
 Vous pouvez ajouter le paramètre bootconfig dans le fichier BoardConfig.mk comme suit: 
BOARD_BOOTCONFIG += androidboot.boot_devices=soc/100000.ufshc

Modifications apportées à fstab

L'arborescence des périphériques et les superpositions de l'arborescence des périphériques ne doivent pas contenir d'entrées fstab. Utilisez un fichier fstab qui fera partie du ramdisk.

Des modifications doivent être apportées au fichier fstab pour les partitions logiques:

  • Le champ des indicateurs fs_mgr doit inclure les options logical et first_stage_mount, introduites dans Android 10, qui indique qu'une partition doit être installée lors de la première étape.
  • Une partition peut spécifier avb=vbmeta partition name comme indicateur fs_mgr, puis la partition vbmeta spécifiée est initialisée par le premier niveau init avant d'essayer de monter des appareils.
  • Le champ dev doit correspondre au nom de la partition.

Les entrées fstab suivantes définissent le système, le fournisseur et le produit comme des partitions logiques conformément aux règles ci-dessus. 

#<dev>  <mnt_point> <type>  <mnt_flags options> <fs_mgr_flags>
system   /system     ext4    ro,barrier=1        wait,slotselect,avb=vbmeta,logical,first_stage_mount
vendor   /vendor     ext4    ro,barrier=1        wait,slotselect,avb,logical,first_stage_mount
product  /product    ext4    ro,barrier=1        wait,slotselect,avb,logical,first_stage_mount

Copiez le fichier fstab dans le ramdisk de la première étape.

Modifications apportées à SELinux

L'appareil de bloc de superpartition doit être marqué avec le libellé super_block_device. Par exemple, si le lien symbolique par nom de super-partition est /dev/block/platform/soc/100000.ufshc/by-name/super, ajoutez la ligne suivante à file_contexts: 

/dev/block/platform/soc/10000\.ufshc/by-name/super   u:object_r:super_block_device:s0

fastbootd

Le bootloader (ou tout outil de flashage autre que l'espace utilisateur) ne comprend pas les partitions dynamiques et ne peut donc pas les flasher. Pour y remédier, les appareils doivent utiliser une implémentation de l'espace utilisateur du protocole fastboot, appelée fastbootd.

Pour en savoir plus sur l'implémentation de fastbootd, consultez Déplacer Fastboot vers l'espace utilisateur.

Remontage adb

Pour les développeurs qui utilisent des builds eng ou userdebug, adb remount est extrêmement utile pour les itérations rapides. Les partitions dynamiques posent un problème pour adb remount, car il n'y a plus d'espace libre dans chaque système de fichiers. Pour y remédier, les appareils peuvent activer les overlayfs. Tant qu'il y a de l'espace libre dans la super partition, adb remount crée automatiquement une partition dynamique temporaire et utilise overlayfs pour les écritures. La partition temporaire est nommée scratch. N'utilisez donc pas ce nom pour d'autres partitions.

Pour en savoir plus sur l'activation d'overlayfs, consultez le fichier README overlayfs dans AOSP.

Mettre à niveau les appareils Android

Si vous mettez à niveau un appareil vers Android 10 et que vous souhaitez inclure la prise en charge des partitions dynamiques dans l'OTA, vous n'avez pas besoin de modifier la table de partition intégrée. Une configuration supplémentaire est requise.

Modifications de la configuration de l'appareil

Pour rétrofiter le partitionnement dynamique, ajoutez les options suivantes dans device.mk: 

PRODUCT_USE_DYNAMIC_PARTITIONS := true
PRODUCT_RETROFIT_DYNAMIC_PARTITIONS := true

Modifications de la configuration du tableau

Vous devez définir les variables de tableau suivantes:

  • Définissez BOARD_SUPER_PARTITION_BLOCK_DEVICES sur la liste des appareils de bloc utilisés pour stocker les extensions de partitions dynamiques. Il s'agit de la liste des noms des partitions physiques existantes sur l'appareil.
  • Définissez BOARD_SUPER_PARTITION_partition_DEVICE_SIZE sur les tailles de chaque appareil de stockage en mode bloc dans BOARD_SUPER_PARTITION_BLOCK_DEVICES, respectivement. Voici la liste des tailles des partitions physiques existantes sur l'appareil. Il s'agit généralement de BOARD_partitionIMAGE_PARTITION_SIZE dans les configurations de carte existantes.
  • Annulez la définition de BOARD_partitionIMAGE_PARTITION_SIZE existante pour toutes les partitions de BOARD_SUPER_PARTITION_BLOCK_DEVICES.
  • Définissez BOARD_SUPER_PARTITION_SIZE sur la somme de BOARD_SUPER_PARTITION_partition_DEVICE_SIZE.
  • Définissez BOARD_SUPER_PARTITION_METADATA_DEVICE sur l'appareil de bloc où les métadonnées de partition dynamique sont stockées. Il doit s'agir de l'un des éléments suivants : BOARD_SUPER_PARTITION_BLOCK_DEVICES. Cette valeur est généralement définie sur system.
  • Définissez BOARD_SUPER_PARTITION_GROUPS, BOARD_group_SIZE et BOARD_group_PARTITION_LIST, respectivement. Pour en savoir plus, consultez la section Modifications de la configuration de la carte sur les nouveaux appareils.

Par exemple, si l'appareil dispose déjà de partitions système et de fournisseur, et que vous souhaitez les convertir en partitions dynamiques et ajouter une nouvelle partition de produit pendant la mise à jour, définissez la configuration de la carte suivante: 

BOARD_SUPER_PARTITION_BLOCK_DEVICES := system vendor
BOARD_SUPER_PARTITION_METADATA_DEVICE := system

# Rename BOARD_SYSTEMIMAGE_PARTITION_SIZE to BOARD_SUPER_PARTITION_SYSTEM_DEVICE_SIZE.
BOARD_SUPER_PARTITION_SYSTEM_DEVICE_SIZE := <size-in-bytes>

# Rename BOARD_VENDORIMAGE_PARTITION_SIZE to BOARD_SUPER_PARTITION_VENDOR_DEVICE_SIZE
BOARD_SUPER_PARTITION_VENDOR_DEVICE_SIZE := <size-in-bytes>

# This is BOARD_SUPER_PARTITION_SYSTEM_DEVICE_SIZE + BOARD_SUPER_PARTITION_VENDOR_DEVICE_SIZE
BOARD_SUPER_PARTITION_SIZE := <size-in-bytes>

# Configuration for dynamic partitions. For example:
BOARD_SUPER_PARTITION_GROUPS := group_foo
BOARD_GROUP_FOO_SIZE := <size-in-bytes>
BOARD_GROUP_FOO_PARTITION_LIST := system vendor product

Modifications apportées à SELinux

Les appareils de bloc de super partition doivent être marqués avec l'attribut super_block_device_type. Par exemple, si l'appareil dispose déjà de partitions system et vendor, vous souhaitez les utiliser comme dispositifs de bloc pour stocker les extensions de partitions dynamiques, et leurs liens symboliques par nom sont marqués comme system_block_device: 

/dev/block/platform/soc/10000\.ufshc/by-name/system   u:object_r:system_block_device:s0
/dev/block/platform/soc/10000\.ufshc/by-name/vendor   u:object_r:system_block_device:s0

Ajoutez ensuite la ligne suivante à device.te: 

typeattribute system_block_device super_block_device_type;

Pour d'autres configurations, consultez Implémenter des partitions dynamiques sur de nouveaux appareils.

Pour en savoir plus sur les mises à jour de rétrofit, consultez la section Mise à jour OTA pour les appareils A/B sans partitions dynamiques.

Images d'usine

Pour un appareil lancé avec la prise en charge des partitions dynamiques, évitez d'utiliser fastboot dans l'espace utilisateur pour flasher des images d'usine, car le démarrage dans l'espace utilisateur est plus lent que les autres méthodes de flashage.

Pour y remédier, make dist crée désormais une image super.img supplémentaire pouvant être flashée directement sur la superpartition. Il regroupe automatiquement le contenu des partitions logiques, ce qui signifie qu'il contient system.img, vendor.img, etc., en plus des métadonnées de partition super. Cette image peut être flashée directement sur la partition super sans outil supplémentaire ni à l'aide de fastbootd. Après la compilation, super.img est placé dans ${ANDROID_PRODUCT_OUT}.

Pour les appareils A/B qui démarrent avec des partitions dynamiques, super.img contient des images dans l'emplacement A. Après avoir flashé directement la super image, marquez l'emplacement A comme amorçable avant de redémarrer l'appareil.

Pour les appareils rétrofités, make dist crée un ensemble d'images super_*.img pouvant être flashées directement sur les partitions physiques correspondantes. Par exemple, make dist compile super_system.img et super_vendor.img lorsque BOARD_SUPER_PARTITION_BLOCK_DEVICES est le fournisseur du système. Ces images sont placées dans le dossier OTA de target_files.zip.

Paramétrage du stockage de l'appareil mappeur d'appareils

Le partitionnement dynamique s'adapte à un certain nombre d'objets device-mapper non déterministes. Il est possible que tous ne soient pas instanciés comme prévu. Vous devez donc suivre tous les montages et mettre à jour les propriétés Android de toutes les partitions associées avec leurs appareils de stockage sous-jacents.

Un mécanisme intégré à init suit les montages et met à jour de manière asynchrone les propriétés Android. La durée de cette opération n'est pas garantie dans un délai spécifique. Vous devez donc laisser suffisamment de temps à tous les déclencheurs on property pour qu'ils réagissent. Les propriétés sont dev.mnt.blk.<partition>, où <partition> est root, system, data ou vendor, par exemple. Chaque propriété est associée au nom de l'appareil de stockage de base, comme illustré dans les exemples suivants:

taimen:/ % getprop | grep dev.mnt.blk
[dev.mnt.blk.data]: [sda]
[dev.mnt.blk.firmware]: [sde]
[dev.mnt.blk.metadata]: [sde]
[dev.mnt.blk.persist]: [sda]
[dev.mnt.blk.root]: [dm-0]
[dev.mnt.blk.vendor]: [dm-1]

blueline:/ $ getprop | grep dev.mnt.blk
[dev.mnt.blk.data]: [dm-4]
[dev.mnt.blk.metadata]: [sda]
[dev.mnt.blk.mnt.scratch]: [sda]
[dev.mnt.blk.mnt.vendor.persist]: [sdf]
[dev.mnt.blk.product]: [dm-2]
[dev.mnt.blk.root]: [dm-0]
[dev.mnt.blk.system_ext]: [dm-3]
[dev.mnt.blk.vendor]: [dm-1]
[dev.mnt.blk.vendor.firmware_mnt]: [sda]

Le langage init.rc permet d'étendre les propriétés Android dans le cadre des règles, et les appareils de stockage peuvent être réglés par la plate-forme si nécessaire à l'aide de commandes comme celles-ci:

write /sys/block/${dev.mnt.blk.root}/queue/read_ahead_kb 128
write /sys/block/${dev.mnt.blk.data}/queue/read_ahead_kb 128

Une fois que le traitement de la commande commence à la deuxième étape init, epoll loop devient actif et les valeurs commencent à être mises à jour. Toutefois, comme les déclencheurs de propriété ne sont pas actifs avant la fin de init, ils ne peuvent pas être utilisés aux étapes de démarrage initiales pour gérer root, system ou vendor. Vous pouvez vous attendre à ce que le read_ahead_kb par défaut du noyau soit suffisant jusqu'à ce que les scripts init.rc puissent remplacer dans early-fs (lorsque divers daemons et services démarrent). Par conséquent, Google vous recommande d'utiliser la fonctionnalité on property, associée à une propriété contrôlée par init.rc telle que sys.read_ahead_kb, pour gérer la planification des opérations et éviter les conditions de concurrence, comme dans les exemples suivants:

on property:dev.mnt.blk.root=* && property:sys.read_ahead_kb=*
    write /sys/block/${dev.mnt.blk.root}/queue/read_ahead_kb ${sys.read_ahead_kb:-2048}

on property:dev.mnt.blk.system=* && property:sys.read_ahead_kb=*
    write /sys/block/${dev.mnt.blk.system}/queue/read_ahead_kb ${sys.read_ahead_kb:-2048}

on property:dev.mnt.blk.vendor=* && property:sys.read_ahead_kb=*
    write /sys/block/${dev.mnt.blk.vendor}/queue/read_ahead_kb ${sys.read_ahead_kb:-2048}

on property:dev.mnt.blk.product=* && property:sys.read_ahead_kb=*
    write /sys/block/${dev.mnt.blk.system_ext}/queue/read_ahead_kb ${sys.read_ahead_kb:-2048}

on property:dev.mnt.blk.oem=* && property:sys.read_ahead_kb=*
    write /sys/block/${dev.mnt.blk.oem}/queue/read_ahead_kb ${sys.read_ahead_kb:-2048}

on property:dev.mnt.blk.data=* && property:sys.read_ahead_kb=*
    write /sys/block/${dev.mnt.blk.data}/queue/read_ahead_kb ${sys.read_ahead_kb:-2048}

on early-fs:
    setprop sys.read_ahead_kb ${ro.read_ahead_kb.boot:-2048}

on property:sys.boot_completed=1
   setprop sys.read_ahead_kb ${ro.read_ahead_kb.bootcomplete:-128}