وصله های 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 دیر می آید، خطای اشاره گر وحشی احتمالی را برطرف کنید)

تصحیح VAB سوئیچینگ اسلات نادرست، پس از به روز رسانی OTA

در اندروید 11 و بالاتر، عدم همگام‌سازی سوئیچ اسلات در دستگاه پس از به‌روزرسانی OTA می‌تواند دستگاه را در حالت غیرقابل استفاده قرار دهد. اگر پیاده سازی Slot-switching در IBootControl HAL شما نوشتن را انجام می دهد، باید فوراً آن نوشته ها را شستشو دهید. اگر نوشته‌ها فلاش نشده باشند، و دستگاه پس از شروع ادغام راه‌اندازی مجدد شود، اما قبل از اینکه سخت‌افزار بتواند نوشته سوئیچ اسلات را پاک کند، ممکن است دستگاه به اسلات قبلی برگردد و راه‌اندازی نشود.

برای مثال راه حل کد، این CL را مشاهده کنید: CL 1535570 .

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

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

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

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

جلوگیری از از دست دادن داده یا خراب شدن به دلیل نادیده گرفته شدن ابرداده

در Android 11 و بالاتر، اگر یک دستگاه ذخیره‌سازی حافظه پنهان بازگشت فرار فرار داشته باشد، تحت شرایط خاص، ابرداده یک ادغام کامل حذف می‌شود و منجر به از دست رفتن داده یا خرابی می‌شود.

شرایط:

1. پس از اتمام عملیات ادغام یک مجموعه از استثناها، merge_callback() فراخوانی شد.
2. فراداده در دستگاه COW که تکمیل ادغام را ردیابی می کند، به روز شد. (این به روز رسانی دستگاه COW به طور تمیز پاک می شود.)

نتیجه: به دلیل پاک نشدن حافظه پنهان دستگاه ذخیره سازی ادغام اخیر، سیستم از کار افتاد.

برای اجرای قطعنامه به موارد زیر مراجعه کنید:

• قبل از انجام فراداده، داده های ادغام شده را شستشو دهید

از پیکربندی صحیح 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 .

در پاسخ به خطای ورودی/خروجی در حین خاموش شدن سیستم اضطراری، از کار راستی رد شوید

در اندروید 11 و بالاتر، اگر خاموشی سیستم اضطراری فراخوانی شود (مانند خاموش شدن حرارتی)، یک دستگاه dm می‌تواند زنده باشد در حالی که دستگاه بلوک دیگر نمی‌تواند درخواست‌های ورودی/خروجی را پردازش کند. در این حالت، خطاهای ورودی/خروجی که توسط درخواست‌های ورودی/خروجی dm جدید، یا توسط آنهایی که قبلاً در حال پرواز هستند، مدیریت می‌شوند، می‌توانند منجر به یک وضعیت فساد واقعی شوند، که یک قضاوت نادرست است.

برای رد شدن از کار درستی در پاسخ به خطای I/O هنگام خاموش شدن سیستم، از موارد زیر استفاده کنید:

CL 1847875 (در پاسخ به خطای ورودی/خروجی در حین خاموش شدن از کار راستی رد می‌شود)

مطمئن شوید DM_ANDROID_VERITY_AT_MOST_ONCE_DEFAULT_ENABLED خاموش است

دستگاه‌های Android Go دارای هسته 4.19 یا نسخه‌های قبلی ممکن است DM_ANDROID_VERITY_AT_MOST_ONCE_DEFAULT_ENABLED=y در پیکربندی هسته خود داشته باشند. این تنظیم با Virtual A/B سازگار نیست، و زمانی که هر دو با هم فعال هستند، مشکلات نادر خرابی صفحه را ایجاد می‌کند.

برای هسته‌های 4.19 و نسخه‌های قبلی، با تنظیم CONFIG_DM_ANDROID_VERITY_AT_MOST_ONCE_DEFAULT_ENABLED=n در پیکربندی هسته، آن را غیرفعال کنید.

برای هسته های 5.4 و بالاتر، کد حذف شده است و گزینه پیکربندی در دسترس نیست.

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

اگر تصاویر سیستم و تصاویر فروشنده را جداگانه می‌سازید، سپس از 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 کپی کنید).