Implementare partizioni dinamiche

Il partizionamento dinamico viene implementato utilizzando il modulo dm-linear device-mapper nel kernel Linux. La partizione super contiene i metadati che elencano i nomi e gli intervalli di blocchi di ogni partizione dinamica all'interno di super. Durante la prima fase di init, questi metadati vengono analizzati e convalidati e vengono creati dispositivi a blocchi virtuali per rappresentare ogni partizione dinamica.

Quando viene applicato un aggiornamento OTA, le partizioni dinamiche vengono create, ridimensionate o eliminate automaticamente in base alle esigenze. Per i dispositivi A/B, esistono 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 dal bootloader non possono essere rese dinamiche. Ad esempio, boot, dtbo e vbmeta vengono lette dal bootloader e quindi devono rimanere come partizioni fisiche.

Ogni partizione dinamica può appartenere a un gruppo di aggiornamento. Questi gruppi limitano lo spazio massimo che le partizioni del gruppo possono consumare. Ad esempio, system e vendor possono appartenere a un gruppo che limita le dimensioni totali di system e vendor.

Implementare partizioni dinamiche sui nuovi dispositivi

Questa sezione descrive in dettaglio come implementare le partizioni dinamiche sui nuovi dispositivi che verranno lanciati con Android 10 e versioni successive. Per aggiornare i dispositivi esistenti, vedi Eseguire l'upgrade dei dispositivi Android.

Modifiche alle partizioni

Per i dispositivi lanciati con Android 10, crea una partizione chiamata super. La partizione super gestisce internamente gli slot A/B, quindi i dispositivi A/B non hanno bisogno di partizioni super_a e super_b separate. Tutte le partizioni AOSP di sola lettura non 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 le dimensioni di super, somma le dimensioni delle partizioni eliminate dalla GPT. Per i dispositivi A/B, questo deve includere le dimensioni di entrambi gli slot. La Figura 1 mostra una tabella delle partizioni di esempio prima e dopo la conversione in partizioni dinamiche.

Le partizioni dinamiche supportate sono:

• Sistema
• Fornitore
• Prodotto
• Estensione del sistema
• ODM

Per i dispositivi lanciati 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 Device Mapper potrebbe funzionare in modo meno efficiente se la partizione super non è allineata correttamente. La partizione super 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 partizione super) presuppone che un allineamento di 1 MiB sia sufficiente per ogni partizione dinamica. Tuttavia, i fornitori devono assicurarsi che la partizione super sia allineata correttamente.

Puoi determinare le dimensioni minime della richiesta di un dispositivo a blocchi ispezionando sysfs. Ad 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 partizione super in modo simile:

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

L'offset di allineamento DEVE essere 0.

Modifiche alla configurazione del dispositivo

Per attivare il partizionamento dinamico, aggiungi il seguente flag in device.mk:

PRODUCT_USE_DYNAMIC_PARTITIONS := true

Modifiche alla configurazione della lavagna

Devi impostare le dimensioni della partizione super:

BOARD_SUPER_PARTITION_SIZE := <size-in-bytes>

Sui dispositivi A/B, il sistema di build genera un errore se la dimensione totale delle immagini delle partizioni dinamiche è superiore alla metà della dimensione della partizione super.

Puoi configurare l'elenco delle partizioni dinamiche nel seguente modo. Per i dispositivi che utilizzano gruppi di aggiornamento, elenca i gruppi nella variabile BOARD_SUPER_PARTITION_GROUPS. Ogni nome del gruppo ha poi una variabile BOARD_group_SIZE e BOARD_group_PARTITION_LIST. Per i dispositivi A/B, la dimensione massima di un gruppo deve coprire un solo slot, poiché i nomi dei gruppi hanno internamente il suffisso dello slot.

Ecco un esempio di dispositivo che inserisce tutte le partizioni in un gruppo denominato 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, 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 virtuale, la somma delle dimensioni massime di tutti i gruppi deve essere al massimo:
  BOARD_SUPER_PARTITION_SIZE - overhead
  Consulta 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 - overhead
