Menerapkan partisi dinamis

Partisi dinamis diimplementasikan menggunakan modul pemeta perangkat dm-linear di kernel Linux. Partisi super berisi metadata yang mencantumkan nama dan rentang blok setiap partisi dinamis dalam super. Selama init tahap pertama, metadata ini diuraikan dan divalidasi, serta perangkat blok virtual dibuat untuk merepresentasikan setiap partisi dinamis.

Saat menerapkan OTA, partisi dinamis akan dibuat, diubah ukurannya, atau dihapus secara otomatis sesuai kebutuhan. Untuk perangkat A/B, ada dua salinan metadata, dan perubahan hanya diterapkan ke salinan yang merepresentasikan slot target.

Karena partisi dinamis diterapkan di ruang pengguna, partisi yang diperlukan oleh bootloader tidak dapat dibuat dinamis. Misalnya, boot, dtbo, dan vbmeta dibaca oleh bootloader, dan oleh karena itu harus tetap sebagai partisi fisik.

Setiap partisi dinamis dapat menjadi bagian dari grup update. Grup ini membatasi ruang maksimum yang dapat digunakan partisi dalam grup tersebut. Misalnya, system dan vendor dapat menjadi bagian dari grup yang membatasi ukuran total system dan vendor.

Menerapkan partisi dinamis di perangkat baru

Bagian ini menjelaskan cara menerapkan partisi dinamis di perangkat baru yang diluncurkan dengan Android 10 dan yang lebih tinggi. Untuk mengupdate perangkat yang ada, lihat Mengupgrade perangkat Android.

Perubahan partisi

Untuk perangkat yang diluncurkan dengan Android 10, buat partisi yang disebut super. Partisi super menangani slot A/B secara internal, sehingga perangkat A/B tidak memerlukan partisi super_a dan super_b terpisah. Semua partisi AOSP hanya baca yang tidak digunakan oleh bootloader harus bersifat dinamis dan harus dihapus dari Tabel Partisi GUID (GPT). Partisi khusus vendor tidak harus dinamis dan dapat ditempatkan di GPT.

Untuk memperkirakan ukuran super, tambahkan ukuran partisi yang dihapus dari GPT. Untuk perangkat A/B, hal ini harus mencakup ukuran kedua slot. Gambar 1 menunjukkan contoh tabel partisi sebelum dan setelah dikonversi ke partisi dinamis.

Tata letak tabel partisi
Gambar 1. Tata letak tabel partisi fisik baru saat mengonversi ke partisi dinamis

Partisi dinamis yang didukung adalah:

  • Sistem
  • Vendor
  • Produk
  • Ext Sistem
  • ODM

Untuk perangkat yang diluncurkan dengan Android 10, opsi command line kernel androidboot.super_partition harus kosong sehingga sysprop perintah ro.boot.super_partition kosong.

Perataan partisi

Modul device-mapper mungkin beroperasi kurang efisien jika partisi super tidak selaras dengan benar. Partisi super HARUS diselaraskan dengan ukuran permintaan I/O minimum sebagaimana ditentukan oleh lapisan blok. Secara default, sistem build (melalui lpmake, yang menghasilkan image partisi super), mengasumsikan bahwa perataan 1 MiB sudah cukup untuk setiap partisi dinamis. Namun, vendor harus memastikan partisi super disejajarkan dengan benar.

Anda dapat menentukan ukuran permintaan minimum perangkat blok dengan memeriksa sysfs. Contoh: 

# 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

Anda dapat memverifikasi penyelarasan partisi super dengan cara yang sama: 

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

Offset penyelarasan HARUS 0.

Perubahan konfigurasi perangkat

Untuk mengaktifkan partisi dinamis, tambahkan tanda berikut di device.mk: 

PRODUCT_USE_DYNAMIC_PARTITIONS := true

Perubahan konfigurasi papan

Anda harus menetapkan ukuran partisi super: 

BOARD_SUPER_PARTITION_SIZE := <size-in-bytes>

Pada perangkat A/B, sistem build akan menampilkan error jika total ukuran image partisi dinamis lebih dari setengah ukuran partisi super.

