Di Android 10, sistem file root tidak lagi
  disertakan dalam ramdisk.img dan digabungkan ke dalam
  system.img (yaitu, system.img selalu dibuat sebagai
  jika BOARD_BUILD_SYSTEM_ROOT_IMAGE ditetapkan). Perangkat
  yang diluncurkan dengan Android 10:
- Gunakan tata letak partisi sistem sebagai root (otomatis diterapkan oleh build tanpa opsi untuk mengubah perilaku).
 - Harus menggunakan ramdisk, yang diperlukan untuk dm-linear.
 - Harus menetapkan 
BOARD_BUILD_SYSTEM_ROOT_IMAGEkefalse. Setelan ini hanya digunakan untuk membedakan antara perangkat yang menggunakan ramdisk dan perangkat yang tidak menggunakan ramdisk (dan sebagai gantinya memasangsystem.imgsecara langsung). 
  Makna konfigurasi sistem sebagai root berbeda antara Android 9 dan
  Android 10. Dalam konfigurasi sistem-sebagai-root
  Android 9, BOARD_BUILD_SYSTEM_ROOT_IMAGE ditetapkan ke
  true, yang memaksa build menggabungkan sistem file root ke
  system.img, lalu memasang system.img sebagai sistem file
  root (rootfs). Konfigurasi ini wajib untuk perangkat
  yang diluncurkan dengan Android 9, tetapi opsional untuk perangkat yang diupgrade ke
  Android 9 dan untuk perangkat yang menjalankan Android versi yang lebih rendah. Dalam konfigurasi sistem-sebagai-root
  Android 10, build selalu
  menggabungkan $TARGET_SYSTEM_OUT dan $TARGET_ROOT_OUT menjadi
  system.img; konfigurasi ini adalah perilaku default untuk semua perangkat
  yang menjalankan Android 10.
Android 10 melakukan perubahan lebih lanjut untuk mendukung partisi dinamis, sistem partisi ruang pengguna yang memungkinkan update over-the-air (OTA) untuk membuat, mengubah ukuran, atau menghapus partisi. Sebagai bagian dari perubahan ini, kernel Linux tidak dapat lagi memasang partisi sistem logis di perangkat yang menjalankan Android 10, sehingga operasi ini ditangani oleh init tahap pertama.
Bagian berikut menjelaskan persyaratan sistem sebagai root untuk OTA khusus sistem, memberikan panduan tentang cara mengupdate perangkat untuk menggunakan sistem sebagai root (termasuk perubahan tata letak partisi dan persyaratan kernel dm-verity). Untuk mengetahui detail tentang perubahan pada ramdisk, lihat Partisi Ramdisk.
Tentang OTA khusus sistem
  OTA khusus sistem, yang memungkinkan rilis Android mengupdate
  system.img dan product.img tanpa mengubah
  partisi lainnya, memerlukan tata letak partisi sistem sebagai root. Semua perangkat yang menjalankan Android
  10 harus menggunakan tata letak partisi sistem sebagai root untuk
  mengaktifkan OTA khusus sistem.
