Implementazione di partizioni dinamiche

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

Quando si applica un'agenzia di viaggi online, le partizioni dinamiche vengono create automaticamente, ridimensionati o eliminati in base alle esigenze. Per i dispositivi A/B, esistono due copie i metadati e le modifiche vengono applicate solo al testo che rappresenta nell'area annuncio target.

Poiché le partizioni dinamiche sono implementate nello spazio utente, sono necessarie dal bootloader non può essere reso dinamico. Ad esempio, boot, dtbo e vbmeta vengono letti dal bootloader e quindi devono rimanere come partizioni fisiche.

Ogni partizione dinamica può appartenere a un gruppo di aggiornamento. Questi 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.

Implementazione di partizioni dinamiche su nuovi dispositivi

Questa sezione descrive come implementare le partizioni dinamiche sui nuovi dispositivi verrà lanciato con Android 10 e versioni successive. Per aggiornare sui dispositivi esistenti, consulta l'articolo Upgrade di Android dispositivi mobili.

Modifiche alle partizioni

Per i dispositivi che vengono lanciati con Android 10, crea una partizione chiamata super. super che gestisce gli slot A/B internamente, quindi i dispositivi A/B non devono separa le partizioni super_a e super_b. Tutte le partizioni AOSP di sola lettura non utilizzate dal bootloader devono essere dinamico e deve essere rimosso dalla tabella di partizione GUID (GPT). Le partizioni specifiche del fornitore non devono essere dinamiche e possono essere posizionate nel GPT.

Per stimare le dimensioni di super, aggiungi le dimensioni del partizioni eliminate dal GPT. Per i dispositivi A/B, deve includere le dimensioni di entrambe le aree. La Figura 1 mostra una tabella di partizione di esempio prima e dopo la conversione in una partizioni di Compute Engine.

Layout tabella di partizione
. Figura 1. Nuovo layout della tabella di partizione fisica quando conversione in partizioni dinamiche
di Gemini Advanced.
.

Le partizioni dinamiche supportate sono:

  • Sistema
  • Fornitore
  • Prodotto
  • Estensione di sistema
  • ODM

Per i dispositivi che vengono lanciati con Android 10, la opzione della riga di comando del kernel androidboot.super_partition deve essere vuoto, in modo che il comando sysprop Il campo ro.boot.super_partition è vuoto.

Allineamento della partizione

Il modulo device-mapper potrebbe funzionare in modo meno efficiente se La partizione super non è allineata correttamente. La La partizione super DEVE essere allineata al minimo I/O delle dimensioni della richiesta in base a quanto determinato dal livello del blocco. Per impostazione predefinita, (tramite lpmake, che genera super), presuppone che un allineamento sia di 1 MiB sia sufficiente per ogni partizione dinamica. Tuttavia, i fornitori devono assicurati che la partizione super sia allineata correttamente.

Per determinare le dimensioni minime della richiesta di un dispositivo a blocchi, ispezione di 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 una 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 lavagna

Devi impostare le dimensioni della partizione super: 

BOARD_SUPER_PARTITION_SIZE := <size-in-bytes>

Sui dispositivi A/B, il sistema di compilazione restituisce un errore se la dimensione totale delle immagini di partizione dinamica è più della metà di super dimensioni della partizione.

Puoi configurare l'elenco delle partizioni dinamiche come segue. Per che utilizzano i gruppi di aggiornamento, elenca i gruppi Variabile BOARD_SUPER_PARTITION_GROUPS. Il nome di ogni gruppo ha un valore BOARD_group_SIZE e BOARD_group_PARTITION_LIST. Per i dispositivi A/B, le dimensioni massime di un gruppo devono coprire solo un gruppo slot, poiché i nomi dei gruppi sono subissati internamente.

Ecco un esempio di dispositivo in cui tutte le partizioni vengono inserite 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 in cui i servizi di sistema e di prodotto 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
di Gemini Advanced.
  • 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 - 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 dei valori massimi le dimensioni di tutti i gruppi devono 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.
  • Nel calcolo è richiesto l'overhead per tenere conto dei metadati. allineamenti e così via. Un overhead ragionevole è pari a 4 MiB, ma può sceglierne una maggiore in base alle necessità del dispositivo.

Dimensione partizioni dinamiche

