Partisi dinamis diimplementasikan menggunakan modul dm-linear device-mapper di kernel Linux. Partisi super
berisi metadata yang mencantumkan nama dan rentang blok dari setiap partisi dinamis dalam super
. Selama init
tahap pertama, metadata ini diuraikan dan divalidasi, dan perangkat blok virtual dibuat untuk mewakili setiap partisi dinamis.
Saat menerapkan OTA, partisi dinamis secara otomatis dibuat, diubah ukurannya, atau dihapus sesuai kebutuhan. Untuk perangkat A/B, ada dua salinan metadata, dan perubahan hanya diterapkan pada salinan yang mewakili slot target.
Karena partisi dinamis diimplementasikan di ruang pengguna, partisi yang dibutuhkan oleh bootloader tidak dapat dibuat dinamis. Misalnya, boot
, dtbo
, dan vbmeta
dibaca oleh bootloader, dan harus tetap sebagai partisi fisik.
Setiap partisi dinamis dapat menjadi bagian dari grup pembaruan . Grup ini membatasi ruang maksimum yang dapat digunakan oleh partisi dalam grup tersebut. Misalnya, system
dan vendor
dapat menjadi bagian dari grup yang membatasi ukuran total system
dan vendor
.
Menerapkan partisi dinamis pada perangkat baru
Bagian ini menjelaskan cara menerapkan partisi dinamis pada peluncuran perangkat baru dengan Android 10 dan lebih tinggi. Untuk memperbarui perangkat yang ada, lihat Meningkatkan perangkat Android .
Perubahan partisi
Untuk perangkat yang diluncurkan dengan Android 10, buat partisi bernama super
. Partisi super
menangani slot A/B secara internal, jadi perangkat A/B tidak memerlukan partisi super_a
dan super_b
terpisah. Semua partisi AOSP read-only yang tidak digunakan oleh bootloader harus dinamis dan harus dihapus dari GUID Partition Table (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, ini harus mencakup ukuran kedua slot. Gambar 1 menunjukkan contoh tabel partisi sebelum dan sesudah dikonversi ke partisi dinamis.
![Tata letak tabel partisi](https://source.android.com/static/devices/tech/ota/images/dynamic_partitions_table.png?authuser=0&hl=id)
Partisi dinamis yang didukung adalah:
- Sistem
- Penjual
- Produk
- Sistem Ekst
- ODM
Untuk perangkat yang diluncurkan dengan Android 10, opsi baris perintah kernel androidboot.super_partition
harus kosong sehingga perintah sysprop ro.boot.super_partition
kosong.
Perataan partisi
Modul device-mapper mungkin beroperasi kurang efisien jika partisi super
tidak disejajarkan dengan benar. Partisi super
HARUS disejajarkan dengan ukuran permintaan I/O minimum seperti yang ditentukan oleh lapisan blok. Secara default, sistem build (melalui lpmake
, yang menghasilkan gambar partisi super
), mengasumsikan bahwa penyelarasan 1 MiB sudah cukup untuk setiap partisi dinamis. Namun, vendor harus memastikan bahwa partisi super
disejajarkan dengan benar.
Anda dapat menentukan ukuran permintaan minimum perangkat blok dengan memeriksa sysfs
. Sebagai 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 perataan partisi super
dengan cara yang sama:
# cat /sys/block/sda/sda17/alignment_offset
Keselarasan offset HARUS 0.
Perubahan konfigurasi perangkat
Untuk mengaktifkan partisi dinamis, tambahkan flag berikut di device.mk
:
PRODUCT_USE_DYNAMIC_PARTITIONS := true
Perubahan konfigurasi papan
Anda diminta untuk mengatur ukuran partisi super
:
BOARD_SUPER_PARTITION_SIZE := <size-in-bytes>
Pada perangkat A/B, sistem build memunculkan kesalahan jika ukuran total gambar partisi dinamis lebih dari setengah ukuran partisi super
.
Anda dapat mengkonfigurasi daftar partisi dinamis sebagai berikut. Untuk perangkat yang menggunakan grup pembaruan, buat daftar grup dalam variabel BOARD_SUPER_PARTITION_GROUPS
. Setiap nama grup kemudian memiliki BOARD_ group _SIZE
dan BOARD_ group _PARTITION_LIST
. Untuk perangkat A/B, ukuran maksimum grup harus mencakup hanya 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
, dan 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 pembuatan, jumlah ukuran gambar setiap partisi dalam grup pembaruan tidak boleh melebihi ukuran maksimum grup.
- Overhead diperlukan dalam perhitungan untuk memperhitungkan metadata, penyelarasan, dan sebagainya. Overhead yang wajar adalah 4 MiB, tetapi Anda dapat memilih overhead yang lebih besar sesuai kebutuhan perangkat.
Mengukur partisi dinamis
Sebelum partisi dinamis, ukuran partisi dialokasikan secara berlebihan untuk memastikan bahwa mereka memiliki cukup ruang untuk pembaruan di masa mendatang. Ukuran sebenarnya diambil apa adanya dan sebagian besar partisi hanya-baca memiliki sejumlah ruang kosong di sistem file mereka. Di partisi dinamis, ruang kosong itu tidak dapat digunakan dan dapat digunakan untuk menumbuhkan partisi selama OTA. Sangat penting untuk memastikan bahwa partisi tidak membuang-buang ruang dan dialokasikan ke ukuran seminimal mungkin.
Untuk image ext4 read-only, sistem build secara otomatis mengalokasikan ukuran minimum jika tidak ada ukuran partisi hardcode yang ditentukan. Sistem build sesuai dengan gambar sehingga sistem file memiliki ruang yang tidak terpakai sesedikit mungkin. Ini memastikan bahwa perangkat tidak membuang-buang ruang yang dapat digunakan untuk OTA.
Selain itu, gambar ext4 dapat dikompresi lebih lanjut dengan mengaktifkan deduplikasi tingkat blok. Untuk mengaktifkan ini, 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_ partition IMAGE_PARTITION_RESERVED_SIZE
, atau Anda dapat menentukan BOARD_ partition IMAGE_PARTITION_SIZE
untuk memaksa partisi dinamis ke ukuran tertentu. Tak satu pun dari ini direkomendasikan kecuali jika diperlukan.
Sebagai contoh:
BOARD_PRODUCTIMAGE_PARTITION_RESERVED_SIZE := 52428800
Ini memaksa sistem file di product.img
untuk memiliki 50 MiB ruang yang tidak terpakai.
Perubahan sistem sebagai root
Perangkat yang diluncurkan dengan Android 10 tidak boleh menggunakan sistem sebagai root.
Perangkat dengan partisi dinamis (baik diluncurkan dengan atau retrofit partisi dinamis) tidak boleh menggunakan sistem sebagai root. Kernel Linux tidak dapat menginterpretasikan partisi super
sehingga tidak dapat memasang system
itu sendiri. system
sekarang dipasang oleh init
tahap pertama, yang berada di ramdisk.
Jangan setel BOARD_BUILD_SYSTEM_ROOT_IMAGE
. Di Android 10, flag BOARD_BUILD_SYSTEM_ROOT_IMAGE
hanya digunakan untuk membedakan apakah sistem dipasang oleh kernel atau oleh init
tahap pertama di ramdisk.
Menyetel BOARD_BUILD_SYSTEM_ROOT_IMAGE
ke true
akan menyebabkan kesalahan pembuatan saat PRODUCT_USE_DYNAMIC_PARTITIONS
juga true
.
Ketika BOARD_USES_RECOVERY_AS_BOOT
disetel ke true, citra pemulihan dibuat sebagai boot.img, berisi ramdisk pemulihan. Sebelumnya, bootloader menggunakan parameter baris perintah kernel skip_initramfs
untuk memutuskan mode mana yang akan di-boot. Untuk perangkat Android 10, bootloader TIDAK HARUS meneruskan skip_initramfs
ke baris perintah kernel. Sebagai gantinya, bootloader harus melewati androidboot.force_normal_boot=1
untuk melewati pemulihan dan mem-boot Android normal. Perangkat yang diluncurkan dengan Android 12 atau lebih baru harus menggunakan bootconfig untuk lulus androidboot.force_normal_boot=1
.
Perubahan konfigurasi AVB
Saat menggunakan Android Verified Boot 2.0 , jika perangkat tidak menggunakan deskriptor partisi berantai , maka tidak diperlukan perubahan. Namun, jika menggunakan partisi berantai, dan salah satu partisi yang diverifikasi bersifat dinamis, maka perubahan diperlukan.
Berikut adalah contoh konfigurasi untuk perangkat yang vbmeta
untuk system
dan partisi 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 mengharapkan untuk menemukan vbmeta footer di akhir system
dan partisi vendor
. Karena partisi ini tidak lagi terlihat oleh bootloader (mereka berada di super
), diperlukan dua perubahan.
- Tambahkan partisi
vbmeta_system
danvbmeta_vendor
ke tabel partisi perangkat. Untuk perangkat A/B, tambahkanvbmeta_system_a
,vbmeta_system_b
,vbmeta_vendor_a
, danvbmeta_vendor_b
. Jika menambahkan satu atau lebih dari partisi ini, ukurannya harus sama dengan partisivbmeta
. - Ganti nama flag konfigurasi dengan menambahkan
VBMETA_
dan tentukan partisi mana yang diperluas rantainya ke: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 mungkin menggunakan salah satu, keduanya, atau tidak satu pun dari partisi ini. Perubahan hanya diperlukan saat merantai ke partisi logis.
Perubahan bootloader AVB
Jika bootloader telah menyematkan libavb , sertakan patch berikut:
- 818cf56740775446285466eda984acedd4baeac0 — "libavb: Hanya kueri GUID partisi saat cmdline membutuhkannya."
- 5abd6bc2578968d24406d834471adfd995a0c2e9 — "Izinkan partisi sistem tidak ada"
- 9ba3b6613b4e5130fa01a11d984c6b5f0eb3af05 — "Perbaiki AvbSlotVerifyData->cmdline mungkin NULL"
Jika menggunakan partisi berantai, sertakan tambalan tambahan:
- 49936b4c0109411fdd38bd4ba3a32a01c40439a9 — "libavb: Mendukung vbmeta blobs di awal partisi."
Perubahan baris perintah kernel
Parameter baru, androidboot.boot_devices
, harus ditambahkan ke baris perintah kernel. Ini digunakan oleh init
untuk mengaktifkan symlink /dev/block/by-name
. Itu harus menjadi komponen jalur perangkat ke symlink nama-dasar yang dibuat oleh ueventd
, yaitu, /dev/block/platform/ device-path /by-name/ partition-name
. Perangkat yang diluncurkan dengan Android 12 atau lebih baru harus menggunakan bootconfig untuk meneruskan androidboot.boot_devices
ke init
.
Misalnya, jika symlink dengan nama partisi super adalah /dev/block/platform/ soc/100000.ufshc /by-name/super
, Anda dapat menambahkan parameter baris perintah di file BoardConfig.mk sebagai berikut:
BOARD_KERNEL_CMDLINE += androidboot.boot_devices=soc/100000.ufshcAnda dapat menambahkan parameter bootconfig di file BoardConfig.mk sebagai berikut:
BOARD_BOOTCONFIG += androidboot.boot_devices=soc/100000.ufshc
perubahan fstab
Pohon perangkat dan hamparan 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:
- Bidang flag fs_mgr harus menyertakan flag
logical
dan flagfirst_stage_mount
, yang diperkenalkan di Android 10, yang menunjukkan bahwa partisi akan dipasang di tahap pertama. - Sebuah partisi dapat menentukan
avb= vbmeta partition name
sebagai flagfs_mgr
dan kemudian partisivbmeta
yang ditentukan diinisialisasi olehinit
tahap pertama sebelum mencoba memasang perangkat apa pun. - Bidang
dev
harus berupa nama partisi.
Entri fstab berikut mengatur sistem, vendor, dan produk sebagai partisi logis 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.
SELinux berubah
Perangkat blok partisi super harus ditandai dengan label super_block_device
. Misalnya, jika symlink dengan 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-userspace) tidak memahami partisi dinamis, sehingga tidak dapat mem-flash-nya. Untuk mengatasi ini, perangkat harus menggunakan implementasi ruang pengguna dari protokol fastboot, yang disebut fastbootd.
Untuk informasi selengkapnya tentang cara menerapkan fastbootd, lihat Memindahkan Fastboot ke Ruang Pengguna .
adb remount
Untuk pengembang yang menggunakan build eng atau userdebug, adb remount
sangat berguna untuk iterasi cepat. Partisi dinamis menimbulkan masalah untuk adb remount
karena tidak ada lagi ruang kosong di dalam setiap sistem file. Untuk mengatasi ini, perangkat dapat mengaktifkan overlayf. Selama ada ruang kosong di dalam partisi super, adb remount
secara otomatis membuat partisi dinamis sementara dan menggunakan overlayf untuk penulisan. Partisi sementara diberi nama scratch
, jadi jangan gunakan nama ini untuk partisi lain.
Untuk informasi selengkapnya tentang cara mengaktifkan overlayf, lihat README overlay di AOSP.
Meningkatkan perangkat Android
Jika Anda meningkatkan perangkat ke Android 10, dan ingin menyertakan dukungan partisi dinamis di OTA, Anda tidak perlu mengubah tabel partisi bawaan. Beberapa konfigurasi tambahan diperlukan.
Perubahan konfigurasi perangkat
Untuk retrofit partisi dinamis, tambahkan flag berikut di device.mk
:
PRODUCT_USE_DYNAMIC_PARTITIONS := true PRODUCT_RETROFIT_DYNAMIC_PARTITIONS := true
Perubahan konfigurasi papan
Anda diminta untuk mengatur variabel papan berikut:
- Setel
BOARD_SUPER_PARTITION_BLOCK_DEVICES
ke daftar perangkat blok yang digunakan untuk menyimpan luasan partisi dinamis. Ini adalah daftar nama partisi fisik yang ada pada perangkat. - Setel
BOARD_SUPER_PARTITION_ partition _DEVICE_SIZE
ke ukuran masing-masing perangkat blok diBOARD_SUPER_PARTITION_BLOCK_DEVICES
. Ini adalah daftar ukuran partisi fisik yang ada pada perangkat. Ini biasanyaBOARD_ partition IMAGE_PARTITION_SIZE
dalam konfigurasi papan yang ada. - Hapus partisi BOARD_ yang ada
BOARD_ partition IMAGE_PARTITION_SIZE
untuk semua partisi diBOARD_SUPER_PARTITION_BLOCK_DEVICES
. - Setel
BOARD_SUPER_PARTITION_SIZE
ke jumlahBOARD_SUPER_PARTITION_ partition _DEVICE_SIZE
. - Setel
BOARD_SUPER_PARTITION_METADATA_DEVICE
ke perangkat blok tempat metadata partisi dinamis disimpan. Itu harus salah satu dariBOARD_SUPER_PARTITION_BLOCK_DEVICES
. Biasanya, ini diatur kesystem
. - Tetapkan
BOARD_SUPER_PARTITION_GROUPS
,BOARD_ group _SIZE
, danBOARD_ group _PARTITION_LIST
. Lihat Perubahan konfigurasi papan pada perangkat baru untuk detailnya.
Misalnya, jika perangkat sudah memiliki partisi sistem dan vendor, dan Anda ingin mengonversinya menjadi partisi dinamis dan menambahkan partisi produk baru selama pembaruan, atur 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
SELinux berubah
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 luasan partisi dinamis, dan symlink dengan nama mereka 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 pada perangkat baru .
Untuk informasi selengkapnya tentang pembaruan retrofit, lihat OTA untuk Perangkat A/B tanpa Partisi Dinamis .
Gambar pabrik
Untuk peluncuran perangkat dengan dukungan partisi dinamis, hindari menggunakan fastboot userspace untuk mem-flash image pabrik, karena booting ke userspace lebih lambat daripada metode flashing lainnya.
Untuk mengatasi ini, make dist
sekarang membuat gambar super.img
tambahan yang dapat di-flash langsung ke partisi super. Ini secara otomatis menggabungkan konten partisi logis, artinya berisi system.img
, vendor.img
, dan seterusnya, selain metadata partisi super
. Gambar 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 gambar di slot A. Setelah mem-flash gambar super secara langsung, tandai slot A sebagai dapat di-boot sebelum mem-boot ulang perangkat.
Untuk perangkat retrofit, make dist
build satu set gambar super_*.img
yang dapat di-flash langsung ke partisi fisik yang sesuai. Misalnya, make dist
build super_system.img
dan super_vendor.img
ketika BOARD_SUPER_PARTITION_BLOCK_DEVICES
adalah vendor sistem. Gambar-gambar ini ditempatkan di folder OTA di target_files.zip
.
Penyetelan perangkat penyimpanan pemetaan perangkat
Partisi dinamis mengakomodasi sejumlah objek pemetaan perangkat nondeterministik. Ini mungkin tidak semua instantiate seperti yang diharapkan, jadi Anda harus melacak semua mount, dan memperbarui properti Android dari semua partisi terkait dengan perangkat penyimpanan yang mendasarinya.
Mekanisme di dalam init
melacak mount dan memperbarui properti Android secara asinkron. Jumlah waktu yang dibutuhkan ini tidak dijamin dalam periode tertentu, jadi Anda harus menyediakan waktu yang cukup untuk semua pemicu on property
untuk bereaksi. Propertinya adalah dev.mnt.blk. <partition>
di mana <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 ini:
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
menjadi aktif, dan nilainya mulai diperbarui. Namun, karena pemicu properti tidak aktif hingga late- init
, pemicu tersebut tidak dapat digunakan pada tahap boot awal untuk menangani root
, system
, atau vendor
. Anda mungkin mengharapkan read_ahead_kb
default kernel cukup sampai skrip init.rc
dapat ditimpa di early-fs
(ketika berbagai daemon dan fasilitas dimulai). Oleh karena itu, Google menyarankan Anda menggunakan fitur on property
, ditambah dengan properti yang dikontrol init.rc
seperti sys.read_ahead_kb
, untuk menangani pengaturan waktu operasi dan untuk mencegah kondisi balapan, 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}