Ringkasan A/B virtual

Virtual A/B adalah mekanisme update utama Android. Build A/B virtual dibuat berdasarkan update A/B lama (lihat Update Sistem A/B) dan non-A/B yang tidak digunakan lagi di versi 15 untuk mengurangi overhead ruang update.

Virtual A/B sebenarnya tidak memiliki slot tambahan untuk partisi dinamis, lihat partisi dinamis. Sebagai gantinya, delta ditulis ke snapshot, lalu digabungkan ke partisi dasar setelah mengonfirmasi booting yang berhasil. Virtual A/B menggunakan format snapshot khusus Android. Lihat Format COW untuk snapshot yang dikompresi yang memungkinkan snapshot dikompresi dan meminimalkan penggunaan ruang disk. Pada OTA lengkap, ukuran snapshot dikurangi sekitar 45% dengan kompresi, dan ukuran snapshot OTA inkremental dikurangi sekitar 55%.

Android 12 menawarkan opsi kompresi Virtual A/B untuk mengompresi partisi yang diambil snapshot-nya. A/B virtual menawarkan hal berikut

  • Update A/B virtual lancar (update terjadi sepenuhnya di latar belakang saat perangkat beroperasi) seperti update A/B. Update A/B virtual akan meminimalkan waktu perangkat offline dan tidak dapat digunakan.
  • Update A/B virtual dapat di-roll back. Jika OS baru gagal melakukan booting, perangkat akan otomatis melakukan rollback ke versi sebelumnya.
  • Update A/B virtual menggunakan ruang tambahan minimum dengan hanya menduplikasi partisi yang digunakan oleh bootloader. Partisi lain yang dapat diupdate diambil snapshot-nya.

Latar Belakang dan terminologi

Bagian ini menentukan terminologi dan menjelaskan teknologi yang mendukung A/B virtual. Selama penginstalan OTA, data sistem operasi baru ditulis ke slot barunya untuk partisi fisik, atau perangkat COW khusus Android. Setelah perangkat dimulai ulang, data partisi dinamis digabungkan kembali ke perangkat dasarnya melalui penggunaan daemon dm-user dan snapuserd. Proses ini terjadi sepenuhnya di ruang pengguna.

Device-mapper

Device-mapper adalah lapisan blok virtual Linux yang sering digunakan di Android. Dengan partisi dinamis, partisi seperti /system adalah tumpukan perangkat berlapis:

  • Di bagian bawah stack adalah partisi super fisik (misalnya, /dev/block/by-name/super).
  • Di tengah adalah perangkat dm-linear, yang menentukan blok mana dalam superpartisi yang membentuk partisi dinamis yang diberikan. Ini akan muncul sebagai /dev/block/mapper/system_[a|b] di perangkat A/B, atau /dev/block/mapper/system di perangkat non-A/B.
  • Di bagian atas terdapat perangkat dm-verity, yang dibuat untuk partisi terverifikasi. Perangkat ini memverifikasi bahwa blok di perangkat dm-linear ditandatangani dengan benar. Tampilannya adalah /dev/block/mapper/system-verity dan merupakan sumber titik pemasangan /system.

Gambar 1 menunjukkan tampilan stack di bawah titik pemasangan /system.

Stacking partisi di bawah sistem

Gambar 1. Stack di bawah titik pemasangan /system

Snapshot terkompresi

Di Android 12 dan yang lebih baru, karena persyaratan ruang di partisi /data dapat tinggi, Anda dapat mengaktifkan snapshot terkompresi dalam build untuk mengatasi persyaratan ruang yang lebih tinggi dari partisi /data.

Ringkasan terkompresi A/B virtual dibuat berdasarkan komponen berikut yang tersedia di Android 12 dan yang lebih tinggi:

  • dm-user, modul kernel yang mirip dengan FUSE yang memungkinkan ruang pengguna menerapkan perangkat blok.
  • snapuserd, daemon ruang pengguna untuk menerapkan format snapshot baru.

Komponen ini mengaktifkan kompresi. Perubahan lain yang diperlukan untuk menerapkan kemampuan snapshot yang dikompresi diberikan di bagian berikutnya: Format COW untuk snapshot yang dikompresi, dm-user, dan snapuserd.

