Il partizionamento dinamico viene implementato utilizzando il modulo dm-linear device-mapper nel kernel Linux. La super
partizione contiene metadati che elencano i nomi e gli intervalli di blocchi di ciascuna partizione dinamica all'interno di super
. Durante la prima fase init
, questi metadati vengono analizzati e convalidati e vengono creati dispositivi a blocchi virtuali per rappresentare ciascuna partizione dinamica.
Quando si applica un'OTA, le partizioni dinamiche vengono create, ridimensionate o eliminate automaticamente in base alle esigenze. Per i dispositivi A/B, sono presenti due copie dei metadati e le modifiche vengono applicate solo alla copia che rappresenta lo slot di destinazione.
Poiché le partizioni dinamiche sono implementate nello spazio utente, le partizioni necessarie al bootloader non possono essere rese dinamiche. Ad esempio, boot
, dtbo
e vbmeta
vengono letti dal bootloader e quindi devono rimanere come partizioni fisiche.
Ciascuna partizione dinamica può appartenere a un gruppo di aggiornamento . Questi gruppi limitano lo spazio massimo che le partizioni di quel gruppo possono utilizzare. Ad esempio, system
e vendor
possono appartenere a un gruppo che limita la dimensione totale di system
e vendor
.
Implementare partizioni dinamiche sui nuovi dispositivi
Questa sezione descrive in dettaglio come implementare le partizioni dinamiche sui nuovi dispositivi avviati con Android 10 e versioni successive. Per aggiornare i dispositivi esistenti, vedere Aggiornamento dei dispositivi Android .
Modifiche alla partizione
Per i dispositivi avviati con Android 10, crea una partizione chiamata super
. La super
partizione gestisce internamente gli slot A/B, quindi i dispositivi A/B non necessitano di partizioni super_a
e super_b
separate. Tutte le partizioni AOSP di sola lettura che non vengono utilizzate dal bootloader devono essere dinamiche e devono essere rimosse dalla tabella delle partizioni GUID (GPT). Le partizioni specifiche del fornitore non devono essere dinamiche e possono essere inserite nel GPT.
Per stimare la dimensione di super
, aggiungi le dimensioni delle partizioni da eliminare dal GPT. Per i dispositivi A/B, ciò dovrebbe includere la dimensione di entrambi gli slot. La Figura 1 mostra un esempio di tabella delle partizioni prima e dopo la conversione in partizioni dinamiche.
Le partizioni dinamiche supportate sono:
- Sistema
- Venditore
- Prodotto
- Sistema est
- ODM
Per i dispositivi avviati con Android 10, l'opzione della riga di comando del kernel androidboot.super_partition
deve essere vuota in modo che il comando sysprop ro.boot.super_partition
sia vuoto.
Allineamento delle partizioni
Il modulo di mappatura dei dispositivi potrebbe funzionare in modo meno efficiente se la super
partizione non è allineata correttamente. La super
partizione DEVE essere allineata alla dimensione minima della richiesta I/O determinata dal livello di blocco. Per impostazione predefinita, il sistema di compilazione (tramite lpmake
, che genera l'immagine della super
partizione), presuppone che un allineamento di 1 MiB sia sufficiente per ogni partizione dinamica. Tuttavia, i fornitori dovrebbero garantire che la super
partizione sia correttamente allineata.
Puoi determinare la dimensione minima della richiesta di un dispositivo a blocchi controllando sysfs
. Per esempio:
# 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
Puoi verificare l'allineamento della super
partizione in modo simile:
# cat /sys/block/sda/sda17/alignment_offset
L'offset di allineamento DEVE essere 0.
Modifiche alla configurazione del dispositivo
Per abilitare il partizionamento dinamico, aggiungi il seguente flag in device.mk
:
PRODUCT_USE_DYNAMIC_PARTITIONS := true
Modifiche alla configurazione della scheda
Devi impostare la dimensione della super
partizione:
BOARD_SUPER_PARTITION_SIZE := <size-in-bytes>
Sui dispositivi A/B, il sistema di compilazione genera un errore se la dimensione totale delle immagini della partizione dinamica è superiore alla metà della dimensione della super
partizione.
È possibile configurare l'elenco delle partizioni dinamiche come segue. Per i dispositivi che utilizzano gruppi di aggiornamento, elenca i gruppi nella variabile BOARD_SUPER_PARTITION_GROUPS
. Ogni nome di gruppo ha quindi una variabile BOARD_ group _SIZE
e BOARD_ group _PARTITION_LIST
. Per i dispositivi A/B, la dimensione massima di un gruppo dovrebbe coprire un solo slot, poiché i nomi dei gruppi hanno un suffisso slot interno.
Ecco un dispositivo di esempio che inserisce tutte le partizioni in un gruppo chiamato 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
Ecco un esempio di dispositivo che inserisce i servizi di sistema e di prodotto in group_foo
e vendor
, product
e odm
in 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
- Per i dispositivi di lancio A/B virtuali, la somma delle dimensioni massime di tutti i gruppi deve essere al massimo:
BOARD_SUPER_PARTITION_SIZE
- sovraccarico
Vedere Implementazione di A/B virtuale . - Per i dispositivi di lancio A/B, la somma delle dimensioni massime di tutti i gruppi deve essere:
BOARD_SUPER_PARTITION_SIZE
/ 2 - sopraelevato - Per i dispositivi non A/B e i dispositivi A/B retrofit, la somma delle dimensioni massime di tutti i gruppi deve essere:
BOARD_SUPER_PARTITION_SIZE
- sovraccarico - In fase di creazione, la somma delle dimensioni delle immagini di ciascuna partizione in un gruppo di aggiornamento non deve superare la dimensione massima del gruppo.
- Nel calcolo è necessario un sovraccarico per tenere conto di metadati, allineamenti e così via. Un sovraccarico ragionevole è 4 MiB, ma è possibile scegliere un sovraccarico maggiore in base alle esigenze del dispositivo.
Dimensioni delle partizioni dinamiche
Prima delle partizioni dinamiche, le dimensioni delle partizioni venivano sovraallocate per garantire che avessero spazio sufficiente per futuri aggiornamenti. La dimensione effettiva è stata presa così com'è e la maggior parte delle partizioni di sola lettura avevano una certa quantità di spazio libero nel file system. Nelle partizioni dinamiche, lo spazio libero è inutilizzabile e potrebbe essere utilizzato per aumentare le partizioni durante un'OTA. È fondamentale garantire che le partizioni non sprechino spazio e siano allocate alla dimensione minima possibile.
Per le immagini ext4 di sola lettura, il sistema di compilazione alloca automaticamente la dimensione minima se non viene specificata alcuna dimensione della partizione codificata. Il sistema di compilazione si adatta all'immagine in modo che il file system abbia il minor spazio inutilizzato possibile. Ciò garantisce che il dispositivo non sprechi spazio che può essere utilizzato per le OTA.
Inoltre, le immagini ext4 possono essere ulteriormente compresse abilitando la deduplicazione a livello di blocco. Per abilitarlo, utilizzare la seguente configurazione:
BOARD_EXT4_SHARE_DUP_BLOCKS := true
Se l'allocazione automatica della dimensione minima di una partizione non è auspicabile, esistono due modi per controllare la dimensione della partizione. È possibile specificare una quantità minima di spazio libero con BOARD_ partition IMAGE_PARTITION_RESERVED_SIZE
oppure è possibile specificare BOARD_ partition IMAGE_PARTITION_SIZE
per forzare le partizioni dinamiche a una dimensione specifica. Nessuno di questi è consigliato a meno che non sia necessario.
Per esempio:
BOARD_PRODUCTIMAGE_PARTITION_RESERVED_SIZE := 52428800
Ciò impone al file system in product.img
di avere 50 MiB di spazio inutilizzato.
Modifiche al sistema come root
I dispositivi avviati con Android 10 non devono utilizzare system-as-root.
I dispositivi con partizioni dinamiche (sia che si avviino con o eseguano partizioni dinamiche) non devono utilizzare system-as-root. Il kernel Linux non può interpretare la super
partizione e quindi non può montare system
stesso. system
è ora montato dal primo stadio init
, che risiede nel ramdisk.
Non impostare BOARD_BUILD_SYSTEM_ROOT_IMAGE
. In Android 10, il flag BOARD_BUILD_SYSTEM_ROOT_IMAGE
viene utilizzato solo per differenziare se il sistema è montato dal kernel o init
della prima fase in ramdisk.
L'impostazione di BOARD_BUILD_SYSTEM_ROOT_IMAGE
su true
provoca un errore di compilazione quando anche PRODUCT_USE_DYNAMIC_PARTITIONS
è true
.
Quando BOARD_USES_RECOVERY_AS_BOOT
è impostato su true, l'immagine di ripristino viene creata come boot.img, contenente il ramdisk di ripristino. In precedenza, il bootloader utilizzava il parametro della riga di comando del kernel skip_initramfs
per decidere in quale modalità avviare. Per i dispositivi Android 10, il bootloader NON DEVE passare skip_initramfs
alla riga di comando del kernel. Invece, il bootloader dovrebbe passare androidboot.force_normal_boot=1
per saltare il ripristino e avviare Android normale. I dispositivi avviati con Android 12 o versioni successive devono utilizzare bootconfig per passare androidboot.force_normal_boot=1
.
Modifiche alla configurazione AVB
Quando si utilizza Android Verified Boot 2.0 , se il dispositivo non utilizza descrittori di partizioni concatenate , non è necessaria alcuna modifica. Se si utilizzano partizioni concatenate, tuttavia, e una delle partizioni verificate è dinamica, sono necessarie modifiche.
Di seguito è riportato un esempio di configurazione per un dispositivo che concatena vbmeta
per le partizioni system
e 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
Con questa configurazione, il bootloader si aspetta di trovare un piè di pagina vbmeta alla fine delle partizioni del system
e vendor
. Poiché queste partizioni non sono più visibili al bootloader (risiedono in super
), sono necessarie due modifiche.
- Aggiungi le partizioni
vbmeta_system
evbmeta_vendor
alla tabella delle partizioni del dispositivo. Per i dispositivi A/B, aggiungivbmeta_system_a
,vbmeta_system_b
,vbmeta_vendor_a
evbmeta_vendor_b
. Se si aggiunge una o più di queste partizioni, queste dovrebbero avere le stesse dimensioni della partizionevbmeta
. - Rinominare i flag di configurazione aggiungendo
VBMETA_
e specificare a quali partizioni si estende il concatenamento: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 dispositivo potrebbe utilizzare una, entrambe o nessuna di queste partizioni. Le modifiche sono necessarie solo durante il concatenamento a una partizione logica.
Modifiche al bootloader AVB
Se il bootloader ha incorporato libavb , includi le seguenti patch:
- 818cf56740775446285466eda984acedd4baeac0 — "libavb: interroga i GUID delle partizioni solo quando la riga cmd ne ha bisogno."
- 5abd6bc2578968d24406d834471adfd995a0c2e9 — "Consenti l'assenza della partizione di sistema"
- 9ba3b6613b4e5130fa01a11d984c6b5f0eb3af05 — "Correggi AvbSlotVerifyData->cmdline potrebbe essere NULL"
Se si utilizzano partizioni concatenate, includere una patch aggiuntiva:
- 49936b4c0109411fdd38bd4ba3a32a01c40439a9 — "libavb: supporta i BLOB vbmeta all'inizio della partizione."
Modifiche alla riga di comando del kernel
Un nuovo parametro, androidboot.boot_devices
, deve essere aggiunto alla riga di comando del kernel. Viene utilizzato da init
per abilitare i collegamenti simbolici /dev/block/by-name
. Dovrebbe essere il componente del percorso del dispositivo al collegamento simbolico sottostante per nome creato da ueventd
, ovvero /dev/block/platform/ device-path /by-name/ partition-name
. I dispositivi avviati con Android 12 o versioni successive devono utilizzare bootconfig per passare androidboot.boot_devices
a init
.
Ad esempio, se il collegamento simbolico per nome della super partizione è /dev/block/platform/ soc/100000.ufshc /by-name/super
, è possibile aggiungere il parametro della riga di comando nel file BoardConfig.mk come segue:
BOARD_KERNEL_CMDLINE += androidboot.boot_devices=soc/100000.ufshcÈ possibile aggiungere il parametro bootconfig nel file BoardConfig.mk come segue:
BOARD_BOOTCONFIG += androidboot.boot_devices=soc/100000.ufshc
modifiche a fstab
L'albero dei dispositivi e le sovrapposizioni dell'albero dei dispositivi non devono contenere voci fstab. Utilizza un file fstab che farà parte del ramdisk.
È necessario apportare modifiche al file fstab per le partizioni logiche:
- Il campo fs_mgr flags deve includere il flag
logical
e il flagfirst_stage_mount
, introdotto in Android 10, che indica che una partizione deve essere montata nel primo stage. - Una partizione può specificare
avb= vbmeta partition name
come flagfs_mgr
e quindi la partizionevbmeta
specificata viene inizializzata dalla prima faseinit
prima di tentare di montare qualsiasi dispositivo. - Il campo
dev
deve essere il nome della partizione.
Le seguenti voci fstab impostano sistema, fornitore e prodotto come partizioni logiche seguendo le regole di cui sopra.
#<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
Copia il file fstab nel ramdisk della prima fase.
SELinux cambia
Il dispositivo a blocchi della super partizione deve essere contrassegnato con l'etichetta super_block_device
. Ad esempio, se il collegamento simbolico per nome della super partizione è /dev/block/platform/ soc/100000.ufshc /by-name/super
, aggiungi la seguente riga a file_contexts
:
/dev/block/platform/soc/10000\.ufshc/by-name/super u:object_r:super_block_device:s0
fastbootd
Il bootloader (o qualsiasi strumento di flashing non userspace) non comprende le partizioni dinamiche, quindi non può flasharle. Per risolvere questo problema, i dispositivi devono utilizzare un'implementazione dello spazio utente del protocollo fastboot, chiamata fastbootd.
Per ulteriori informazioni su come implementare fastbootd, vedere Spostamento di Fastboot nello spazio utente .
adb rimontare
Per gli sviluppatori che utilizzano build eng o userdebug, adb remount
è estremamente utile per un'iterazione rapida. Le partizioni dinamiche rappresentano un problema per adb remount
perché non c'è più spazio libero all'interno di ciascun file system. Per risolvere questo problema, i dispositivi possono abilitare gli overlayf. Finché c'è spazio libero all'interno della super partizione, adb remount
crea automaticamente una partizione dinamica temporanea e utilizza overlayfs per le scritture. La partizione temporanea è denominata scratch
, quindi non utilizzare questo nome per altre partizioni.
Per ulteriori informazioni su come abilitare overlayfs, vedere il README di overlayfs in AOSP.
Aggiorna i dispositivi Android
Se aggiorni un dispositivo ad Android 10 e desideri includere il supporto delle partizioni dinamiche nell'OTA, non è necessario modificare la tabella delle partizioni integrata. È necessaria una configurazione aggiuntiva.
Modifiche alla configurazione del dispositivo
Per aggiornare il partizionamento dinamico, aggiungi i seguenti flag in device.mk
:
PRODUCT_USE_DYNAMIC_PARTITIONS := true PRODUCT_RETROFIT_DYNAMIC_PARTITIONS := true
Modifiche alla configurazione della scheda
Ti viene richiesto di impostare le seguenti variabili della scheda:
- Imposta
BOARD_SUPER_PARTITION_BLOCK_DEVICES
sull'elenco dei dispositivi a blocchi utilizzati per archiviare le estensioni delle partizioni dinamiche. Questo è l'elenco dei nomi delle partizioni fisiche esistenti sul dispositivo. - Imposta
BOARD_SUPER_PARTITION_ partition _DEVICE_SIZE
rispettivamente sulle dimensioni di ciascun dispositivo a blocchi inBOARD_SUPER_PARTITION_BLOCK_DEVICES
. Questo è l'elenco delle dimensioni delle partizioni fisiche esistenti sul dispositivo. Di solito èBOARD_ partition IMAGE_PARTITION_SIZE
nelle configurazioni della scheda esistenti. - Annulla
BOARD_ partition IMAGE_PARTITION_SIZE
per tutte le partizioni inBOARD_SUPER_PARTITION_BLOCK_DEVICES
. - Imposta
BOARD_SUPER_PARTITION_SIZE
sulla somma dellaBOARD_SUPER_PARTITION_ partition _DEVICE_SIZE
. - Imposta
BOARD_SUPER_PARTITION_METADATA_DEVICE
sul dispositivo a blocchi in cui sono archiviati i metadati della partizione dinamica. Deve essere uno traBOARD_SUPER_PARTITION_BLOCK_DEVICES
. Di solito, è impostato susystem
. - Impostare
BOARD_SUPER_PARTITION_GROUPS
,BOARD_ group _SIZE
eBOARD_ group _PARTITION_LIST
, rispettivamente. Per i dettagli vedere Modifiche alla configurazione della scheda sui nuovi dispositivi .
Ad esempio, se il dispositivo dispone già di partizioni di sistema e del fornitore e desideri convertirle in partizioni dinamiche e aggiungere una nuova partizione di prodotto durante l'aggiornamento, imposta questa configurazione della scheda:
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
SELinux cambia
I dispositivi a blocchi della super partizione devono essere contrassegnati con l'attributo super_block_device_type
. Ad esempio, se il dispositivo dispone già di partizioni system
e vendor
, si desidera utilizzarle come dispositivi a blocchi per archiviare estensioni di partizioni dinamiche e i relativi collegamenti simbolici per nome sono contrassegnati come 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
Quindi, aggiungi la seguente riga a device.te
:
typeattribute system_block_device super_block_device_type;
Per altre configurazioni, vedere Implementazione di partizioni dinamiche su nuovi dispositivi .
Per ulteriori informazioni sugli aggiornamenti di retrofit, consulta OTA per dispositivi A/B senza partizioni dinamiche .
Immagini di fabbrica
Per l'avvio di un dispositivo con supporto per partizioni dinamiche, evitare di utilizzare l'avvio rapido dello spazio utente per eseguire il flashing delle immagini di fabbrica, poiché l'avvio nello spazio utente è più lento rispetto ad altri metodi di flashing.
Per risolvere questo problema, make dist
ora crea un'immagine super.img
aggiuntiva che può essere flashata direttamente nella super partizione. Raggruppa automaticamente il contenuto delle partizioni logiche, ovvero contiene system.img
, vendor.img
e così via, oltre ai metadati della super
partizione. Questa immagine può essere flashata direttamente nella super
partizione senza strumenti aggiuntivi o utilizzando fastbootd. Dopo la creazione, super.img
viene inserito in ${ANDROID_PRODUCT_OUT}
.
Per i dispositivi A/B avviati con partizioni dinamiche, super.img
contiene immagini nello slot A. Dopo aver eseguito direttamente il flashing della super immagine, contrassegnare lo slot A come avviabile prima di riavviare il dispositivo.
Per i dispositivi retrofit, make dist
crea un set di immagini super_*.img
che possono essere flashate direttamente sulle partizioni fisiche corrispondenti. Ad esempio, make dist
crea super_system.img
e super_vendor.img
quando BOARD_SUPER_PARTITION_BLOCK_DEVICES
è il fornitore del sistema. Queste immagini vengono inserite nella cartella OTA in target_files.zip
.
Ottimizzazione del dispositivo di archiviazione del mapping dei dispositivi
Il partizionamento dinamico ospita un numero di oggetti di mappatura di dispositivi non deterministici. Potrebbero non essere tutte istanziate come previsto, quindi è necessario tenere traccia di tutti i montaggi e aggiornare le proprietà Android di tutte le partizioni associate con i relativi dispositivi di archiviazione sottostanti.
Un meccanismo all'interno di init
tiene traccia dei montaggi e aggiorna in modo asincrono le proprietà di Android. Non è garantito che il tempo necessario rientri in un periodo specifico, quindi è necessario fornire tempo sufficiente affinché tutti gli attivatori on property
possano reagire. Le proprietà sono dev.mnt.blk. <partition>
dove <partition>
è root
, system
, data
o vendor
, ad esempio. Ogni proprietà è associata al nome del dispositivo di archiviazione di base, come mostrato in questi esempi:
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]
Il linguaggio init.rc
consente di espandere le proprietà di Android come parte delle regole e i dispositivi di archiviazione possono essere ottimizzati dalla piattaforma secondo necessità con comandi come questi:
write /sys/block/${dev.mnt.blk.root}/queue/read_ahead_kb 128 write /sys/block/${dev.mnt.blk.data}/queue/read_ahead_kb 128
Una volta avviata l'elaborazione dei comandi nella seconda fase init
, il epoll loop
diventa attivo e i valori iniziano ad aggiornarsi. Tuttavia, poiché i trigger di proprietà non sono attivi fino alla fase late- init
, non possono essere utilizzati nelle fasi iniziali di avvio per gestire root
, system
o vendor
. Potresti aspettarti che il valore predefinito del kernel read_ahead_kb
sia sufficiente finché gli script init.rc
non potranno sovrascrivere in early-fs
(quando vengono avviati vari demoni e funzionalità). Pertanto, Google consiglia di utilizzare la funzione on property
, insieme a una proprietà controllata init.rc
come sys.read_ahead_kb
, per gestire la tempistica delle operazioni e prevenire condizioni di competizione, come in questi esempi:
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}