Menerapkan partisi dinamis

Partisi dinamis diimplementasikan menggunakan modul dm-linear device-mapper di kernel Linux. Partisi super berisi metadata yang mencantumkan nama dan rentang blok setiap partisi dinamis dalam super . Selama init tahap pertama, metadata ini diurai 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 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 anggota 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 .

Terapkan partisi dinamis pada perangkat baru

Bagian ini merinci cara menerapkan partisi dinamis pada perangkat baru yang diluncurkan dengan Android 10 dan lebih tinggi. Untuk memperbarui perangkat yang ada, lihat Mengupgrade perangkat Android .

Perubahan partisi

Untuk perangkat yang diluncurkan dengan Android 10, buat partisi bernama super . Partisi super menangani slot A/B secara internal, sehingga perangkat A/B tidak memerlukan partisi super_a dan super_b yang 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.

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 mencakup ukuran kedua slot. Gambar 1 menunjukkan contoh tabel partisi sebelum dan sesudah konversi ke partisi dinamis.

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

Partisi dinamis yang didukung adalah:

• Sistem
• Penjual
• Produk
• Ekst. Sistem
• 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.

Penyelarasan partisi

Modul pemeta perangkat mungkin beroperasi kurang efisien jika partisi super tidak diselaraskan dengan benar. Partisi super HARUS disejajarkan dengan ukuran permintaan I/O minimum sebagaimana ditentukan oleh lapisan blok. Secara default, sistem pembangunan (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 . Misalnya:

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

# 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 diminta untuk mengatur ukuran partisi super :

BOARD_SUPER_PARTITION_SIZE := <size-in-bytes>

Pada perangkat A/B, sistem pembangunan memunculkan kesalahan jika ukuran total gambar partisi dinamis lebih dari setengah ukuran partisi super .

Anda dapat mengonfigurasi daftar partisi dinamis sebagai berikut. Untuk perangkat yang menggunakan grup pembaruan, 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 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

Catatan: Hindari memilih nama yang dapat bertentangan dengan variabel build, seperti super dan super_partition . Agar mudah dibaca, pilih nama seperti foo_dp , foo_dynamic_partitions , foo_dp_group , super_foo , atau group_foo (di mana foo adalah nama pihak yang memperbarui grup tertentu). Misalnya, group_OEM atau group_VENDOR .

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

• Untuk perangkat peluncuran A/B Virtual, jumlah ukuran maksimum semua grup harus maksimal:
  BOARD_SUPER_PARTITION_SIZE - overhead
  Lihat Menerapkan Virtual A/B .
• Untuk perangkat peluncuran A/B, jumlah ukuran maksimum semua grup harus:
  BOARD_SUPER_PARTITION_SIZE / 2 - overhead
• Untuk perangkat non-A/B dan perangkat retrofit A/B, 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 komputasi untuk memperhitungkan metadata, penyelarasan, dan sebagainya. Overhead yang wajar adalah 4 MiB, namun Anda dapat memilih overhead yang lebih besar sesuai kebutuhan perangkat.

Ukuran partisi dinamis

Sebelum adanya partisi dinamis, ukuran partisi dialokasikan secara berlebihan untuk memastikan bahwa partisi tersebut memiliki cukup ruang untuk pembaruan di masa mendatang. Ukuran sebenarnya diambil apa adanya dan sebagian besar partisi read-only memiliki sejumlah ruang kosong di sistem filenya. Dalam partisi dinamis, ruang kosong tersebut tidak dapat digunakan dan dapat digunakan untuk mengembangkan partisi selama OTA. 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 menyesuaikan image sehingga sistem file memiliki ruang yang tidak terpakai sesedikit mungkin. Hal ini memastikan perangkat tidak membuang-buang ruang yang dapat digunakan untuk OTA.

Selain itu, gambar ext4 dapat dikompresi lebih lanjut dengan mengaktifkan deduplikasi 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_ 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 hal ini direkomendasikan kecuali diperlukan.

Misalnya:

BOARD_PRODUCTIMAGE_PARTITION_RESERVED_SIZE := 52428800

Hal ini memaksa sistem file di product.img memiliki 50 MiB ruang yang tidak terpakai.

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

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 menafsirkan 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 menyebabkan kesalahan build ketika PRODUCT_USE_DYNAMIC_PARTITIONS juga true .

Ketika BOARD_USES_RECOVERY_AS_BOOT disetel ke true, image pemulihan dibuat sebagai boot.img, berisi ramdisk pemulihan. Sebelumnya, bootloader menggunakan parameter baris perintah kernel skip_initramfs untuk memutuskan mode mana yang akan digunakan untuk boot. Untuk perangkat Android 10, bootloader TIDAK HARUS meneruskan skip_initramfs ke baris perintah kernel. Sebaliknya, 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 agar dapat lolos androidboot.force_normal_boot=1 .

Perubahan konfigurasi AVB

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

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 terverifikasi bersifat dinamis, maka diperlukan perubahan.

Berikut ini contoh konfigurasi untuk perangkat yang menghubungkan 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 menemukan footer vbmeta di akhir partisi system dan vendor . Karena partisi ini tidak lagi terlihat oleh bootloader (berada di super ), diperlukan dua perubahan.

• 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 lebih partisi ini, ukurannya harus sama dengan partisi vbmeta .
• Ganti nama flag konfigurasi dengan menambahkan VBMETA_ dan tentukan partisi mana yang diperluas rangkaiannya:

  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 sama sekali dari partisi ini. Perubahan hanya diperlukan saat merangkai ke partisi logis.

Perubahan bootloader AVB

Jika bootloader telah menyematkan libavb , sertakan patch berikut:

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

Jika menggunakan partisi berantai, sertakan patch tambahan:

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

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 . Ini harus berupa komponen jalur perangkat ke symlink berdasarkan nama 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 berdasarkan 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.ufshc

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

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

perubahan fstab

Lapisan pohon perangkat dan 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 flag first_stage_mount , yang diperkenalkan di Android 10, yang menunjukkan bahwa partisi akan dipasang pada tahap pertama.
• Sebuah partisi dapat menentukan avb= vbmeta partition name sebagai flag fs_mgr dan kemudian partisi vbmeta yang ditentukan diinisialisasi oleh init 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 dengan 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.

Copy file fstab ke ramdisk tahap pertama.

SELinux berubah

Perangkat blok partisi super harus ditandai dengan label super_block_device . Misalnya, jika symlink berdasarkan 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 lainnya) tidak memahami partisi dinamis, sehingga tidak dapat mem-flash-nya. Untuk mengatasi hal ini, perangkat harus menggunakan implementasi protokol fastboot ruang pengguna, yang disebut fastbootd.

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

