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

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 dikonversi ke partisi dinamis.

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

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

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 lebih grup pembaruan di perangkat Anda.

• 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.

Catatan: Sistem build hanya dapat paling sesuai dengan image sistem file ext4, dan hanya pada image yang dihasilkan oleh build. Untuk gambar yang dibuat sebelumnya, atau gambar yang menggunakan sistem file lain, penting untuk memastikan secara manual bahwa sistem file tidak membuang-buang ruang di 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 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

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 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 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 dari partisi ini, ukurannya harus sama dengan partisi vbmeta .
• 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."
  Catatan: Sebelumnya, adalah opsional untuk mengimplementasikan get_size_of_partition di AvbOps . 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 . 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.ufshc

Anda 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 flag first_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 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 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.

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 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.
• Hapus partisi BOARD_ yang ada 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 .
• Tetapkan BOARD_SUPER_PARTITION_GROUPS , BOARD_ group _SIZE , dan BOARD_ 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}