- Perangkat A/B, yang memasang partisi 
systemsebagai rootfs, sudah menggunakan sistem sebagai root dan tidak memerlukan perubahan untuk mendukung OTA sistem. - Perangkat non-A/B, yang memasang partisi 
systemdi/system, harus diupdate untuk menggunakan tata letak partisi sistem sebagai root guna mendukung OTA sistem. 
Untuk mengetahui detail tentang perangkat A/B dan non-A/B, lihat Update Sistem A/B (Lancar).
Menggunakan overlay vendor (<=AOSP 14)
Overlay vendor memungkinkan Anda menempatkan perubahan pada partisi vendor
saat perangkat melakukan booting. Overlay vendor adalah kumpulan modul vendor di
partisi product yang ditempatkan di atas partisi
vendor saat perangkat melakukan booting, menggantikan dan menambahkan ke modul yang ada.
Saat perangkat melakukan booting, proses init akan menyelesaikan pemasangan
tahap pertama dan membaca properti default. Kemudian, sistem akan menelusuri
/product/vendor_overlay/<target_vendor_version> dan memasang
setiap subdirektori di direktori partisi vendor yang sesuai,
jika kondisi berikut terpenuhi:
/vendor/<overlay_dir>ada./product/vendor_overlay/<target_vendor_version>/<overlay_dir>memiliki konteks file yang sama dengan/vendor/<overlay_dir>.initdiizinkan untuk di-mount pada konteks file/vendor/<overlay_dir>.
Menerapkan overlay vendor
Instal file overlay vendor di
/product/vendor_overlay/<target_vendor_version>. File tersebut
menutupi partisi vendor saat perangkat melakukan booting, menggantikan file
dengan nama yang sama dan menambahkan file baru. Overlay vendor tidak dapat menghapus file
dari partisi vendor.
File overlay vendor harus memiliki konteks file yang sama dengan file target
yang diganti di partisi vendor. Secara default, file dalam
direktori /product/vendor_overlay/<target_vendor_version>
memiliki konteks vendor_file. Jika ada ketidakcocokan konteks file
antara file overlay vendor dan file yang digantinya, tentukan hal tersebut dalam
sepolicy khusus perangkat. Konteks file ditetapkan di tingkat direktori. Jika
konteks file direktori overlay vendor tidak cocok dengan direktori target,
dan konteks file yang benar tidak ditentukan dalam sepolicy khusus perangkat,
direktori overlay vendor tersebut tidak akan ditempatkan di direktori target.
Untuk menggunakan overlay vendor, kernel harus mengaktifkan OverlayFS dengan menetapkan
CONFIG_OVERLAY_FS=y. Selain itu, kernel harus digabungkan dari
kernel umum 4.4 atau yang lebih baru, atau di-patch dengan "overlayfs:
override_creds=off option bypass creator_cred".
Contoh penerapan overlay vendor
Prosedur ini menunjukkan penerapan overlay vendor yang menempatkan direktori
/vendor/lib/*, /vendor/etc/*, dan
/vendor/app/*.
- 
Tambahkan file vendor bawaan di
device/<vendor>/<target>/vendor_overlay/<target_vendor_version>/:device/google/device/vendor_overlay/28/lib/libfoo.so device/google/device/vendor_overlay/28/lib/libbar.so device/google/device/vendor_overlay/28/etc/baz.xml device/google/device/vendor_overlay/28/app/qux.apk
 - 
Instal file vendor bawaan ke
product/vendor_overlaydidevice/google/device/device.mk:PRODUCT_COPY_FILES += \ $(call find-copy-subdir-files,*,device/google/device/vendor_overlay,$(TARGET_COPY_OUT_PRODUCT)/vendor_overlay)
 - 
Tentukan konteks file jika file partisi
vendortarget memiliki konteks selainvendor_file. Karena/vendor/lib/*menggunakan konteksvendor_file, contoh ini tidak menyertakan direktori tersebut.Tambahkan kode berikut ke
device/google/device-sepolicy/private/file_contexts:/(product|system/product)/vendor_overlay/[0-9]+/etc(/.*)? u:object_r:vendor_configs_file:s0 /(product|system/product)/vendor_overlay/[0-9]+/app(/.*)? u:object_r:vendor_app_file:s0
 - 
Izinkan proses
inituntuk memasang overlay vendor pada konteks file selainvendor_file. Karena prosesinitsudah memiliki izin untuk di-mount pada konteksvendor_file, contoh ini tidak menentukan kebijakan untukvendor_file.Tambahkan kode berikut ke
device/google/device-sepolicy/public/init.te:allow init vendor_configs_file:dir mounton; allow init vendor_app_file:dir mounton;
 
Memvalidasi overlay vendor
Untuk memvalidasi konfigurasi overlay vendor, tambahkan file di
/product/vendor_overlay/<target_vendor_version>/<overlay_dir>
dan periksa apakah file tersebut ditempatkan di file di
/vendor/<overlay_dir>.
Untuk build userdebug, ada modul pengujian untuk Atest:
$ atest -v fs_mgr_vendor_overlay_test
Mengupdate ke sistem-sebagai-root
  Untuk mengupdate perangkat non-A/B agar menggunakan sistem sebagai root, Anda harus mengupdate
  skema partisi untuk boot.img dan system.img, menyiapkan
  dm-verity, dan menghapus dependensi booting apa pun di folder root
  khusus perangkat.
Memperbarui partisi
  Tidak seperti perangkat A/B yang menggunakan kembali /boot sebagai
  partisi pemulihan,
  perangkat non-A/B harus tetap memisahkan
  partisi /recovery karena tidak memiliki partisi slot penggantian (misalnya,
  dari boot_a ke boot_b). Jika /recovery
  dihapus di perangkat non-A/B dan dibuat mirip dengan skema A/B, mode pemulihan
  dapat rusak selama update yang gagal ke partisi /boot. Karena
  alasan ini, partisi /recovery harus berupa
  partisi terpisah dari /boot untuk perangkat non-A/B, yang menyiratkan
  bahwa image pemulihan terus diupdate dengan cara yang ditangguhkan (yaitu
  sama seperti di perangkat yang menjalankan Android 8.1.0 atau yang lebih lama).
Tabel berikut mencantumkan perbedaan partisi image untuk perangkat non-A/B sebelum dan sesudah Android 9.
| Gambar | Ramdisk (sebelum 9) | System-as-root (setelah 9) | 
|---|---|---|
boot.img | 
    Berisi kernel dan ramdisk.img:
    ramdisk.img
  -/
    - init.rc
    - init
    - etc -> /system/etc
    - system/ (mount point)
    - vendor/ (mount point)
    - odm/ (mount point)
    ... | 
    Hanya berisi kernel booting normal. | 
recovery.img | 
    Berisi kernel pemulihan dan
    ramdisk.img pemulihan. | 
  |
system.img | 
    Berisi hal berikut:
    system.img
  -/
    - bin/
    - etc
    - vendor -> /vendor
    - ... | 
    Berisi konten gabungan dari system.img dan
    ramdisk.img asli:
    system.img
  -/
    - init.rc
    - init
    - etc -> /system/etc
    - system/
      - bin/
      - etc/
      - vendor -> /vendor
      - ...
    - vendor/ (mount point)
    - odm/ (mount point)
    ... | 
  
Partisi itu sendiri tidak berubah; ramdisk dan sistem-sebagai-root menggunakan skema partisi berikut:
/boot/system/system/recovery/vendor, dll.
Menyiapkan dm-verity
  Dalam system-as-root, kernel harus memasang system.img di
  / (titik pemasangan) dengan
  dm-verity. AOSP mendukung implementasi dm-verity
  berikut untuk system.img.
vboot 1.0
  Untuk vboot 1.0, kernel harus mengurai
  metadata khusus
  Android di
  /system, lalu mengonversi ke
  dm-verity params untuk menyiapkan dm-verity (memerlukan
  patch kernel ini).
  Contoh berikut menunjukkan setelan terkait dm-verity untuk sistem-sebagai-root di
  command line kernel:
ro root=/dev/dm-0 rootwait skip_initramfs init=/init dm="system none ro,0 1 android-verity /dev/sda34" veritykeyid=id:7e4333f9bba00adfe0ede979e28ed1920492b40f
vboot 2.0
  Untuk vboot 2.0
  (AVB), bootloader harus mengintegrasikan
  external/avb/libavb, yang kemudian mengurai
   deskripsi hashtree untuk /system, mengonversinya
  menjadi
  dm-verity params, dan akhirnya meneruskan parameter ke
  kernel melalui command line kernel. (Deskripsi hashtree /system
  mungkin ada di /vbmeta atau di /system itu sendiri.)
vboot 2.0 memerlukan patch kernel berikut:
- https://android-review.googlesource.com/#/c/kernel/common/+/158491/
 - patch kernel 4.4, patch kernel 4.9, dll.
 
Contoh berikut menunjukkan setelan terkait dm-verity untuk sistem-sebagai-root di command line kernel:
ro root=/dev/dm-0 rootwait skip_initramfs init=/init dm="1 vroot none ro 1,0 5159992 verity 1 PARTUUID=00000016-0000-0000-0000-000000000000 PARTUUID=00000016-0000-0000-0000-000000000000 4096 4096 644999 644999 sha1 d80b4a8be3b58a8ab86fad1b498640892d4843a2 8d08feed2f55c418fb63447fec0d32b1b107e42c 10 restart_on_corruption ignore_zero_blocks use_fec_from_device PARTUUID=00000016-0000-0000-0000-000000000000 fec_roots 2 fec_blocks 650080 fec_start 650080"
Menggunakan folder root khusus perangkat
  Dengan sistem sebagai root, setelah image sistem umum
  (GSI) di-flash di perangkat (dan sebelum menjalankan
  pengujian Vendor Test Suite), semua
  folder root khusus perangkat yang ditambahkan dengan BOARD_ROOT_EXTRA_FOLDERS
  akan hilang karena seluruh konten direktori root telah diganti dengan
  GSI sistem sebagai root. Penghapusan folder ini dapat menyebabkan perangkat
  tidak dapat di-booting jika ada dependensi pada folder root khusus perangkat
  (misalnya, folder tersebut digunakan sebagai titik pemasangan).
  Untuk menghindari masalah ini, jangan gunakan BOARD_ROOT_EXTRA_FOLDERS untuk
  menambahkan folder root khusus perangkat. Jika Anda perlu menentukan titik pemasangan
  khusus perangkat, gunakan /mnt/vendor/<mount point> (ditambahkan dalam
  daftar perubahan ini). Titik pemasangan khusus vendor ini dapat
  ditentukan secara langsung di hierarki perangkat fstab (untuk pemasangan
  tahap pertama) dan file /vendor/etc/fstab.{ro.hardware} tanpa
  penyiapan tambahan (karena fs_mgr membuatnya di
  /mnt/vendor/* secara otomatis).