Le partitionnement dynamique est implémenté à l'aide de l'outil de mappage d'appareils dm-linear
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 un rayon de super
. Lors de la première phase init
,
les métadonnées sont analysées et validées, et des appareils de stockage de blocs virtuels sont créés pour
représentent chaque partition dynamique.
Lors de l'application d'une OTA, des partitions dynamiques sont automatiquement créées, redimensionnés ou supprimés si nécessaire. Pour les appareils A/B, il existe deux copies les métadonnées. Les modifications ne sont appliquées qu'à la copie représentant emplacement cible.
Étant donné que les partitions dynamiques sont
implémentées dans l'espace utilisateur, elles doivent
par le bootloader ne peut
être rendu dynamique. Par exemple, boot
,
dtbo
et vbmeta
sont lus par le bootloader, et
et doivent donc rester
sous forme de partitions physiques.
Chaque partition dynamique peut appartenir à un groupe de mise à jour. Ces
limitent l'espace maximal que les partitions d'un groupe peuvent utiliser.
Par exemple, system
et vendor
peuvent appartenir à un
qui limite la taille totale de system
et
vendor
Implémenter des partitions dynamiques sur les nouveaux appareils
Cette section explique comment implémenter des partitions dynamiques sur les nouveaux appareils avec Android 10 ou version ultérieure. Pour mettre à jour appareils existants, consultez la section Mise à niveau appareils mobiles.
Modifications de partition
Pour les appareils équipés d'Android 10, créez
une partition appelée super
. super
gère les emplacements A/B en interne, de sorte que les périphériques A/B n'ont pas besoin
séparer les partitions super_a
et super_b
.
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 partition GUID (GPT).
Les partitions spécifiques aux fournisseurs n'ont pas besoin d'être dynamiques et peuvent être placées
dans le tag GPT.
Pour estimer la taille de super
, ajoutez les tailles du
des partitions en cours de suppression du GPT. Pour les appareils A/B,
doit inclure la taille des deux espaces. La Figure 1 illustre
un exemple de table de partition avant et après la conversion en table dynamique
des partitions.
Les partitions dynamiques compatibles sont les suivantes:
- Système
- Fournisseur
- Produit
- Ext. système
- ODM
Pour les appareils équipés d'Android 10,
Option de ligne de commande du noyau androidboot.super_partition
doit être vide pour que la commande sysprop
Le champ "ro.boot.super_partition
" est vide.
Alignement des partitions
Le module de mappage de l'appareil peut être moins efficace si le
La partition super
n'est pas correctement alignée. La
La partition super
DOIT être alignée sur les E/S minimales
la taille d'une requête telle que déterminée par la couche de bloc. Par défaut,
système de compilation (via lpmake
, qui génère
super
), suppose qu'un alignement de 1 Mio
est suffisant pour chaque partition dynamique. Toutefois, les fournisseurs doivent
vous assurer que la partition super
est correctement alignée.
Vous pouvez déterminer la taille de requête minimale d'un appareil de stockage en mode bloc en
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
dans une
de la même manière:
# cat /sys/block/sda/sda17/alignment_offset
Le décalage d'alignement DOIT être égal à 0.
Modifications apportées à la configuration de l'appareil
Pour activer le partitionnement dynamique, ajoutez l'option suivante dans
device.mk
:
PRODUCT_USE_DYNAMIC_PARTITIONS := true
Modifications de la configuration de la carte
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 dynamiques représentent plus de la moitié des super
la taille de la partition.
Vous pouvez configurer la liste des partitions dynamiques comme suit. Pour
à l'aide des groupes de mise à jour, listez les groupes
Variable BOARD_SUPER_PARTITION_GROUPS
. Le nom de chaque groupe
a ensuite un BOARD_group_SIZE
et la variable BOARD_group_PARTITION_LIST
.
Pour les appareils A/B, la taille maximale d'un groupe ne doit couvrir qu'un seul
"slot", car les noms des groupes comportent des suffixes 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
, vendor
et 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<ph type="x-smartling-placeholder"> <ph type="x-smartling-placeholder">
-
Pour les appareils virtuels de lancement A/B, la somme des tailles maximales de tous les groupes doit
ne doit pas dépasser:
BOARD_SUPER_PARTITION_SIZE
- frais généraux
Consultez la page Implémenter des tests A/B virtuels. -
Pour les appareils avec lancement A/B, la somme des tailles maximales de tous les groupes doit
être:
BOARD_SUPER_PARTITION_SIZE
/ 2 - frais généraux -
Pour les appareils non-A/B et les appareils A/B ayant été adaptés, la somme des valeurs maximales
les tailles de tous les groupes doivent être:
BOARD_SUPER_PARTITION_SIZE
– frais généraux - Au moment de la compilation, la somme des tailles des images de chaque partition dans un groupe de mise à jour ne doit pas dépasser la taille maximale du groupe.
- Les frais généraux sont requis dans le calcul pour tenir compte des métadonnées. les alignements, etc. Une surcharge raisonnable est de 4 Mio, mais peut choisir une surcharge plus importante si nécessaire par l'appareil.
Taille des partitions dynamiques
Avant les partitions dynamiques, les tailles de partition étaient surallouées aux s’assurer qu’ils disposaient de suffisamment de place pour les mises à jour futures. La taille réelle était pris en l'état, et la plupart des partitions en lecture seule disposaient d'une certaine quantité dans leur système de fichiers. Dans les partitions dynamiques, cet espace libre inutilisable et pourrait être utilisé pour augmenter les partitions lors d’une OTA. Il est essentiel de s'assurer que les partitions ne gaspillent pas d'espace et sont est allouée à une 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. La système de compilation ajuste l'image afin que le système de fichiers n'ait que possible l'espace inutilisé. Cela garantit que l'appareil ne le gaspille pas pouvant être utilisé pour les agences de voyages en ligne.
Vous pouvez aussi compresser davantage les images ext4 en activant au niveau de la déduplication. 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,
il existe deux façons de contrôler
la taille de la partition. Vous pouvez spécifier un
d'espace libre minimum avec
BOARD_partitionIMAGE_PARTITION_RESERVED_SIZE
,
ou vous pouvez spécifier
BOARD_partitionIMAGE_PARTITION_SIZE
pour forcer
des partitions dynamiques à une taille spécifique. Aucune de ces options n’est
recommandé, sauf en cas de nécessité.
Exemple :
BOARD_PRODUCTIMAGE_PARTITION_RESERVED_SIZE := 52428800
Cela oblige le système de fichiers de product.img
à avoir
50 Mio d'espace inutilisé
Modifications du système en tant que racine
Les appareils équipés d'Android 10 ne doivent pas utilisez le système en tant que racine.
Appareils dotés de partitions dynamiques (lancement ou adaptation
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
. system
est maintenant installé par
init
de premier étage, qui se trouve dans le ramdisk.
Ne définissez pas BOARD_BUILD_SYSTEM_ROOT_IMAGE
. Dans
Android 10, le
L'option BOARD_BUILD_SYSTEM_ROOT_IMAGE
n'est utilisée que pour
de différencier si le système est installé par le noyau ou par
init
de premier étage en ramdisk.
Définir BOARD_BUILD_SYSTEM_ROOT_IMAGE
sur true
une erreur de compilation
PRODUCT_USE_DYNAMIC_PARTITIONS
est également true
.
Lorsque BOARD_USES_RECOVERY_AS_BOOT
est défini sur "true",
est créée sous le nom boot.img, qui contient l'image
"ramdisk". Auparavant, le bootloader utilisait le noyau skip_initramfs
.
paramètre de ligne de commande pour décider
dans quel mode démarrer. Pour
Appareils Android 10, le bootloader NE DOIT PAS réussir
skip_initramfs
à la ligne de commande du noyau. Au lieu de cela, le bootloader
doit transmettre androidboot.force_normal_boot=1
pour ignorer la récupération
et démarrer un appareil Android normal. Appareils équipés d'Android 12
ou une version ultérieure doivent utiliser bootconfig pour transmettre androidboot.force_normal_boot=1
.
Modifications de la configuration AVB
<ph type="x-smartling-placeholder">Si vous utilisez Android Démarrage validé 2.0, si l'appareil n'utilise pas de partitions en chaîne de description, aucun changement n'est nécessaire. Si vous utilisez des chaînes des partitions, mais l'une des partitions validées est dynamique alors des changements sont nécessaires.
Voici un exemple de configuration pour un appareil
vbmeta
pour system
et
vendor
partitions.
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 vbmeta
pied de page à la fin des system
et
vendor
partitions. Comme ces partitions ne sont plus
visibles par le bootloader (ils se trouvent dans super
), deux
des changements sont nécessaires.
-
Ajouter
vbmeta_system
etvbmeta_vendor
des partitions à la table de partitionnement de l'appareil. Pour les appareils A/B, ajoutezvbmeta_system_a
,vbmeta_system_b
vbmeta_vendor_a
etvbmeta_vendor_b
. Si lorsque vous ajoutez une ou plusieurs de ces partitions, elles doivent avoir la même taille en tant que partitionvbmeta
. -
Renommez les options de configuration en ajoutant
VBMETA_
et Spécifiez à quelles partitions le chaînage s'étend: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 l'une de ces partitions, les deux ou aucune de ces partitions. Modifications ne sont nécessaires que lors du chaînage à une partition logique.
Modifications du bootloader AVB
Si le bootloader intègre libavb, incluent les correctifs suivants:
- 818cf56740775446285466eda984acedd4baeac0 — "libavb: N'interrogez les GUID de partition uniquement lorsque la ligne de commande a besoin eux."
- 5abd6bc2578968d24406d834471adfd995a0c2e9 — "Autoriser l'absence de la partition système"
- 9ba3b6613b4e5130fa01a11d984c6b5f0eb3af05 — "Fix AvbSlotVerifyData->cmdline could be NULL" (Fix AvbSlotVerifyData->cmdline peut être NULL)
Si vous utilisez des partitions en chaîne, incluez un correctif supplémentaire:
- 49936b4c0109411fdd38bd4ba3a32a01c40439a9 — "libavb: Prise en charge des blobs vbmeta au début de la partition." <ph type="x-smartling-placeholder">
Modifications de la ligne de commande du noyau
Un nouveau paramètre, androidboot.boot_devices
, doit être ajouté.
à la ligne de commande du noyau. Il est utilisé par init
pour
activer les liens symboliques /dev/block/by-name
. Il doit s'agir
du chemin d'accès de l'appareil au lien symbolique sous-jacent créé par
ueventd
, c'est-à-dire :
/dev/block/platform/device-path/by-name/partition-name
Les appareils équipés d'Android 12 ou version ultérieure doivent utiliser
bootconfig pour transmettre androidboot.boot_devices
à init
.
Par exemple, si le lien symbolique
de 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 en tant que
ce qui suit:
BOARD_KERNEL_CMDLINE += androidboot.boot_devices=soc/100000.ufshcVous pouvez ajouter le paramètre bootconfig dans le fichier BoardConfig.mk comme suit:
BOARD_BOOTCONFIG += androidboot.boot_devices=soc/100000.ufshc
modifications du fichier fstab
Les superpositions dans les arborescences d'appareils et d'appareils ne doivent pas contenir de fstab les entrées correspondantes. Utilisez un fichier fstab qui fera partie de ramdisk.
Vous devez modifier le fichier fstab pour les partitions logiques:
-
Le champ des options fs_mgr doit inclure l'option
logical
. et l'optionfirst_stage_mount
, introduite dans Android 10, qui indique qu'une partition doit être installé dans la première étape. -
Une partition peut spécifier
avb=vbmeta partition name
en tant que L'optionfs_mgr
, puis la valeurvbmeta
spécifiée est initialisée par la première étapeinit
avant d'installer des périphériques. -
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 logiques les partitions en suivant les 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<ph type="x-smartling-placeholder">
Copiez le fichier fstab dans le ramdisk de la première étape.
Modifications apportées à SELinux
Le périphérique de bloc de
superpartition doit être marqué avec l’étiquette
super_block_device
Par exemple, si le lien symbolique
de super-partition par nom 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 flash hors espace utilisateur) ne comprend pas des partitions dynamiques, et ne peut donc pas les flasher. Pour résoudre ce problème, les appareils doit utiliser une implémentation d'espace utilisateur du protocole fastboot, appelée fastbootd.
Pour en savoir plus sur l'implémentation de fastbootd, consultez Déplacer Fastboot vers un espace utilisateur.
réinstaller adb
Pour les développeurs qui utilisent des versions eng ou userdebug, adb remount
est extrêmement utile pour
une itération rapide. Les partitions dynamiques présentent
problème pour adb remount
, car l'offre n'est plus sans frais
dans chaque système de fichiers. Pour résoudre ce problème, les appareils peuvent activer
superfs. Tant qu'il y a de l'espace libre
dans la super partition,
adb remount
crée automatiquement une création dynamique temporaire
et utilise des superpositions pour les écritures. La partition temporaire est
nommé scratch
. Vous ne devez donc pas l'utiliser pour d'autres
des partitions.
Pour plus d'informations sur l'activation des superpositions, consultez la section overlayfs README dans AOSP.
Mettre à niveau les appareils Android
Si vous passez à Android 10 sur un appareil si vous souhaitez inclure les partitions dynamiques dans l'OTA, vous n'avez pas besoin de modifier la table de partition intégrée. Certaines configurations supplémentaires sont obligatoire.
Modifications apportées à la configuration de l'appareil
Pour adapter le partitionnement dynamique, ajoutez les options suivantes dans
device.mk
:
PRODUCT_USE_DYNAMIC_PARTITIONS := true PRODUCT_RETROFIT_DYNAMIC_PARTITIONS := true
Modifications de la configuration de la carte
Vous devez définir les variables de tableau suivantes:
- Définissez
BOARD_SUPER_PARTITION_BLOCK_DEVICES
sur la liste des appareils de stockage en mode bloc utilisés. pour stocker des fragments de partitions dynamiques. Il s'agit de la liste des noms des appareils des partitions sur le périphérique. - Définir
BOARD_SUPER_PARTITION_partition_DEVICE_SIZE
sur les tailles de chaque appareil en mode bloc dansBOARD_SUPER_PARTITION_BLOCK_DEVICES
, respectivement. Il s'agit de la liste des tailles des partitions physiques existantes sur l'appareil. C'est généralementBOARD_partitionIMAGE_PARTITION_SIZE
dans le tableau existant de configuration. - Ne plus définir les
BOARD_partitionIMAGE_PARTITION_SIZE
existants pour tous partitions dansBOARD_SUPER_PARTITION_BLOCK_DEVICES
. - Définissez
BOARD_SUPER_PARTITION_SIZE
sur la somme deBOARD_SUPER_PARTITION_partition_DEVICE_SIZE
- Définissez
BOARD_SUPER_PARTITION_METADATA_DEVICE
sur l'appareil de stockage en mode bloc où les métadonnées de partition dynamique sont stockées. Il doit s'agir deBOARD_SUPER_PARTITION_BLOCK_DEVICES
En général, il est défini sursystem
- Définir
BOARD_SUPER_PARTITION_GROUPS
,BOARD_group_SIZE
BOARD_group_PARTITION_LIST
, respectivement. Voir Modifications de la configuration de la carte sur les nouveaux appareils pour en savoir plus.
Par exemple, si l'appareil dispose déjà de partitions système et de fournisseurs, et que vous souhaitez convertir vers des partitions dynamiques et ajouter une nouvelle partition de produits lors de 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 périphériques de bloc de superpartition doivent être marqués avec l'attribut
super_block_device_type
Par exemple, si l'appareil a déjà
partitions system
et vendor
, vous souhaitez les utiliser comme bloc
appareils pour stocker des étendues 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 les autres configurations, reportez-vous à la section Implémentation les partitions dynamiques sur les nouveaux appareils.
Pour en savoir plus sur les mises à jour de rétrofit, consultez OTA pour les appareils A/B sans flux dynamique Partitions.
Images d'usine
Pour un appareil qui prend en charge les partitions dynamiques, évitez d'utiliser l'espace utilisateur fastboot vers les images d'usine flash, car le démarrage vers l'espace utilisateur est plus lentement que les autres méthodes de clignotement.
Pour résoudre ce problème, make dist
crée désormais une couche supplémentaire
Image super.img
qui peut être flashée directement sur le bouton Super
partition. Elle regroupe automatiquement le contenu des
partitions, ce qui signifie qu'elle contient system.img
,
vendor.img
, etc., en plus de super
métadonnées de partition. Cette image peut être flashée directement sur la
partition super
sans outil supplémentaire ni utilisation
fastbootd. Après la compilation, super.img
est placé dans
${ANDROID_PRODUCT_OUT}
Pour les appareils A/B
lancés avec des partitions dynamiques,
super.img
contient des images dans l'emplacement A. Après avoir flashé,
directement sur l'image, marquez l'emplacement A comme amorçable avant de redémarrer
appareil.
Pour les appareils rétrofit, make dist
crée un ensemble de
super_*.img
images qui peuvent être flashées directement sur
des partitions physiques correspondantes. Exemple : make dist
construit super_system.img
et super_vendor.img
lorsque BOARD_SUPER_PARTITION_BLOCK_DEVICES
est le système
fournisseur. Ces images sont placées dans le dossier OTA dans
target_files.zip
Réglage de l'appareil de stockage du mappeur d'appareil
Le partitionnement dynamique est compatible avec un certain nombre d'outils de mappage d'appareils non déterministes. d'objets. Il est possible que ces éléments ne soient pas tous instanciés comme prévu, vous devez donc les suivre et de mettre à jour les propriétés Android de toutes les partitions associées leurs périphériques de stockage sous-jacents.
Un mécanisme dans init
suit les installations et de manière asynchrone
met à jour les propriétés Android. Le temps nécessaire à cette opération n'est pas garanti
se situent dans une période précise. Vous devez donc prévoir suffisamment de temps
pour que tous les déclencheurs on property
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 base de l'appareil de stockage, 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 aux propriétés Android d'être
étendu conformément aux règles, et les périphériques de stockage peuvent être réglés par la plate-forme
au besoin, à 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 des commandes a commencé à l'é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 du init
, ils
ne peut pas être utilisée lors des étapes de démarrage initiales pour gérer root
.
system
ou vendor
. Attendez-vous à ce que
la valeur par défaut du noyau (read_ahead_kb
) est suffisante jusqu'à ce que le
Les scripts init.rc
peuvent être remplacés dans early-fs
(lorsque
plusieurs daemons et installations démarrent). Par conséquent, Google recommande que
vous utilisez la fonctionnalité on property
, associée à
propriété contrôlée par init.rc
comme sys.read_ahead_kb
,
pour gérer la planification des opérations et éviter les conditions de concurrence,
exemples:
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}