Menerapkan Virtual A/B - patch

Pilih patch berikut untuk mengatasi masalah umum berikut.

Periksa ruang yang dapat dialokasikan dengan benar saat melakukan sideload

Mengesampingkan paket OTA lengkap pada perangkat Virtual A/B yang memiliki partisi super dengan ukuran lebih kecil dari *2 * jumlah(ukuran grup pembaruan)* mungkin gagal dengan yang berikut ini di log pemulihan /tmp/recovery.log :

The maximum size of all groups with suffix _b (...) has exceeded half of allocatable space for dynamic partitions ...

Berikut ini contoh lognya:

[INFO:dynamic_partition_control_android.cc(1020)] Will overwrite existing partitions. Slot A may be unbootable until update finishes!
[...]
[ERROR:dynamic_partition_control_android.cc(803)] The maximum size of all groups with suffix _b (2147483648) has exceeded half of allocatable space for dynamic partitions 1073741824.

Jika Anda mengalami masalah ini, pilih CL 1399393 , bangun kembali, dan flash partisi boot atau partisi pemulihan jika perangkat tidak menggunakan pemulihan sebagai boot.

Perbaiki kesalahan segmentasi selama penggabungan

Setelah menerapkan pembaruan OTA, selama proses penggabungan VAB, panggilan ke update_engine_client --cancel menyebabkan CleanupPreviousUpdateAction terhenti. Potensi kesalahan penunjuk liar juga terjadi ketika markSlotSuccessful datang terlambat.

Masalah ini diatasi dengan menambahkan fungsi StopActionInternal . CleanupPreviousUpdateAction membatalkan tugas yang tertunda saat penghancuran. Ia memelihara variabel yang melacak ID tugas dari tugas yang tertunda dalam loop pesan. Saat dihancurkan, tugas yang tertunda dibatalkan untuk menghindari segfault.

Pastikan perubahan berikut ada di pohon sumber Android 11 Anda untuk memperbaiki kerusakan SIGSEGV di update_engine selama penggabungan:

  • CL 1439792 (persyaratan untuk CL 1439372)
  • CL 1439372 ( CleanupPreviousUpdateAction : membatalkan tugas yang tertunda saat penghancuran)
  • CL 1663460 (memperbaiki potensi kesalahan penunjuk liar ketika markSlotSuccessful datang terlambat)

Perbaiki peralihan slot VAB yang salah, pasca pembaruan OTA

Di Android 11 dan lebih tinggi, kegagalan menyinkronkan sakelar slot di perangkat setelah pembaruan OTA dapat membuat perangkat tidak dapat digunakan. Jika implementasi peralihan slot IBootControl HAL Anda melakukan penulisan, Anda harus segera menghapus penulisan tersebut. Jika penulisan tidak dihapus, dan perangkat melakukan boot ulang setelah penggabungan dimulai, namun sebelum perangkat keras dapat menghapus penulisan sakelar slot, perangkat dapat kembali ke slot sebelumnya dan gagal melakukan booting.

Untuk contoh solusi kode, lihat CL ini: CL 1535570 .

Cegah penggabungan prematur update_engine

Saat perangkat melakukan booting (Android 11 dan lebih tinggi), dan booting selesai, update_engine akan memanggil ScheduleWaitMarkBootSuccessful() , dan WaitForMergeOrSchedule() . Ini memulai proses penggabungan. Namun, perangkat melakukan boot ulang ke slot lama. Karena penggabungan sudah dimulai, perangkat gagal melakukan booting dan tidak dapat dioperasikan.

Tambahkan perubahan berikut ke pohon sumber Anda. Perhatikan bahwa CL 1664859 bersifat opsional.

  • CL 1439792 (persyaratan untuk CL 1439372)
  • CL 1439372 ( CleanupPreviousUpdateAction : membatalkan tugas yang tertunda saat penghancuran)
  • CL 1663460 (memperbaiki potensi kesalahan penunjuk liar ketika markSlotSuccessful datang terlambat)
  • CL 1664859 (opsional - tambahkan unittest untuk CleanupPreviousUpdateAction )

Mencegah kehilangan atau kerusakan data karena metadata yang dilewati

Di Android 11 dan yang lebih tinggi, jika perangkat penyimpanan memiliki cache tulis kembali yang mudah menguap, dalam kondisi tertentu, metadata penggabungan yang telah selesai akan dilewati, sehingga mengakibatkan kehilangan atau kerusakan data.