Prima delle partizioni dinamiche, le dimensioni delle partizioni venivano allocate in eccesso a per assicurarsi di avere spazio sufficiente per gli aggiornamenti futuri. Le dimensioni effettive è stata utilizzata così com'è e la maggior parte delle partizioni di sola lettura aveva una certa quantità spazio nel proprio file system. Nelle partizioni dinamiche, lo spazio libero è è inutilizzabile e potrebbe essere usato per far crescere le partizioni durante una OTA. È fondamentale assicurarsi che le partizioni non sprechino spazio e assegnati a una dimensione minima possibile.

Per le immagini ext4 di sola lettura, il sistema di compilazione alloca automaticamente la dimensione minima se non viene specificata una dimensione della partizione hardcoded. La il sistema di compilazione si adatta all'immagine in modo che il file system abbia di spazio inutilizzato. In questo modo eviterai sprechi del dispositivo spazio utilizzabile per le agenzie di viaggi online.

Inoltre, le immagini ext4 possono essere ulteriormente compresse abilitando a livello di deduplicazione. Per attivarlo, utilizza la seguente configurazione: 

BOARD_EXT4_SHARE_DUP_BLOCKS := true

Se l'allocazione automatica della dimensione minima di una partizione non è desiderata, puoi controllare la dimensione della partizione in due modi. Puoi specificare un quantità minima di spazio libero con BOARD_partitionIMAGE_PARTITION_RESERVED_SIZE, oppure specificare BOARD_partitionIMAGE_PARTITION_SIZE per forzare partizioni dinamiche a una dimensione specifica. Nessuna di queste opzioni è se non necessario.

Ad esempio: 

BOARD_PRODUCTIMAGE_PARTITION_RESERVED_SIZE := 52428800

Questa operazione obbliga il file system in product.img ad avere 50 MiB di spazio inutilizzato.

Modifiche system as-root

I dispositivi che vengono lanciati con Android 10 non devono utilizza system-as-root.

Dispositivi con partizioni dinamiche (a partire dal lancio o da retrofit) partizioni dinamiche) non devono utilizzare system-as-root. Il kernel Linux non può interpreta la partizione super e quindi non può montare system. system è ora montato da init di prima fase, che risiede nel ramdisk.

Non impostare BOARD_BUILD_SYSTEM_ROOT_IMAGE. Nella Android 10, Il flag BOARD_BUILD_SYSTEM_ROOT_IMAGE è utilizzato solo per differenziare se il sistema è montato dal kernel o init di prima fase in ramdisk.

Impostazione di BOARD_BUILD_SYSTEM_ROOT_IMAGE su true causa un errore di generazione Anche PRODUCT_USE_DYNAMIC_PARTITIONS è true.

Quando BOARD_USES_RECOVERY_AS_BOOT è impostato su true, il parametro l'immagine di ripristino viene creata come boot.img, contenente ramdisk. In precedenza, il bootloader utilizzava il kernel skip_initramfs parametro della riga di comando per decidere in quale modalità avviare. Per Sui dispositivi Android 10, il bootloader NON DEVE passare skip_initramfs alla riga di comando del kernel. Il bootloader devi superare androidboot.force_normal_boot=1 per saltare il recupero e avviano il normale Android. Dispositivi con Android 12 lanciati o versioni successive devono utilizzare bootconfig per passare androidboot.force_normal_boot=1.

Modifiche alla configurazione AVB

Con Android Avvio verificato 2.0, se il dispositivo non utilizza partizione concatenata descrittori, non è necessaria alcuna modifica. Se utilizzi e una delle partizioni verificate è dinamica, allora le modifiche sono necessarie.

Ecco un esempio di configurazione per un dispositivo che concatena vbmeta per system e vendor partizioni. 

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 una funzione vbmeta piè di pagina alla fine di system e vendor partizioni. Poiché queste partizioni non sono più visibili al bootloader (che risiedono in super), due sono necessarie modifiche.

  • Aggiungi 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 aggiungendo una o più di queste partizioni, devono avere le stesse dimensioni come la partizione vbmeta.
  • Rinomina i flag di configurazione aggiungendo VBMETA_ e specificare le partizioni a cui 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. Modifiche sono necessarie solo in caso di concatenamento a una partizione logica.

Modifiche al bootloader AVB

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

