Mengimplementasikan partisi dinamis

Partisi dinamis diimplementasikan menggunakan modul device-mapper dm-linear dalam 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 merepresentasikan setiap partisi dinamis.

Saat menerapkan OTA, partisi dinamis akan otomatis dibuat, ubah ukurannya, atau dihapus sesuai kebutuhan. Untuk perangkat A/B, ada dua salinan metadata, dan perubahan hanya diterapkan ke salinan yang mewakili 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, sehingga 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 pada perangkat baru yang diluncurkan dengan Android 10 dan 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.

Catatan: Hindari menempatkan userdata atau partisi baca-tulis permanen lainnya di dalam super.

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

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

Partisi dinamis yang didukung adalah:

• Sistem
• Vendor
• Produk
• Ekstensi Sistem
• Pengelolaan Pesanan dan Pemenuhan Produk

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 mapper perangkat mungkin beroperasi kurang efisien jika partisi super tidak disejajarkan dengan benar. Partisi super HARUS diselaraskan dengan ukuran permintaan I/O minimum seperti yang 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 bahwa partisi super sudah diselaraskan 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 perataan partisi super dengan cara yang serupa:

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

Offset perataan HARUS 0.

Perubahan konfigurasi perangkat

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

PRODUCT_USE_DYNAMIC_PARTITIONS := true

Perubahan konfigurasi board

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

Catatan: Hindari memilih nama yang dapat bertentangan dengan variabel build, seperti super dan super_partition. Untuk keterbacaan, pilih nama seperti foo_dp, foo_dynamic_partitions, foo_dp_group, super_foo, atau group_foo (dengan foo adalah nama pihak yang mengupdate grup tertentu). Misalnya, group_OEM atau group_VENDOR.

Catatan: Mungkin ada satu atau beberapa grup update di perangkat Anda.

• Untuk perangkat peluncuran Virtual A/B, jumlah ukuran maksimum semua grup harus paling banyak:
  BOARD_SUPER_PARTITION_SIZE - overhead
  Lihat Menerapkan Virtual A/B.
• Untuk perangkat peluncuran A/B, jumlah ukuran maksimum semua grup harus menjadi:
  BOARD_SUPER_PARTITION_SIZE / 2 - overhead
• Untuk perangkat non-A/B dan perangkat A/B yang dimodifikasi, jumlah ukuran maksimum semua grup harus:
  BOARD_SUPER_PARTITION_SIZE - overhead
• Pada waktu build, jumlah ukuran image setiap partisi dalam grup update tidak boleh melebihi ukuran maksimum grup.
• Overhead diperlukan dalam komputasi untuk memperhitungkan metadata, penyelarasan, 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 cukup ruang untuk update mendatang. Ukuran sebenarnya diambil apa adanya dan sebagian besar partisi hanya baca memiliki sejumlah ruang kosong di sistem filenya. Dalam partisi dinamis, ruang kosong tersebut tidak dapat digunakan dan dapat digunakan untuk memperluas partisi selama OTA. Sangat penting untuk memastikan bahwa partisi tidak membuang ruang dan dialokasikan ke ukuran minimum yang memungkinkan.

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

Selain itu, image 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 menentukan BOARD_partitionIMAGE_PARTITION_SIZE untuk memaksa partisi dinamis ke ukuran tertentu. Kedua hal ini tidak direkomendasikan kecuali jika diperlukan.

Contoh:

BOARD_PRODUCTIMAGE_PARTITION_RESERVED_SIZE := 52428800

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

Catatan: Sistem build hanya dapat menyesuaikan image sistem file ext4 dengan tepat, dan hanya pada image yang dihasilkan oleh build. Untuk image bawaan, atau image yang menggunakan sistem file lain, penting untuk memastikan secara manual bahwa sistem file tidak membuang ruang disk.

Perubahan sistem sebagai root

Perangkat yang diluncurkan dengan Android 10 tidak boleh menggunakan sistem sebagai root.

Perangkat dengan partisi dinamis (baik yang diluncurkan dengan maupun yang retrofit partisi dinamis) tidak boleh menggunakan sistem-sebagai root. Kernel Linux tidak dapat menafsirkan partisi super sehingga tidak dapat memasang system itu sendiri. system kini dipasang oleh init tahap pertama, yang berada di ramdisk.

Jangan tetapkan 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 jika PRODUCT_USE_DYNAMIC_PARTITIONS juga true.

Jika BOARD_USES_RECOVERY_AS_BOOT ditetapkan ke true, image pemulihan akan di-build sebagai boot.img, yang berisi ramdisk pemulihan. Sebelumnya, bootloader menggunakan parameter command line kernel skip_initramfs untuk menentukan mode yang akan di-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-booting 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

Perhatian: Partisi dinamis memerlukan Android Verified Boot (AVB) dan tidak akan berfungsi dengan Verified Boot 1.0.

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

Berikut adalah contoh konfigurasi untuk perangkat yang merantai 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 mengharapkan untuk menemukan 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, partisi tersebut harus berukuran sama dengan partisi vbmeta.
• Ganti nama flag konfigurasi dengan menambahkan VBMETA_ dan tentukan partisi yang diperluas oleh rantai:

  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 satu, keduanya, atau tidak satu pun dari partisi ini. Perubahan hanya diperlukan saat membuat rantai ke partisi logis.