Kondisi:

  1. Setelah menyelesaikan operasi penggabungan satu set pengecualian, merge_callback() dipanggil.
  2. Metadata telah diperbarui di perangkat COW yang melacak penyelesaian penggabungan. (Pembaruan pada perangkat COW ini telah dihapus dengan bersih.)

Hasil: Sistem mogok karena cache perangkat penyimpanan penggabungan baru-baru ini tidak dihapus.

Lihat hal berikut untuk menerapkan resolusi:

Pastikan konfigurasi dm-verity benar

Di Android 11 dan lebih tinggi, perangkat dapat dikonfigurasi secara tidak sengaja dengan opsi dm-verity berikut:

  • CONFIG_DM_VERITY_AVB=y di kernel
  • Bootloader dikonfigurasi untuk menggunakan mode kebenaran apa pun, (seperti AVB_HASHTREE_ERROR_MODE_RESTART_AND_INVALIDATE ), tanpa AVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIO .

Dengan konfigurasi perangkat ini, kesalahan kebenaran apa pun menyebabkan partisi vbmeta menjadi rusak, dan membuat perangkat non-A/B tidak dapat dioperasikan. Demikian pula, jika penggabungan telah dimulai, perangkat A/B mungkin juga tidak dapat dioperasikan. Hanya gunakan mode kebenaran AVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIO .

  1. Setel CONFIG_DM_VERITY_AVB=n di kernel
  2. Konfigurasikan perangkat untuk menggunakan mode AVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIO .

Untuk informasi lebih lanjut, dan sebagai bahan praktik, rujuk dokumentasi kebenaran: Menangani Kesalahan dm-verity .

Lewati pekerjaan kebenaran sebagai respons terhadap kesalahan I/O selama pematian sistem darurat

Di Android 11 dan yang lebih tinggi, jika penghentian sistem darurat dilakukan (seperti dalam kasus pematian termal), perangkat dm dapat hidup sementara perangkat blok tidak dapat lagi memproses permintaan I/O. Dalam keadaan ini, kesalahan I/O yang ditangani oleh permintaan I/O dm baru, atau oleh permintaan yang sudah ada dalam penerbangan, dapat menyebabkan keadaan korupsi kebenaran, yang merupakan kesalahan penilaian.

Untuk melewati pekerjaan verifikasi sebagai respons terhadap kesalahan I/O saat sistem dimatikan, gunakan yang berikut ini:

CL 1847875 (Melewati pekerjaan kebenaran sebagai respons terhadap kesalahan I/O selama pematian)

Pastikan DM_ANDROID_VERITY_AT_MOST_ONCE_DEFAULT_ENABLED nonaktif

Perangkat Android Go yang menjalankan kernel 4.19 atau versi lebih lama mungkin memiliki DM_ANDROID_VERITY_AT_MOST_ONCE_DEFAULT_ENABLED=y dalam konfigurasi kernelnya. Pengaturan ini tidak kompatibel dengan Virtual A/B, dan diketahui menyebabkan masalah kerusakan halaman yang jarang terjadi ketika keduanya diaktifkan bersamaan.

Untuk kernel 4.19 dan yang lebih lama, nonaktifkan dengan mengatur CONFIG_DM_ANDROID_VERITY_AT_MOST_ONCE_DEFAULT_ENABLED=n di konfigurasi kernel.

Untuk kernel 5.4 dan yang lebih baru, kode telah dihapus dan opsi konfigurasi tidak tersedia.

Konfirmasikan bahwa file yang digabungkan telah dikonfigurasi dengan benar

Jika Anda membuat citra sistem dan citra vendor secara terpisah, lalu menggunakan merge_target_files untuk menggabungkannya, konfigurasi Virtual A/B mungkin salah dihilangkan selama proses penggabungan. Untuk memverifikasi bahwa konfigurasi Virtual A/B sudah benar dalam file target gabungan, terapkan patch berikut: CL 2084183 (gabungkan pasangan kunci/val identik dalam info partisi dinamis)

Perbarui komponen yang diperlukan

Mulai Android 13, snapuserd telah dipindahkan dari vendor ramdisk ke ramdisk generik. Jika perangkat Anda diupgrade ke Android 13, kemungkinan vendor ramdisk dan ramdisk generik berisi salinan snapuserd . Dalam situasi ini, Virtual A/B memerlukan salinan sistem snapuserd . Untuk memastikan bahwa salinan snapuserd yang benar sudah ada, terapkan CL 2031243 (salin snapuserd ke first_stage_ramdisk).