• Per i dispositivi non A/B e i dispositivi A/B di retrofit, la somma delle dimensioni massime di tutti i gruppi deve essere:
  BOARD_SUPER_PARTITION_SIZE - overhead
• Al momento della creazione, la somma delle dimensioni delle immagini di ogni partizione in un gruppo di aggiornamento non deve superare la dimensione massima del gruppo.
• L'overhead è necessario nel calcolo per tenere conto di metadati, allineamenti e così via. Un overhead ragionevole è 4 MiB, ma puoi scegliere un overhead più grande in base alle esigenze del dispositivo.

Partizioni dinamiche delle dimensioni

Prima delle partizioni dinamiche, le dimensioni delle partizioni venivano allocate in eccesso per assicurarsi che avessero spazio sufficiente per gli aggiornamenti futuri. Le dimensioni effettive sono state prese così com'erano e la maggior parte delle partizioni di sola lettura aveva una certa quantità di spazio libero nel file system. Nelle partizioni dinamiche, lo spazio libero non è utilizzabile e potrebbe essere utilizzato per aumentare le partizioni durante un aggiornamento OTA. È fondamentale assicurarsi che le partizioni non sprechino spazio e che siano allocate a una dimensione minima possibile.

Per le immagini ext4 di sola lettura, il sistema di build alloca automaticamente la dimensione minima se non viene specificata alcuna dimensione della partizione hardcoded. Il sistema di compilazione adatta l'immagine in modo che il file system abbia il minor spazio inutilizzato possibile. In questo modo, il dispositivo non spreca spazio che può essere utilizzato per gli aggiornamenti OTA.

Inoltre, le immagini ext4 possono essere ulteriormente compresse attivando la deduplicazione a livello di blocco. Per attivare questa funzionalità, utilizza la seguente configurazione:

BOARD_EXT4_SHARE_DUP_BLOCKS := true

Se l'allocazione automatica di una dimensione minima della partizione non è auspicabile, esistono due modi per controllare la dimensione della partizione. Puoi specificare una quantità minima di spazio libero con BOARD_partitionIMAGE_PARTITION_RESERVED_SIZE, oppure puoi specificare BOARD_partitionIMAGE_PARTITION_SIZE per forzare le partizioni dinamiche a una dimensione specifica. Nessuna delle due opzioni è consigliata se non necessaria.

Ad esempio:

BOARD_PRODUCTIMAGE_PARTITION_RESERVED_SIZE := 52428800

In questo modo, il file system in product.img avrà 50 MiB di spazio inutilizzato.

Modifiche al sistema come root

I dispositivi lanciati con Android 10 non devono utilizzare system-as-root.

I dispositivi con partizioni dinamiche (che vengano lanciati con partizioni dinamiche o che le adattino) non devono utilizzare system-as-root. Il kernel Linux non può interpretare la partizione super e quindi non può montare system. system è ora montato dalla prima fase init, che si trova 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 dalla init di prima fase in ramdisk.

L'impostazione di BOARD_BUILD_SYSTEM_ROOT_IMAGE su true causa un errore di build quando PRODUCT_USE_DYNAMIC_PARTITIONS è anche 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 il sistema. Per i dispositivi Android 10, il bootloader NON DEVE passare skip_initramfs alla riga di comando del kernel. Il bootloader deve passare androidboot.force_normal_boot=1 per saltare il ripristino e avviare Android normalmente. I dispositivi lanciati con Android 12 o versioni successive devono utilizzare bootconfig per trasmettere androidboot.force_normal_boot=1.

Modifiche alla configurazione AVB

Quando utilizzi Android Verified Boot 2.0, se il dispositivo non utilizza descrittori di partizione concatenati, non è necessaria alcuna modifica. Se utilizzi partizioni concatenate, tuttavia, e una delle partizioni verificate è dinamica, sono necessarie modifiche.

Ecco 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 prevede di trovare un piè di pagina vbmeta alla fine delle partizioni system e vendor. Poiché queste partizioni non sono più visibili al bootloader (si trovano in super), sono necessarie due modifiche.