Perubahan bootloader AVB

Jika bootloader telah menyematkan libavb, sertakan patch berikut:

• 818cf56740775446285466eda984acedd4baeac0 — "libavb: Hanya membuat kueri GUID partisi saat cmdline membutuhkannya."
• 5abd6bc2578968d24406d834471adfd995a0c2e9 — "Izinkan partisi sistem tidak ada"
• 9ba3b6613b4e5130fa01a11d984c6b5f0eb3af05 — "Perbaiki AvbSlotVerifyData->cmdline mungkin NULL"

Jika menggunakan partisi berantai, sertakan patch tambahan:

• 49936b4c0109411fdd38bd4ba3a32a01c40439a9 — "libavb: Mendukung blob vbmeta di awal partisi."
  Catatan: Sebelumnya, mengimplementasikan get_size_of_partition di AvbOps bersifat opsional. Setelah perubahan ini, perubahan ini diperlukan, dan bootloader harus menerapkan fungsi ini.

Perubahan command line kernel

Parameter baru, androidboot.boot_devices, harus ditambahkan ke command line kernel. Ini digunakan oleh init untuk mengaktifkan symlink /dev/block/by-name. Ini harus berupa komponen jalur perangkat ke symlink berdasarkan nama yang mendasarinya 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 symlink super partisi menurut nama adalah /dev/block/platform/soc/100000.ufshc/by-name/super, Anda dapat menambahkan parameter command line di file BoardConfig.mk sebagai berikut:

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

Anda dapat menambahkan parameter bootconfig di file BoardConfig.mk sebagai berikut:

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

perubahan fstab

Hierarki perangkat dan overlay hierarki 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 flag fs_mgr harus menyertakan flag logical dan 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 tanda 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

Catatan: Jangan sertakan slotselect untuk perangkat non-A/B.

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

fastboot

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 User Space.

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 operasi tulis. Partisi sementara bernama scratch, jadi jangan gunakan nama ini untuk partisi lain.

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

Mengupgrade perangkat Android

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

Perubahan konfigurasi perangkat

Untuk melakukan retrofit partisi dinamis, tambahkan flag berikut di device.mk:

PRODUCT_USE_DYNAMIC_PARTITIONS := true
PRODUCT_RETROFIT_DYNAMIC_PARTITIONS := true

Perubahan konfigurasi board

Anda harus menetapkan variabel board berikut:

• Tetapkan BOARD_SUPER_PARTITION_BLOCK_DEVICES ke daftar perangkat blok yang digunakan untuk menyimpan ekstensi 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 board yang ada.
• Hapus penetapan 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.
• Tetapkan BOARD_SUPER_PARTITION_METADATA_DEVICE ke perangkat blok tempat metadata partisi dinamis disimpan. Harus berupa salah satu dari BOARD_SUPER_PARTITION_BLOCK_DEVICES. Biasanya, nilai ini ditetapkan ke system.
• Tetapkan masing-masing BOARD_SUPER_PARTITION_GROUPS, BOARD_group_SIZE, dan BOARD_group_PARTITION_LIST. Lihat Perubahan konfigurasi Board pada perangkat baru untuk mengetahui detailnya.

Misalnya, jika perangkat sudah memiliki partisi sistem dan vendor, dan Anda ingin mengonversinya menjadi partisi dinamis dan menambahkan partisi produk baru selama update, tetapkan konfigurasi board 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 ekstensi partisi dinamis, dan symlink 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 Mengimplementasikan partisi dinamis di perangkat baru.

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

Setelan pabrik

Untuk peluncuran perangkat 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 mem-build image super.img tambahan yang dapat di-flash langsung ke super partisi. File ini otomatis memaketkan konten partisi logis, yang berarti 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 gambar di slot A. Setelah mem-flash super image secara langsung, tandai slot A sebagai dapat di-booting sebelum memulai ulang perangkat.

Untuk perangkat retrofit, make dist mem-build kumpulan 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 saat BOARD_SUPER_PARTITION_BLOCK_DEVICES adalah vendor sistem. Image ini ditempatkan di folder OTA di target_files.zip.

Penyesuaian perangkat penyimpanan mapper perangkat

Partisi dinamis mengakomodasi sejumlah objek mapper perangkat yang tidak deterministik. Semua partisi ini mungkin tidak dibuat instance-nya seperti yang diharapkan, sehingga Anda harus melacak semua pasangan, dan mengupdate 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 periode tertentu, jadi Anda harus memberikan waktu yang cukup agar semua pemicu on property bereaksi. Propertinya 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 disesuaikan 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 menjadi aktif, dan nilai mulai diperbarui. Namun, karena pemicu properti belum aktif hingga akhir init, pemicu tersebut tidak dapat digunakan pada tahap booting awal untuk menangani root, system, atau vendor. Anda mungkin mengharapkan read_ahead_kb default kernel sudah memadai hingga skrip init.rc dapat diganti di early-fs (saat berbagai daemon dan fasilitas dimulai). Oleh karena itu, Google merekomendasikan agar Anda menggunakan fitur on property, yang digabungkan dengan properti yang dikontrol init.rc seperti sys.read_ahead_kb, untuk menangani pengaturan waktu operasi dan mencegah kondisi perlombaan, 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}