adb pasang kembali

Untuk pengembang 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 di dalam partisi super, adb remount secara otomatis membuat partisi dinamis sementara dan menggunakan overlayfs untuk penulisan. Partisi sementara diberi nama scratch , jadi jangan gunakan nama ini untuk partisi lain.

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

Tingkatkan perangkat Android

Jika Anda mengupgrade 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 melakukan retrofit partisi dinamis, tambahkan tanda 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 di BOARD_SUPER_PARTITION_BLOCK_DEVICES . Ini adalah daftar ukuran partisi fisik yang ada pada perangkat. Ini biasanya BOARD_ partition IMAGE_PARTITION_SIZE dalam konfigurasi papan yang ada.
• Batalkan penyetelan BOARD_ partition IMAGE_PARTITION_SIZE untuk semua partisi di BOARD_SUPER_PARTITION_BLOCK_DEVICES .
• Setel 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. Itu harus salah satu dari BOARD_SUPER_PARTITION_BLOCK_DEVICES . Biasanya, ini diatur ke system .
• Setel BOARD_SUPER_PARTITION_GROUPS , BOARD_ group _SIZE , dan BOARD_ group _PARTITION_LIST . Lihat perubahan konfigurasi Board 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 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

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 berdasarkan 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 pada perangkat baru .

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

Gambar pabrik

Untuk perangkat yang diluncurkan dengan dukungan partisi dinamis, hindari menggunakan fastboot userspace untuk mem-flash image pabrik, karena boot ke userspace lebih lambat dibandingkan metode flashing lainnya.

Untuk mengatasi hal ini, make dist sekarang membuat image super.img tambahan yang dapat di-flash langsung ke partisi super. 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 apa pun atau menggunakan fastbootd. Setelah pembuatan, 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 melakukan boot ulang perangkat.

Untuk perangkat retrofit, make dist membuat sekumpulan gambar super_*.img yang dapat di-flash langsung ke partisi fisik terkait. 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 mapper perangkat

Partisi dinamis mengakomodasi sejumlah objek pemetaan perangkat nondeterministik. Ini mungkin tidak semuanya dibuat 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 mount dan memperbarui properti Android secara asinkron. Jumlah waktu yang dibutuhkan tidak dijamin dalam jangka waktu tertentu, jadi Anda harus menyediakan waktu yang cukup agar semua pemicu on property dapat 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 disesuaikan 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 pada tahap kedua init , epoll loop menjadi aktif, dan nilainya mulai diperbarui. Namun, karena pemicu properti tidak aktif hingga init akhir, pemicu tersebut tidak dapat digunakan pada tahap boot awal untuk menangani root , system , atau vendor . Anda mungkin mengharapkan read_ahead_kb default kernel cukup hingga skrip init.rc dapat ditimpa di early-fs (ketika berbagai daemon dan fasilitas dimulai). Oleh karena itu, Google menyarankan agar Anda menggunakan fitur on property , ditambah dengan properti yang dikontrol init.rc seperti sys.read_ahead_kb , untuk mengatur waktu pengoperasian dan 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}