• Aggiungi le partizioni vbmeta_system e vbmeta_vendor alla tabella di partizione del dispositivo. Per i dispositivi A/B, aggiungi vbmeta_system_a, vbmeta_system_b, vbmeta_vendor_a e vbmeta_vendor_b. Se aggiungi una o più di queste partizioni, devono avere le stesse dimensioni della partizione vbmeta.
• Rinomina i flag di configurazione aggiungendo VBMETA_ e specifica 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 quando si esegue il collegamento a una partizione logica.

Modifiche al bootloader AVB

Se il bootloader ha incorporato libavb, includi le seguenti patch:

• 818cf56740775446285466eda984acedd4baeac0 — "libavb: Only query partition GUIDs when the cmdline needs them."
• 5abd6bc2578968d24406d834471adfd995a0c2e9 — "Allow system partition to be absent" (Consenti l'assenza della partizione di sistema)
• 9ba3b6613b4e5130fa01a11d984c6b5f0eb3af05 — "Fix AvbSlotVerifyData->cmdline might be NULL"

Se utilizzi partizioni concatenate, includi una patch aggiuntiva:

• 49936b4c0109411fdd38bd4ba3a32a01c40439a9 — "libavb: Support vbmeta blobs in beginning of partition."

Modifiche alla riga di comando del kernel

Alla riga di comando del kernel deve essere aggiunto un nuovo parametro, androidboot.boot_devices. Viene utilizzato da init per abilitare i link simbolici /dev/block/by-name. Deve essere il componente del percorso del dispositivo al collegamento simbolico sottostante creato da ueventd, ovvero /dev/block/platform/device-path/by-name/partition-name. I dispositivi lanciati con Android 12 o versioni successive devono utilizzare bootconfig per passare androidboot.boot_devices a init.

Ad esempio, se il link simbolico by-name della super partizione è /dev/block/platform/soc/100000.ufshc/by-name/super, puoi aggiungere il parametro della riga di comando nel file BoardConfig.mk come segue:

BOARD_KERNEL_CMDLINE += androidboot.boot_devices=soc/100000.ufshc

BOARD_BOOTCONFIG += androidboot.boot_devices=soc/100000.ufshc

modifiche a fstab

L'albero dei dispositivi e gli overlay dell'albero dei dispositivi non devono contenere voci fstab. Utilizza un file fstab che farà parte del ramdisk.

Per le partizioni logiche devono essere apportate modifiche al file fstab:

• Il campo dei flag fs_mgr deve includere il flag logical e il flag first_stage_mount, introdotto in Android 10, che indica che una partizione deve essere montata nella prima fase.
• 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 system, vendor e product come partizioni logiche in base alle regole precedenti.

#<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.

Modifiche a SELinux

Il dispositivo a blocchi della superpartizione deve essere contrassegnato con l'etichetta super_block_device. Ad esempio, se il collegamento simbolico della super partizione per nome è /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 riconosce le partizioni dinamiche, quindi non può eseguirne il flashing. 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, consulta Spostare Fastboot nello spazio utente.

adb remount

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 è più presente spazio libero all'interno di ogni file system. Per risolvere questo problema, i dispositivi possono attivare overlayfs. 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 si chiama scratch, quindi non utilizzare questo nome per altre partizioni.

Per ulteriori informazioni su come abilitare overlayfs, consulta il file README di overlayfs in AOSP.

Aggiornare i dispositivi Android

Se esegui l'upgrade di un dispositivo ad Android 10 e vuoi includere il supporto delle partizioni dinamiche nell'OTA, non devi modificare la tabella delle partizioni integrata. È necessaria una configurazione aggiuntiva.

Modifiche alla configurazione del dispositivo

Per eseguire l'adeguamento della partizionamento dinamico, aggiungi i seguenti flag in device.mk:

PRODUCT_USE_DYNAMIC_PARTITIONS := true
PRODUCT_RETROFIT_DYNAMIC_PARTITIONS := true

Modifiche alla configurazione della lavagna

Devi impostare le seguenti variabili della scheda:

• Imposta BOARD_SUPER_PARTITION_BLOCK_DEVICES sull'elenco dei dispositivi di blocco 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 sulle dimensioni di ogni dispositivo a blocchi in BOARD_SUPER_PARTITION_BLOCK_DEVICES, rispettivamente. Questo è l'elenco delle dimensioni delle partizioni fisiche esistenti sul dispositivo. In genere, questa opzione BOARD_partitionIMAGE_PARTITION_SIZE nelle configurazioni delle schede esistenti.
• Annulla l'impostazione di BOARD_partitionIMAGE_PARTITION_SIZE esistente per tutte le partizioni in BOARD_SUPER_PARTITION_BLOCK_DEVICES.
• Imposta BOARD_SUPER_PARTITION_SIZE sulla somma di 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 dei seguenti: BOARD_SUPER_PARTITION_BLOCK_DEVICES. In genere, questo valore è impostato su system.
• Imposta BOARD_SUPER_PARTITION_GROUPS, BOARD_group_SIZE e BOARD_group_PARTITION_LIST, rispettivamente. Per maggiori dettagli, vedi Modifiche alla configurazione della scheda sui nuovi dispositivi.

Ad esempio, se il dispositivo ha già partizioni di sistema e fornitore e vuoi 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

Modifiche a SELinux

I dispositivi di blocco della super partizione devono essere contrassegnati con l'attributo super_block_device_type. Ad esempio, se il dispositivo ha già le partizioni system e vendor, vuoi utilizzarle come dispositivi a blocchi per archiviare le estensioni delle partizioni dinamiche e i relativi link 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

Poi, aggiungi la seguente riga a device.te:

typeattribute system_block_device super_block_device_type;

Per altre configurazioni, vedi Implementazione di partizioni dinamiche su nuovi dispositivi.

Per saperne di più sugli aggiornamenti di retrofit, vedi OTA per dispositivi A/B senza partizioni dinamiche.

Immagini del produttore

Per un dispositivo che viene lanciato con il supporto delle partizioni dinamiche, evita di utilizzare fastboot userspace per eseguire il flashing delle immagini di fabbrica, poiché l'avvio di userspace è 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 i contenuti delle partizioni logiche, il che significa che contiene system.img, vendor.img e così via, oltre ai metadati della partizione super. Questa immagine può essere caricata direttamente nella partizione super senza strumenti aggiuntivi o l'utilizzo di fastbootd. Dopo la build, super.img viene inserito in ${ANDROID_PRODUCT_OUT}.

Per i dispositivi A/B che vengono avviati con partizioni dinamiche, super.img contiene immagini nello slot A. Dopo aver flashato l'immagine super direttamente, contrassegna lo slot A come avviabile prima di riavviare il dispositivo.

Per i dispositivi di retrofit, make dist crea un insieme di immagini super_*.img che possono essere caricate direttamente nelle 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 mapper di dispositivi

Il partizionamento dinamico ospita una serie di oggetti device-mapper non deterministici. Potrebbero non essere tutti istanziati come previsto, quindi devi monitorare 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à Android. Il tempo necessario per questa operazione non è garantito entro un periodo specifico, quindi devi fornire un tempo sufficiente perché tutti i trigger on property reagiscano. 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à Android nell'ambito delle regole e di ottimizzare i dispositivi di archiviazione in base alle esigenze della piattaforma 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, epoll loop diventa attivo e i valori iniziano ad aggiornarsi. Tuttavia, poiché i trigger della proprietà non sono attivi fino alla fine di init, non possono essere utilizzati nelle fasi di avvio iniziali per gestire root, system o vendor. Puoi prevedere che il valore predefinito del kernel read_ahead_kb sia sufficiente fino a quando gli script init.rc non possono eseguire l'override in early-fs (quando vengono avviati vari daemon e strutture). Pertanto, Google consiglia di utilizzare la funzionalità on property, insieme a una proprietà controllata da init.rc come sys.read_ahead_kb, per gestire la tempistica delle operazioni e prevenire le race condition, 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}