Anda dapat mengonfigurasi daftar partisi dinamis sebagai berikut. Untuk perangkat yang menggunakan grup update, cantumkan grup dalam variabel BOARD_SUPER_PARTITION_GROUPS. Setiap nama grup kemudian memiliki variabel BOARD_group_SIZE dan BOARD_group_PARTITION_LIST. Untuk perangkat A/B, ukuran maksimum grup hanya boleh mencakup satu slot, karena nama grup diberi akhiran slot secara internal.

Berikut adalah contoh perangkat yang menempatkan semua partisi ke dalam grup bernama 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

Berikut adalah contoh perangkat yang menempatkan layanan sistem dan produk ke dalam group_foo, dan vendor, product, serta odm ke dalam 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
  • Untuk perangkat peluncuran A/B Virtual, jumlah ukuran maksimum semua grup harus paling banyak:
    BOARD_SUPER_PARTITION_SIZE - overhead
    Lihat Menerapkan A/B Virtual.
  • Untuk perangkat peluncuran A/B, jumlah ukuran maksimum semua grup harus:
    BOARD_SUPER_PARTITION_SIZE / 2 - overhead
  • Untuk perangkat non-A/B dan perangkat A/B retrofit, jumlah ukuran maksimum semua grup harus:
    BOARD_SUPER_PARTITION_SIZE - overhead
  • Pada waktu build, jumlah ukuran gambar setiap partisi dalam grup update tidak boleh melebihi ukuran maksimum grup.
  • Overhead diperlukan dalam penghitungan untuk memperhitungkan metadata, perataan, dan sebagainya. Overhead yang wajar adalah 4 MiB, tetapi Anda dapat memilih overhead yang lebih besar sesuai kebutuhan perangkat.

Mengubah ukuran partisi dinamis

Sebelum partisi dinamis, ukuran partisi dialokasikan secara berlebihan untuk memastikan bahwa partisi memiliki ruang yang cukup untuk update mendatang. Ukuran sebenarnya diambil apa adanya dan sebagian besar partisi hanya baca memiliki sejumlah ruang kosong dalam sistem filenya. Di partisi dinamis, ruang kosong tersebut tidak dapat digunakan dan dapat digunakan untuk memperluas partisi selama OTA. Sangat penting untuk memastikan bahwa partisi tidak membuang-buang ruang dan dialokasikan ke ukuran minimum yang mungkin.

Untuk image ext4 hanya baca, sistem build akan otomatis mengalokasikan ukuran minimum jika tidak ada ukuran partisi hardcode yang ditentukan. Sistem build menyesuaikan gambar sehingga sistem file memiliki ruang yang tidak terpakai sekecil mungkin. Hal ini memastikan bahwa perangkat tidak membuang-buang ruang yang dapat digunakan untuk OTA.

Selain itu, gambar ext4 dapat dikompresi lebih lanjut dengan mengaktifkan penghapusan duplikat tingkat blok. Untuk mengaktifkannya, gunakan konfigurasi berikut: 

BOARD_EXT4_SHARE_DUP_BLOCKS := true

Jika alokasi otomatis ukuran minimum partisi tidak diinginkan, ada dua cara untuk mengontrol ukuran partisi. Anda dapat menentukan jumlah minimum ruang kosong dengan BOARD_partitionIMAGE_PARTITION_RESERVED_SIZE, atau Anda dapat menentukan BOARD_partitionIMAGE_PARTITION_SIZE untuk memaksa partisi dinamis ke ukuran tertentu. Tidak satu pun dari opsi ini direkomendasikan kecuali jika diperlukan.

Contoh: 

BOARD_PRODUCTIMAGE_PARTITION_RESERVED_SIZE := 52428800

Tindakan ini memaksa sistem file di product.img untuk memiliki ruang yang tidak terpakai sebesar 50 MiB.

Perubahan system-as-root

Perangkat yang diluncurkan dengan Android 10 tidak boleh menggunakan system-as-root.

Perangkat dengan partisi dinamis (baik diluncurkan dengan atau menyesuaikan partisi dinamis) tidak boleh menggunakan system-as-root. Kernel Linux tidak dapat menafsirkan partisi super sehingga tidak dapat memasang system itu sendiri. system kini di-mount oleh init tahap pertama, yang berada di ramdisk.

