وصله های A/B مجازی را پیاده سازی کنید

گیلاس وصله های زیر را برای رفع مشکلات شناخته شده زیر انتخاب کنید.

هنگام بارگذاری جانبی، فضای قابل تخصیص را به درستی بررسی کنید

بارگذاری جانبی یک بسته کامل OTA در یک دستگاه مجازی A/B که دارای یک پارتیشن فوق العاده با اندازه کوچکتر از *2 * مجموع (اندازه گروه های به روز رسانی)* است، ممکن است با موارد زیر در گزارش بازیابی /tmp/recovery.log شکست بخورد:

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

در اینجا یک نمونه از لاگ است:

[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.

اگر با این مشکل مواجه شدید، CL 1399393 را انتخاب کنید، دوباره بسازید و پارتیشن بوت یا پارتیشن بازیابی را فلش کنید اگر دستگاه از بازیابی به عنوان بوت استفاده نمی کند.

رفع خطای بخش بندی در حین ادغام

پس از اعمال به‌روزرسانی OTA، در طول فرآیند ادغام VAB، تماس با update_engine_client --cancel باعث از کار افتادن CleanupPreviousUpdateAction می‌شود. هنگامی که markSlotSuccessful دیر بیاید، یک خطای اشاره گر وحشی بالقوه نیز وجود دارد.

این با اضافه کردن تابع StopActionInternal حل شد. CleanupPreviousUpdateAction وظایف معلق در هنگام تخریب را لغو می کند. متغیری را حفظ می کند که شناسه وظیفه تکلیف معلق را در حلقه پیام ردیابی می کند. در هنگام نابودی، وظیفه معلق لغو می شود تا از خطای اشتباه جلوگیری شود.

برای رفع خرابی‌های SIGSEGV در update_engine در حین ادغام، اطمینان حاصل کنید که تغییرات زیر در درخت منبع Android 11 شما وجود دارد:

  • CL 1439792 (پیش نیاز CL 1439372)
  • CL 1439372 ( CleanupPreviousUpdateAction : لغو کارهای معلق در هنگام تخریب)
  • CL 1663460 (هنگامی که markSlotSuccessful دیر می آید، خطای اشاره گر وحشی احتمالی را برطرف کنید)

جلوگیری از ادغام پیش از موعد update_engine

هنگامی که دستگاهی بوت می شود (اندروید 11 و بالاتر)، و بوت کامل می شود، update_engine ScheduleWaitMarkBootSuccessful() و WaitForMergeOrSchedule() فرا می خواند. این فرآیند ادغام را شروع می کند. با این حال، دستگاه به اسلات قدیمی راه اندازی مجدد می شود. از آنجایی که ادغام از قبل شروع شده است، دستگاه بوت نمی شود و غیر قابل اجرا می شود.

تغییرات زیر را به درخت منبع خود اضافه کنید. توجه داشته باشید که CL 1664859 اختیاری است.

  • CL 1439792 (پیش نیاز CL 1439372)
  • CL 1439372 ( CleanupPreviousUpdateAction : لغو کارهای معلق در هنگام تخریب)
  • CL 1663460 (هنگامی که markSlotSuccessful دیر می آید، خطای اشاره گر وحشی احتمالی را برطرف کنید)
  • CL 1664859 (اختیاری - اضافه کردن unittest برای CleanupPreviousUpdateAction )

از پیکربندی صحیح dm-verity اطمینان حاصل کنید

در اندروید 11 و بالاتر، دستگاه‌ها را می‌توان ناخواسته با گزینه‌های dm-verity زیر پیکربندی کرد:

  • CONFIG_DM_VERITY_AVB=y در هسته
  • بوت لودر برای استفاده از هر حالت صحت (مانند AVB_HASHTREE_ERROR_MODE_RESTART_AND_INVALIDATE ) بدون AVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIO پیکربندی شده است.

با پیکربندی این دستگاه، هر گونه خطای صحت باعث خراب شدن پارتیشن vbmeta می شود و دستگاه های غیر A/B را غیرفعال می کند. به طور مشابه، اگر ادغام شروع شده باشد، ممکن است دستگاه‌های A/B نیز غیرفعال شوند. فقط از حالت صحت AVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIO استفاده کنید.

  1. CONFIG_DM_VERITY_AVB=n در هسته تنظیم کنید.
  2. دستگاه‌ها را برای استفاده از حالت AVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIO پیکربندی کنید.

برای اطلاعات بیشتر به مستندات صحت مراجعه کنید: مدیریت خطاهای dm-verity .

تأیید کنید که فایل ادغام شده به درستی پیکربندی شده است

اگر تصاویر سیستم و تصاویر فروشنده را جداگانه می‌سازید، سپس از merge_target_files برای ادغام آنها استفاده می‌کنید، ممکن است پیکربندی‌های A/B مجازی در طول فرآیند ادغام به اشتباه حذف شوند. برای تأیید درستی پیکربندی‌های A/B مجازی در فایل هدف ادغام‌شده، وصله‌های زیر را اعمال کنید: CL 2084183 (ادغام جفت‌های کلید/وال یکسان در اطلاعات پارتیشن پویا)

اجزای لازم را به روز کنید

از اندروید 13، snapuserd از ramdisk فروشنده به ramdisk عمومی منتقل شده است. اگر دستگاه شما در حال ارتقا به Android 13 است، ممکن است هر دو ramdisk فروشنده و ramdisk عمومی یک کپی از snapuserd داشته باشند. در این شرایط، Virtual A/B به کپی سیستم snapuserd نیاز دارد. برای اطمینان از اینکه کپی صحیح snapuserd در جای خود قرار دارد، CL 2031243 را اعمال کنید ( snapuserd در first_stage_ramdisk کپی کنید).