پیاده‌سازی آزمایش A/B مجازی - وصله‌ها

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

بررسی صحیح فضای قابل‌تخصیص هنگام بارگیری جانبی

بارگذاری جانبی بسته کامل OTA در دستگاه مجازی A/B که دارای پارتیشن فوق‌العاده با اندازه کوچک‌تر از *2 * sum(size of update groups)* است ممکن است با خطای زیر در گزارش بازیابی /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 تکالیف معلقه را درصورت ازبین رفتن لغو می‌کند. متغیری را حفظ می‌کند که شناسه تکلیف تکلیف معلقه را در حلقه پیام پیگیری می‌کند. در destroy، تکلیف معلقه برای جلوگیری از خطای تقسیم‌بندی لغو می‌شود.

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

  • CL 1439792 (پیش‌نیاز CL 1439372)
  • CL 1439372 (CleanupPreviousUpdateAction: cancel pending tasks on destroy)
  • CL 1663460 (رفع خطای احتمالی اشاره‌گر وحشی وقتی markSlotSuccessful دیر می‌آید)

جلوگیری از ادغام زودرس update_engine

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

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

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

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

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

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

با این پیکربندی دستگاه، هرگونه خطای verity باعث می‌شود پارتیشن 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 استفاده کنند.

برای اطلاعات بیشتر، به مستندات verity مراجعه کنید: Handling dm-verity Errors.

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

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

به‌روزرسانی اجزای ضروری

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