Pilih patch berikut untuk mengatasi masalah umum berikut.
Memeriksa ruang yang dapat dialokasikan dengan benar saat sideloading
Sideloading paket OTA lengkap di perangkat Virtual A/B yang memiliki partisi super dengan ukuran lebih kecil dari *2 * sum(size of update groups)* mungkin gagal dengan pesan berikut dalam log pemulihan /tmp/recovery.log:
The maximum size of all groups with suffix _b (...) has exceeded half of allocatable space for dynamic partitions ...
Berikut adalah contoh log:
[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, buat ulang, dan flash partisi booting atau partisi pemulihan jika perangkat tidak menggunakan pemulihan sebagai booting.
Memperbaiki kesalahan segmentasi selama penggabungan
Setelah menerapkan update OTA, selama proses penggabungan VAB, panggilan ke update_engine_client --cancel menyebabkan CleanupPreviousUpdateAction mengalami error. Potensi error pointer liar juga ada saat markSlotSuccessful terlambat.
Masalah ini diatasi dengan menambahkan fungsi StopActionInternal.
CleanupPreviousUpdateAction membatalkan tugas yang tertunda saat penghancuran. Fungsi ini mempertahankan variabel yang melacak ID tugas dari tugas yang tertunda dalam loop pesan. Saat penghancuran, tugas yang tertunda dibatalkan untuk menghindari segfault.
Pastikan perubahan berikut ada di pohon sumber Android 11 Anda untuk memperbaiki error SIGSEGV di update_engine selama penggabungan:
- CL 1439792 (a prasyarat untuk CL 1439372)
- CL 1439372
(
CleanupPreviousUpdateAction: membatalkan tugas yang tertunda saat penghancuran) - CL 1663460 (memperbaiki
potensi error pointer liar saat
markSlotSuccessfulterlambat)
Mencegah penggabungan prematur update_engine
Saat perangkat melakukan booting (Android 11 dan yang lebih baru), dan booting selesai, update_engine memanggil ScheduleWaitMarkBootSuccessful(), dan WaitForMergeOrSchedule(). Tindakan ini memulai proses penggabungan. Namun, perangkat melakukan booting 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 (a prasyarat untuk CL 1439372)
- CL 1439372
(
CleanupPreviousUpdateAction: membatalkan tugas yang tertunda saat penghancuran) - CL 1663460 (memperbaiki
potensi error pointer liar saat
markSlotSuccessfulterlambat) - CL 1664859 (opsional -
tambahkan
unittestuntukCleanupPreviousUpdateAction)
Memastikan konfigurasi dm-verity yang benar
Di Android 11 dan yang lebih baru, perangkat dapat dikonfigurasi secara tidak sengaja dengan opsi dm-verity berikut:
CONFIG_DM_VERITY_AVB=ydi kernel- Bootloader dikonfigurasi untuk menggunakan mode verity apa pun, (seperti
AVB_HASHTREE_ERROR_MODE_RESTART_AND_INVALIDATE), tanpaAVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIO.
Dengan konfigurasi perangkat ini, error verity apa pun akan menyebabkan partisi vbmeta 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 verity AVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIO.
- Tetapkan
CONFIG_DM_VERITY_AVB=ndi kernel. - Konfigurasi perangkat untuk menggunakan mode
AVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIO.
Untuk mengetahui informasi selengkapnya, lihat dokumentasi verity: Menangani Error dm-verity.
Mengonfirmasi bahwa file gabungan dikonfigurasi dengan benar
Jika Anda membuat image sistem dan image vendor secara terpisah, lalu menggunakan merge_target_files untuk menggabungkannya, konfigurasi Virtual A/B mungkin akan salah dihilangkan selama proses penggabungan. Untuk memverifikasi bahwa konfigurasi Virtual A/B
sudah benar dalam file target gabungan, terapkan patch berikut: CL
2084183
(menggabungkan pasangan kunci/nilai yang identik dalam info partisi dinamis)
Memperbarui komponen yang diperlukan
Mulai Android 13, snapuserd telah dipindahkan dari ramdisk vendor ke ramdisk generik. Jika perangkat Anda diupgrade ke Android 13, ada kemungkinan ramdisk vendor dan ramdisk generik berisi salinan snapuserd. Dalam situasi ini, Virtual A/B memerlukan salinan sistem snapuserd. Untuk memastikan
salinan snapuserd yang benar ada, terapkan CL
2031243
(menyalin snapuserd ke first_stage_ramdisk).