Format COW untuk snapshot yang dikompresi

Di Android 12 dan yang lebih baru, snapshot yang dikompresi menggunakan format COW khusus Android. Format COW berisi metadata tentang OTA dan memiliki buffering yang berbeda yang berisi operasi COW dan data sistem operasi baru. Dibandingkan dengan format snapshot kernel yang hanya mengizinkan operasi replace (Ganti blok X dalam image dasar dengan konten blok Y dalam snapshot), format COW snapshot terkompresi Android lebih ekspresif dan mendukung operasi berikut:

  • Salin: Blok X di perangkat dasar harus diganti dengan blok Y di perangkat dasar.
  • Replace: Blok X di perangkat dasar harus diganti dengan konten blok Y dalam snapshot. Setiap blok ini dikompresi gz.
  • Nol: Blok X di perangkat dasar harus diganti dengan semua nol.
  • XOR: Perangkat COW menyimpan byte yang dikompresi XOR antara blok X dan blok Y. (Tersedia di Android 13 dan yang lebih tinggi.)

Update OTA lengkap hanya terdiri dari operasi ganti dan nol. Update OTA inkremental juga dapat memiliki operasi salin.

Tata letak snapshot lengkap di disk terlihat seperti ini:

format sapi

Gambar 2. Format COW Android di Disk

dm-user

Modul kernel dm-user memungkinkan userspace menerapkan perangkat blok device-mapper. Entri tabel dm-user membuat perangkat lainnya di /dev/dm-user/<control-name>. Proses userspace dapat melakukan polling pada perangkat untuk menerima permintaan baca dan tulis dari kernel. Setiap permintaan memiliki buffering terkait untuk ruang pengguna agar diisi (untuk operasi baca) atau disebarkan (untuk operasi tulis).

Modul kernel dm-user menyediakan antarmuka baru yang terlihat pengguna ke kernel yang bukan bagian dari basis kode kernel.org upstream. Hingga saat itu, Google berhak mengubah antarmuka dm-user di Android.

snapuserd

Komponen ruang pengguna snapuserd ke dm-user mengimplementasikan kompresi A/B Virtual. Snapuserd adalah daemon ruang pengguna yang bertanggung jawab untuk menulis dan membaca perangkat COW Android. Semua I/O ke snapshot harus melalui layanan ini. Selama penginstalan OTA, data sistem operasi baru ditulis ke snapshot oleh snapuserd (dengan kompresi). Pemrosesan metadata dan unpacking data blok baru juga ditangani di sini.

Kompresi XOR

Untuk perangkat yang diluncurkan dengan Android 13 dan yang lebih baru, fitur kompresi XOR, yang diaktifkan secara default, memungkinkan snapshot ruang pengguna untuk menyimpan byte yang dikompresi XOR di antara blok lama dan blok baru. Jika hanya beberapa byte dalam blok yang diubah dalam update Virtual A/B, skema penyimpanan kompresi XOR akan menggunakan lebih sedikit ruang daripada skema penyimpanan default karena snapshot tidak menyimpan 4K byte penuh. Pengurangan ukuran snapshot ini mungkin karena data XOR berisi banyak nol dan lebih mudah dikompresi daripada data blok mentah. Di perangkat Pixel, kompresi XOR mengurangi ukuran snapshot sebesar 25% hingga 40%.

Untuk perangkat yang mengupgrade ke Android 13 dan yang lebih baru, kompresi XOR harus diaktifkan. Untuk mengetahui detailnya, lihat Kompresi XOR.

Penggabungan snapshot

Untuk perangkat yang diluncurkan dengan Android 13 dan yang lebih baru, proses snapshot dan penggabungan snapshot dalam kompresi Virtual A/B dilakukan oleh komponen ruang pengguna snapuserd. Untuk perangkat yang mengupgrade ke Android 13 dan yang lebih baru, fitur ini harus diaktifkan. Untuk mengetahui detailnya, lihat Penggabungan ruang pengguna.