Jangan setel BOARD_BUILD_SYSTEM_ROOT_IMAGE. Di Android 10, tanda BOARD_BUILD_SYSTEM_ROOT_IMAGE hanya digunakan untuk membedakan apakah sistem dipasang oleh kernel atau oleh init tahap pertama di ramdisk.

Menetapkan BOARD_BUILD_SYSTEM_ROOT_IMAGE ke true akan menyebabkan error build saat PRODUCT_USE_DYNAMIC_PARTITIONS juga true.

Jika BOARD_USES_RECOVERY_AS_BOOT disetel ke benar (true), image pemulihan dibangun sebagai boot.img, yang berisi ramdisk pemulihan. Sebelumnya, bootloader menggunakan parameter command line kernel skip_initramfs untuk memutuskan mode yang akan digunakan saat booting. Untuk perangkat Android 10, bootloader TIDAK BOLEH meneruskan skip_initramfs ke command line kernel. Sebagai gantinya, bootloader harus meneruskan androidboot.force_normal_boot=1 untuk melewati pemulihan dan mem-boot Android normal. Perangkat yang diluncurkan dengan Android 12 atau yang lebih baru harus menggunakan bootconfig untuk meneruskan androidboot.force_normal_boot=1.

Perubahan konfigurasi AVB

Saat menggunakan Android Verified Boot 2.0, jika perangkat tidak menggunakan deskriptor partisi berantai, tidak ada perubahan yang diperlukan. Namun, jika menggunakan partisi berantai dan salah satu partisi terverifikasi bersifat dinamis, maka perubahan diperlukan.

Berikut contoh konfigurasi untuk perangkat yang merangkai vbmeta untuk partisi system dan 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

Dengan konfigurasi ini, bootloader akan mencari footer vbmeta di akhir partisi system dan vendor. Karena partisi ini tidak lagi terlihat oleh bootloader (berada di super), dua perubahan diperlukan.

  • Tambahkan partisi vbmeta_system dan vbmeta_vendor ke tabel partisi perangkat. Untuk perangkat A/B, tambahkan vbmeta_system_a, vbmeta_system_b, vbmeta_vendor_a, dan vbmeta_vendor_b. Jika menambahkan satu atau beberapa partisi ini, ukurannya harus sama dengan partisi vbmeta.
  • Ganti nama tanda konfigurasi dengan menambahkan VBMETA_ dan tentukan partisi yang diperluas oleh penggabungan: 
    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

Perangkat dapat menggunakan satu, kedua, atau tidak satu pun dari partisi ini. Perubahan hanya diperlukan saat melakukan chaining ke partisi logis.

Perubahan bootloader AVB

Jika bootloader telah menyematkan libavb, sertakan patch berikut:

Jika menggunakan partisi berantai, sertakan patch tambahan:

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

Perubahan command line kernel

Parameter baru, androidboot.boot_devices, harus ditambahkan ke command line kernel. Ini digunakan oleh init untuk mengaktifkan link simbolis /dev/block/by-name. Komponen ini harus berupa komponen jalur perangkat ke symlink by-name yang dibuat oleh ueventd, yaitu, /dev/block/platform/device-path/by-name/partition-name. Perangkat yang diluncurkan dengan Android 12 atau yang lebih baru harus menggunakan bootconfig untuk meneruskan androidboot.boot_devices ke init.

Misalnya, jika link simbolis super partisi menurut nama adalah /dev/block/platform/soc/100000.ufshc/by-name/super, Anda dapat menambahkan parameter command line dalam file BoardConfig.mk sebagai berikut: 

BOARD_KERNEL_CMDLINE += androidboot.boot_devices=soc/100000.ufshc
 Anda dapat menambahkan parameter bootconfig dalam file BoardConfig.mk sebagai berikut: 
BOARD_BOOTCONFIG += androidboot.boot_devices=soc/100000.ufshc

perubahan fstab

Pohon perangkat dan overlay pohon perangkat tidak boleh berisi entri fstab. Gunakan file fstab yang akan menjadi bagian dari ramdisk.

Perubahan harus dilakukan pada file fstab untuk partisi logis:

  • Kolom tanda fs_mgr harus menyertakan tanda logical dan tanda first_stage_mount, yang diperkenalkan di Android 10, yang menunjukkan bahwa partisi akan dipasang di tahap pertama.
  • Partisi dapat menentukan avb=vbmeta partition name sebagai flag fs_mgr, lalu partisi vbmeta yang ditentukan diinisialisasi oleh init tahap pertama sebelum mencoba memasang perangkat apa pun.
  • Kolom dev harus berupa nama partisi.