Se utilizzi partizioni concatenate, includi una patch aggiuntiva:

  • 49936b4c0109411fdd38bd4ba3a32a01c40439a9 — "libavb: Supporta i BLOB vbmeta all'inizio della partizione."

Modifiche alla riga di comando kernel

È necessario aggiungere un nuovo parametro, androidboot.boot_devices alla riga di comando del kernel. Questa funzionalità viene utilizzata da init per abilita i collegamenti simbolici /dev/block/by-name. Dovrebbe essere device path al link simbolico sottostante creato ueventd, ovvero /dev/block/platform/device-path/by-name/partition-name. I dispositivi che vengono lanciati con Android 12 o versioni successive devono utilizzare bootconfig per passare androidboot.boot_devices a init.

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

BOARD_KERNEL_CMDLINE += androidboot.boot_devices=soc/100000.ufshc
Puoi aggiungere il parametro bootconfig nel file BoardConfig.mk come segue: 
BOARD_BOOTCONFIG += androidboot.boot_devices=soc/100000.ufshc

modifiche FStab

La struttura dei dispositivi e gli overlay della struttura ad albero dei dispositivi non devono contenere fstab le voci corrispondenti. Utilizza un file fstab che farà parte del ramdisk.

È necessario apportare modifiche al file fstab per le partizioni logiche:

  • Il campo flags fs_mgr deve includere il flag logical e il flag first_stage_mount, introdotto Android 10, che indica che una partizione è montare nella prima fase.
  • Una partizione può specificare avb=vbmeta partition name come fs_mgr e il valore vbmeta specificato viene inizializzata dalla prima fase init prima tentare di montare i dispositivi.
  • Il campo dev deve essere il nome della partizione.

Le seguenti voci fstab impostano sistema, fornitore e prodotto come logici che seguono le regole riportate 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.

Modifiche a SELinux

Il dispositivo di blocco della super partizione deve essere contrassegnato con l'etichetta super_block_device. Ad esempio, se il link simbolico della superpartizione 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 nello spazio utente) non capisce partizioni dinamiche, quindi non può eseguirne il flashing. Per risolvere questo problema, i dispositivi deve utilizzare un'implementazione dello spazio utente del protocollo fastboot, chiamata fastbootd.

Per ulteriori informazioni su come implementare fastbootd, vedi Spostamento di Fastboot nello spazio utente.

rimonta ADB

Per gli sviluppatori che utilizzano build di eng o userdebug, adb remount è estremamente utile per un'iterazione rapida. Le partizioni dinamiche rappresentano per adb remount perché non c'è più spazio all'interno di ogni file system. Per risolvere questo problema, i dispositivi possono attivare overlay. Se nella super partizione ci è spazio libero, adb remount crea automaticamente una creatività dinamica temporanea e utilizza overlayfs per le scritture. La partizione temporanea è denominato scratch, quindi non utilizzare questo nome per partizioni di Compute Engine.

Per ulteriori informazioni su come attivare overlayfs, consulta la sezione overlayfs README in AOSP.

Eseguire l'upgrade dei dispositivi Android

Se esegui l'upgrade di un dispositivo ad Android 10 Se vuoi includere nell'OTA il supporto delle partizioni dinamiche, non è necessario e modificare la tabella di partizione integrata. Altre configurazioni sono obbligatorio.

Modifiche alla configurazione del dispositivo

Per riadattare il 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 board:

  • Imposta BOARD_SUPER_PARTITION_BLOCK_DEVICES sull'elenco dei dispositivi di blocco utilizzati in un archivio di estensioni di partizioni dinamiche. Questo è l'elenco dei nomi degli oggetti fisici partizioni di memoria sul dispositivo.
  • Imposta BOARD_SUPER_PARTITION_partition_DEVICE_SIZE sulle dimensioni di ogni dispositivo di blocco rispettivamente in BOARD_SUPER_PARTITION_BLOCK_DEVICES. Questo è l'elenco delle dimensioni delle partizioni fisiche esistenti sul dispositivo. Di solito BOARD_partitionIMAGE_PARTITION_SIZE nella bacheca esistente configurazioni.
  • Annulla l'impostazione di BOARD_partitionIMAGE_PARTITION_SIZE esistente per tutti 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 di blocco in cui dei metadati della partizione dinamica. Deve essere uno di BOARD_SUPER_PARTITION_BLOCK_DEVICES. Di solito, questo valore è impostato su system.
  • Imposta BOARD_SUPER_PARTITION_GROUPS, BOARD_group_SIZE e rispettivamente BOARD_group_PARTITION_LIST. Consulta Modifiche alla configurazione della scheda su nuovi dispositivi per maggiori dettagli.

