Pilih patch berikut untuk mengatasi masalah umum berikut.
Memeriksa ruang yang dapat dialokasikan dengan benar saat melakukan sideload
Melakukan sideload paket OTA lengkap di perangkat Virtual A/B yang memiliki superpartisi dengan ukuran lebih kecil dari *2 * sum(size of update groups)* dapat gagal
dengan menampilkan 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, bangun ulang, dan flash partisi boot atau partisi pemulihan jika perangkat tidak menggunakan pemulihan sebagai boot.
Memperbaiki kesalahan segmentasi selama penggabungan
Setelah menerapkan update OTA, selama proses penggabungan VAB, panggilan ke
update_engine_client --cancel
menyebabkan CleanupPreviousUpdateAction
error. Error pointer liar potensial juga ada saat markSlotSuccessful
terlambat.
Masalah ini diselesaikan dengan menambahkan fungsi StopActionInternal
.
CleanupPreviousUpdateAction
membatalkan tugas yang tertunda saat dihancurkan. 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 hierarki sumber Android 11 Anda untuk memperbaiki error SIGSEGV
di update_engine
selama penggabungan:
- CL 1439792 (prasyarat untuk CL 1439372)
- CL 1439372
(
CleanupPreviousUpdateAction
: batalkan tugas yang tertunda saat penghapusan) - CL 1663460 (memperbaiki potensi error pointer tidak valid saat
markSlotSuccessful
terlambat)
Mencegah penggabungan prematur update_engine
Saat perangkat melakukan booting (Android 11 dan yang lebih tinggi), dan booting selesai, update_engine
akan memanggil ScheduleWaitMarkBootSuccessful()
, dan
WaitForMergeOrSchedule()
. Tindakan ini akan memulai proses penggabungan. Namun, perangkat
di-reboot ke slot lama. Karena penggabungan sudah dimulai, perangkat gagal di-boot dan menjadi tidak dapat dioperasikan.
Tambahkan perubahan berikut ke hierarki sumber Anda. Perhatikan bahwa CL 1664859 bersifat opsional.
- CL 1439792 (prasyarat untuk CL 1439372)
- CL 1439372
(
CleanupPreviousUpdateAction
: batalkan tugas yang tertunda saat penghapusan) - CL 1663460 (memperbaiki potensi error pointer tidak valid saat
markSlotSuccessful
terlambat) - CL 1664859 (opsional -
tambahkan
unittest
untukCleanupPreviousUpdateAction
)
Memastikan konfigurasi dm-verity yang benar
Di Android 11 dan yang 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 verity apa pun, (seperti
AVB_HASHTREE_ERROR_MODE_RESTART_AND_INVALIDATE
), tanpaAVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIO
.
Dengan konfigurasi perangkat ini, setiap error verity menyebabkan partisi vbmeta menjadi rusak, dan membuat perangkat non-A/B tidak dapat dioperasikan. Demikian pula, jika penggabungan
telah dimulai, perangkat A/B juga mungkin tidak dapat dioperasikan. Hanya gunakan mode verifikasi
AVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIO
.
- Tetapkan
CONFIG_DM_VERITY_AVB=n
di 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.
Pastikan file gabungan dikonfigurasi dengan benar
Jika Anda membuat image sistem dan image vendor secara terpisah, lalu menggunakan
merge_target_files
untuk menggabungkannya, konfigurasi A/B Virtual mungkin
dihapus secara tidak benar selama proses penggabungan. Untuk memverifikasi bahwa konfigurasi Virtual A/B sudah benar dalam file target gabungan, terapkan patch berikut: CL 2084183 (gabungkan pasangan key/val 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 bahwa
vendor ramdisk dan ramdisk generik berisi salinan snapuserd
. Dalam situasi ini, A/B Virtual memerlukan salinan sistem snapuserd
. Untuk memastikan salinan snapuserd
yang benar sudah ada, terapkan CL
2031243
(salin snapuserd
ke first_stage_ramdisk).