Entri fstab berikut menetapkan sistem, vendor, dan produk sebagai partisi logis yang mengikuti aturan di atas. 

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

Salin file fstab ke ramdisk tahap pertama.

Perubahan SELinux

Perangkat blok partisi super harus ditandai dengan label super_block_device. Misalnya, jika symlink menurut nama partisi super adalah /dev/block/platform/soc/100000.ufshc/by-name/super, tambahkan baris berikut ke file_contexts: 

/dev/block/platform/soc/10000\.ufshc/by-name/super   u:object_r:super_block_device:s0

fastbootd

Bootloader (atau alat flashing non-ruang pengguna) tidak memahami partisi dinamis, sehingga tidak dapat mem-flash-nya. Untuk mengatasi hal ini, perangkat harus menggunakan implementasi ruang pengguna dari protokol fastboot, yang disebut fastbootd.

Untuk mengetahui informasi selengkapnya tentang cara menerapkan fastbootd, lihat Memindahkan Fastboot ke Ruang Pengguna.

adb remount

Untuk developer yang menggunakan build eng atau userdebug, adb remount sangat berguna untuk iterasi cepat. Partisi dinamis menimbulkan masalah bagi adb remount karena tidak ada lagi ruang kosong dalam setiap sistem file. Untuk mengatasi hal ini, perangkat dapat mengaktifkan overlayfs. Selama ada ruang kosong dalam partisi super, adb remount akan otomatis membuat partisi dinamis sementara dan menggunakan overlayfs untuk penulisan. Partisi sementara diberi nama scratch, jadi jangan gunakan nama ini untuk partisi lain.

Untuk mengetahui informasi selengkapnya tentang cara mengaktifkan overlayfs, lihat README overlayfs di AOSP.

Mengupgrade perangkat Android

Jika Anda mengupgrade perangkat ke Android 10, dan ingin menyertakan dukungan partisi dinamis dalam OTA, Anda tidak perlu mengubah tabel partisi bawaan. Diperlukan beberapa konfigurasi tambahan.

Perubahan konfigurasi perangkat

Untuk menyesuaikan partisi dinamis, tambahkan tanda berikut di device.mk: 

PRODUCT_USE_DYNAMIC_PARTITIONS := true
PRODUCT_RETROFIT_DYNAMIC_PARTITIONS := true

Perubahan konfigurasi papan

Anda harus menetapkan variabel papan berikut:

  • Setel BOARD_SUPER_PARTITION_BLOCK_DEVICES ke daftar perangkat blok yang digunakan untuk menyimpan rentang partisi dinamis. Ini adalah daftar nama partisi fisik yang ada di perangkat.
  • Tetapkan BOARD_SUPER_PARTITION_partition_DEVICE_SIZE ke ukuran setiap perangkat blok di BOARD_SUPER_PARTITION_BLOCK_DEVICES. Ini adalah daftar ukuran partisi fisik yang ada di perangkat. Ini biasanya BOARD_partitionIMAGE_PARTITION_SIZE dalam konfigurasi papan yang ada.
  • Batalkan setelan BOARD_partitionIMAGE_PARTITION_SIZE yang ada untuk semua partisi di BOARD_SUPER_PARTITION_BLOCK_DEVICES.
  • Tetapkan BOARD_SUPER_PARTITION_SIZE ke jumlah BOARD_SUPER_PARTITION_partition_DEVICE_SIZE.
  • Setel BOARD_SUPER_PARTITION_METADATA_DEVICE ke perangkat blok tempat metadata partisi dinamis disimpan. Nilainya harus salah satu dari BOARD_SUPER_PARTITION_BLOCK_DEVICES. Biasanya, nilai ini ditetapkan ke system.
  • Tetapkan BOARD_SUPER_PARTITION_GROUPS, BOARD_group_SIZE, dan BOARD_group_PARTITION_LIST. Lihat Perubahan konfigurasi papan di perangkat baru untuk mengetahui detailnya.

Misalnya, jika perangkat sudah memiliki partisi sistem dan vendor, dan Anda ingin mengonversinya ke partisi dinamis dan menambahkan partisi produk baru selama update, tetapkan konfigurasi papan ini: 

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