Ad esempio, se il dispositivo ha già partizioni di sistema e del fornitore e vuoi convertire alle partizioni dinamiche e aggiungi una nuova partizione del prodotto durante l'aggiornamento, imposta questa configurazione della lavagna: 

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à partizioni system e vendor, vuoi utilizzarle come blocco dispositivi per archiviare estensioni di partizioni dinamiche e i loro 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

Poi aggiungi la seguente riga a device.te: 

typeattribute system_block_device super_block_device_type;

Per altre configurazioni, consulta la sezione Implementazione partizioni dinamiche su nuovi dispositivi.

Per ulteriori informazioni sugli aggiornamenti di retrofit, consulta OTA per dispositivi A/B senza annunci dinamici Partizioni.

Immagini di fabbrica

Per un dispositivo che viene avviato con il supporto delle partizioni dinamiche, evita di utilizzare fastboot per le immagini di fabbrica flash, poiché l'avvio per lo spazio utente è più lento rispetto ad altri metodi di lampeggiamento.

Per risolvere questo problema, make dist ora crea un'ulteriore super.img immagine che può essere mostrata in flash direttamente nella barra di stato della partizione di testo. Raggruppa automaticamente i contenuti partizioni di memoria, il che significa che contiene system.img, vendor.img e così via, oltre a super dei metadati della partizione. Questa immagine può essere indirizzata direttamente partizione super senza strumenti aggiuntivi o con l'utilizzo fastbootd. Dopo la build, super.img viene inserito ${ANDROID_PRODUCT_OUT}.

Per i dispositivi A/B che si avviano con partizioni dinamiche, super.img contiene immagini nell'area A. Dopo il flashing del super immagine direttamente, contrassegna lo slot A come avviabile prima di riavviare dispositivo.

Per i dispositivi di retrofit, make dist crea un insieme di super_*.img immagini che possono essere lampeggiate direttamente alle partizioni fisiche corrispondenti. Ad esempio, make dist build super_system.img e super_vendor.img quando BOARD_SUPER_PARTITION_BLOCK_DEVICES è il sistema di terze parti. Queste immagini vengono inserite nella cartella OTA target_files.zip.

Ottimizzazione dispositivo di archiviazione per mappatore dispositivi

Il partizionamento dinamico supporta una serie di parametri non deterministici di oggetti strutturati. Potrebbero non essere tutte create come previsto, quindi devi monitorare tutti monta i componenti e aggiorna le proprietà Android di tutte le partizioni associate dei dispositivi di archiviazione sottostanti.

Un meccanismo all'interno di init monitora i montaggi e in modo asincrono aggiorna le proprietà di Android. Il tempo richiesto non è garantito sia entro un determinato periodo, quindi devi fornire tempo sufficiente per tutti gli attivatori di on property di reazione. Le proprietà sono dev.mnt.blk.<partition> dove <partition> è root, system, data o vendor, ad esempio. Ogni proprietà è associata al base dello spazio di archiviazione, 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]

La lingua init.rc consente alle proprietà Android di essere ampliato in base alle regole e i dispositivi di archiviazione possono essere ottimizzati in base alla 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

Quando l'elaborazione dei comandi viene avviata nella seconda fase init, epoll loop diventa attivo e i valori iniziano ad aggiornarsi. Tuttavia, poiché gli attivatori delle proprietà non sono attivi fino alla fine del init, non può essere utilizzata nelle fasi di avvio iniziali per gestire root, system o vendor. Potrebbero essere previsti il valore predefinito del kernel read_ahead_kb sia sufficiente fino È possibile eseguire l'override di init.rc script in early-fs (quando vengono avviati vari daemon e strutture). Pertanto, Google consiglia utilizzi la funzionalità on property, insieme a proprietà controllata da init.rc come sys.read_ahead_kb, gestire le tempistiche delle operazioni e prevenire le racecondition, come in queste 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}