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.
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 odmdi 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
evbmeta_vendor
alla tabella di partizione del dispositivo. Per i dispositivi A/B, aggiungivbmeta_system_a
,vbmeta_system_b
,vbmeta_vendor_a
evbmeta_vendor_b
. Se aggiungendo una o più di queste partizioni, devono avere le stesse dimensioni come la partizionevbmeta
. -
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:
- 818cf56740775446285466eda984acedd4baeac0 — "libavb: esegui query sui GUID delle partizioni solo quando il cmdline ha bisogno ".
- 5abd6bc2578968d24406d834471adfd995a0c2e9 — "Consenti alla partizione di sistema di essere assente"
- 9ba3b6613b4e5130fa01a11d984c6b5f0eb3af05 — "Correggi AvbSlotVerifyData->cmdline potrebbe essere NULL"
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.ufshcPuoi 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 flagfirst_stage_mount
, introdotto Android 10, che indica che una partizione è montare nella prima fase. -
Una partizione può specificare
avb=vbmeta partition name
comefs_mgr
e il valorevbmeta
specificato viene inizializzata dalla prima faseinit
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 inBOARD_SUPER_PARTITION_BLOCK_DEVICES
. Questo è l'elenco delle dimensioni delle partizioni fisiche esistenti sul dispositivo. Di solitoBOARD_partitionIMAGE_PARTITION_SIZE
nella bacheca esistente configurazioni. - Annulla l'impostazione di
BOARD_partitionIMAGE_PARTITION_SIZE
esistente per tutti inBOARD_SUPER_PARTITION_BLOCK_DEVICES
. - Imposta
BOARD_SUPER_PARTITION_SIZE
sulla somma diBOARD_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 diBOARD_SUPER_PARTITION_BLOCK_DEVICES
. Di solito, questo valore è impostato susystem
. - Imposta
BOARD_SUPER_PARTITION_GROUPS
,BOARD_group_SIZE
e rispettivamenteBOARD_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}