Perubahan SELinux

Perangkat blok partisi super harus ditandai dengan atribut super_block_device_type. Misalnya, jika perangkat sudah memiliki partisi system dan vendor, Anda ingin menggunakannya sebagai perangkat blok untuk menyimpan rentang partisi dinamis, dan link simbolis menurut namanya ditandai sebagai 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

Kemudian, tambahkan baris berikut ke device.te: 

typeattribute system_block_device super_block_device_type;

Untuk konfigurasi lainnya, lihat Menerapkan partisi dinamis di perangkat baru.

Untuk mengetahui informasi selengkapnya tentang update retrofit, lihat OTA untuk Perangkat A/B tanpa Partisi Dinamis.

Setelan pabrik

Untuk perangkat yang diluncurkan dengan dukungan partisi dinamis, hindari penggunaan fastboot ruang pengguna untuk mem-flash image pabrik, karena booting ke ruang pengguna lebih lambat daripada metode flashing lainnya.

Untuk mengatasi hal ini, make dist kini membuat gambar super.img tambahan yang dapat di-flash langsung ke partisi super. Secara otomatis, fungsi ini menggabungkan konten partisi logis, yang berarti fungsi ini berisi system.img, vendor.img, dan sebagainya, selain metadata partisi super. Image ini dapat di-flash langsung ke partisi super tanpa alat tambahan atau menggunakan fastbootd. Setelah build, super.img ditempatkan di ${ANDROID_PRODUCT_OUT}.

Untuk perangkat A/B yang diluncurkan dengan partisi dinamis, super.img berisi image di slot A. Setelah mem-flash gambar super secara langsung, tandai slot A sebagai dapat di-boot sebelum memulai ulang perangkat.

Untuk perangkat retrofit, make dist membuat serangkaian image super_*.img yang dapat di-flash langsung ke partisi fisik yang sesuai. Misalnya, make dist mem-build super_system.img dan super_vendor.img jika BOARD_SUPER_PARTITION_BLOCK_DEVICES adalah vendor sistem. Gambar ini ditempatkan di folder OTA di target_files.zip.

Penyesuaian perangkat penyimpanan pemeta perangkat

Partisi dinamis mengakomodasi sejumlah objek device-mapper nondeterministik. Semua partisi ini mungkin tidak di-instantiate seperti yang diharapkan, jadi Anda harus melacak semua pemasangan, dan memperbarui properti Android dari semua partisi terkait dengan perangkat penyimpanan yang mendasarinya.

Mekanisme di dalam init melacak pemasangan dan memperbarui properti Android secara asinkron. Jumlah waktu yang diperlukan tidak dijamin berada dalam jangka waktu tertentu, jadi Anda harus memberikan waktu yang cukup agar semua pemicu on property dapat bereaksi. Properti adalah dev.mnt.blk.<partition> dengan <partition> adalah root, system, data, atau vendor, misalnya. Setiap properti dikaitkan dengan nama perangkat penyimpanan dasar, seperti yang ditunjukkan dalam contoh berikut:

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]

Bahasa init.rc memungkinkan properti Android diperluas sebagai bagian dari aturan, dan perangkat penyimpanan dapat disetel oleh platform sesuai kebutuhan dengan perintah seperti berikut:

write /sys/block/${dev.mnt.blk.root}/queue/read_ahead_kb 128
write /sys/block/${dev.mnt.blk.data}/queue/read_ahead_kb 128

Setelah pemrosesan perintah dimulai di init tahap kedua, epoll loop akan menjadi aktif, dan nilai mulai diperbarui. Namun, karena pemicu properti tidak aktif hingga init akhir, pemicu tersebut tidak dapat digunakan pada tahap booting awal untuk menangani root, system, atau vendor. Anda dapat mengandalkan read_ahead_kb default kernel hingga skrip init.rc dapat menggantikannya di early-fs (saat berbagai daemon dan fasilitas dimulai). Oleh karena itu, Google merekomendasikan agar Anda menggunakan fitur on property, bersama dengan properti yang dikontrol init.rc seperti sys.read_ahead_kb, untuk menangani pengaturan waktu operasi dan mencegah kondisi persaingan, seperti dalam contoh berikut:

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}