وصله های 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 با تأخیر اجرا شود، احتمال خطای wild pointer وجود دارد.

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

مطمئن شوید که تغییرات زیر در درخت منبع اندروید ۱۱ شما وجود دارد تا مشکلات SIGSEGV در update_engine هنگام ادغام برطرف شود:

  • CL 1439792 (پیش‌نیاز CL 1439372)
  • CL 1439372 ( CleanupPreviousUpdateAction : لغو وظایف در حال انتظار هنگام تخریب)
  • CL 1663460 (رفع خطای احتمالی اشاره‌گر wild هنگام دیر رسیدن markSlotSuccessful )

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

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

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

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

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

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

  • CONFIG_DM_VERITY_AVB=y در هسته
  • بوت‌لودر طوری پیکربندی شده است که از هر حالت راستی‌آزمایی (verity mode) (مانند 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 استفاده کنند.

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

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

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

به‌روزرسانی اجزای لازم

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