Implementare partizioni dinamiche

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.

Layout della tabella delle partizioni
Figura 1. Nuovo layout della tabella delle partizioni fisiche durante 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 e vbmeta_vendor alla tabella delle partizioni del dispositivo. Per i dispositivi A/B, aggiungi vbmeta_system_a , vbmeta_system_b , vbmeta_vendor_a e vbmeta_vendor_b . Se si aggiunge una o più di queste partizioni, queste dovrebbero avere le stesse dimensioni della partizione vbmeta .
  • 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:

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 flag first_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 flag fs_mgr e quindi la partizione vbmeta specificata viene inizializzata dalla prima fase init 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 in BOARD_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 in BOARD_SUPER_PARTITION_BLOCK_DEVICES .
  • Imposta BOARD_SUPER_PARTITION_SIZE sulla somma della BOARD_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 tra BOARD_SUPER_PARTITION_BLOCK_DEVICES . Di solito, è impostato su system .
  • Impostare BOARD_SUPER_PARTITION_GROUPS , BOARD_ group _SIZE e BOARD_ 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}