Berikut ini penjelasan proses kompresi Virtual A/B:

  1. Framework ini memasang partisi /system dari perangkat dm-verity, yang ditumpuk di atas perangkat dm-user. Artinya, setiap I/O dari sistem file root dirutekan ke dm-user.
  2. dm-user merutekan I/O ke daemon snapuserd ruang pengguna, yang menangani permintaan I/O.
  3. Setelah operasi penggabungan selesai, framework akan menciutkan dm-verity di atas dm-linear (system_base) dan menghapus dm-user.

Proses kompresi A/B virtual

Gambar 3. Proses kompresi A/B virtual

Proses penggabungan snapshot dapat terganggu. Jika perangkat dimulai ulang selama proses penggabungan, proses penggabungan akan dilanjutkan setelah dimulai ulang.

Transisi init

Saat melakukan booting dengan snapshot yang dikompresi, init tahap pertama harus memulai snapuserd untuk memasang partisi. Hal ini menimbulkan masalah: Saat sepolicy dimuat dan diterapkan, snapuserd akan ditempatkan dalam konteks yang salah, dan permintaan bacanya akan gagal, dengan penolakan selinux.

Untuk mengatasi hal ini, snapuserd bertransisi secara serentak dengan init, sebagai berikut:

  1. init tahap pertama meluncurkan snapuserd dari ramdisk, dan menyimpan deskripsi file terbuka ke dalamnya dalam variabel lingkungan.
  2. init tahap pertama mengalihkan sistem file root ke partisi sistem, lalu mengeksekusi salinan sistem init.
  3. Salinan sistem init membaca sepolicy gabungan menjadi string.
  4. Init memanggil mlock() di semua halaman yang didukung ext4. Kemudian, semua tabel device-mapper untuk perangkat snapshot akan dinonaktifkan, dan snapuserd akan dihentikan. Setelah itu, Anda tidak boleh membaca dari partisi karena tindakan tersebut akan menyebabkan deadlock.
  5. Dengan menggunakan deskripsi terbuka ke salinan ramdisk snapuserd, init akan meluncurkan kembali daemon dengan konteks selinux yang benar. Tabel device-mapper untuk perangkat snapshot diaktifkan kembali.
  6. Init memanggil munlockall() - aman untuk melakukan IO lagi.

Penggunaan ruang

Tabel berikut memberikan perbandingan penggunaan ruang untuk berbagai mekanisme OTA menggunakan ukuran OS dan OTA Pixel.

Dampak Ukuran non-A/B A/B A/B Virtual Virtual A/B (dikompresi)
Gambar Pabrik Asli Super 4,5 GB (image 3,8 GB + 700 MB direservasi)1 9 GB super (3,8 GB + 700 MB dicadangkan, untuk dua slot) Super 4,5 GB (image 3,8 G + 700 M direservasi) Super 4,5 GB (image 3,8 G + 700 M dicadangkan)
Partisi statis lainnya /cache Tidak ada Tidak ada Tidak ada
Penyimpanan tambahan Selama OTA (ruang yang ditampilkan setelah menerapkan OTA) 1,4 GB di /data 0 3,8 GB2 di /data 2,1 GB2 di /data
Total penyimpanan yang diperlukan untuk menerapkan OTA 5,9 GB3 (super dan data) 9GB (super) 8,3 GB3 (super dan data) 6,6 GB3 (super dan data)

1Menunjukkan tata letak yang diasumsikan berdasarkan pemetaan Pixel.

2Menganggap image sistem baru berukuran sama dengan yang asli.

3Persyaratan ruang bersifat sementara hingga dimulai ulang.

A/B Virtual Android 11

Android 11 Virtual A/B menulis ke partisi dinamis menggunakan format COW Kernel. Hal ini pada akhirnya tidak digunakan lagi karena format COW Kernel tidak mendukung kompresi.

A/B Virtual Android 12

Di Android 12, kompresi didukung dalam bentuk format COW khusus Android. Versi Virtual A/B ini memerlukan terjemahan COW khusus Android ke format COW Kernel. Pada akhirnya, ini diganti di Android 13 yang menghapus ketergantungan pada format COW Kernel dan juga dm-snapshot.

Untuk menerapkan Virtual A/B, atau menggunakan kemampuan snapshot yang dikompresi, lihat Menerapkan Virtual A/B