قم باختيار التصحيحات التالية لمعالجة المشكلات المعروفة التالية.
تحقق من المساحة القابلة للتخصيص بشكل صحيح عند التحميل الجانبي
قد يفشل التحميل الجانبي لحزمة OTA كاملة على جهاز Virtual 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 بإلغاء المهام المعلقة عند التدمير. ويحتفظ بمتغير يتتبع معرف المهمة للمهمة المعلقة في حلقة الرسالة. عند التدمير، يتم إلغاء المهمة المعلقة لتجنب التقسيم.
تأكد من وجود التغييرات التالية في شجرة مصدر Android 11 لديك لإصلاح أعطال SIGSEGV في update_engine أثناء الدمج:
- CL 1439792 (متطلب أساسي لـ CL 1439372)
- CL 1439372 (
CleanupPreviousUpdateAction: إلغاء المهام المعلقة عند التدمير) - CL 1663460 (إصلاح خطأ المؤشر البري المحتمل عندما يأتي
markSlotSuccessfulمتأخرًا)
إصلاح تبديل الفتحات غير الصحيح لـ VAB، ونشر تحديث عبر الهواء
في نظام التشغيل Android 11 والإصدارات الأحدث، قد يؤدي الفشل في مزامنة مفتاح الفتحة في الجهاز بعد تحديث OTA إلى وضع الجهاز في حالة غير قابلة للاستخدام. إذا كان تطبيق تبديل الفتحات الخاص بـ IBootControl HAL يقوم بالكتابة، فيجب عليك مسح عمليات الكتابة هذه على الفور. إذا لم يتم مسح عمليات الكتابة، وتمت إعادة تشغيل الجهاز بعد بدء الدمج، ولكن قبل أن يتمكن الجهاز من مسح كتابة مفتاح الفتحة، فقد يعود الجهاز إلى الفتحة السابقة ويفشل في التمهيد.
للحصول على مثال لحل التعليمات البرمجية، قم بعرض CL: CL 1535570 .
منع الدمج المبكر لمحرك التحديث
عندما يقوم جهاز ما بالتمهيد (Android 11 والإصدارات الأحدث)، ويكتمل التمهيد، يستدعي update_engine جدولة ScheduleWaitMarkBootSuccessful() و WaitForMergeOrSchedule() . يؤدي هذا إلى بدء عملية الدمج. ومع ذلك، يتم إعادة تشغيل الجهاز إلى الفتحة القديمة. نظرًا لأن عملية الدمج قد بدأت بالفعل، يفشل الجهاز في التمهيد ويصبح غير قابل للعمل.
أضف التغييرات التالية إلى شجرة المصدر الخاصة بك. لاحظ أن CL 1664859 اختياري.
- CL 1439792 (متطلب أساسي لـ CL 1439372)
- CL 1439372 (
CleanupPreviousUpdateAction: إلغاء المهام المعلقة عند التدمير) - CL 1663460 (إصلاح خطأ المؤشر البري المحتمل عندما يأتي
markSlotSuccessfulمتأخرًا) - CL 1664859 (اختياري - أضف
unittestلـCleanupPreviousUpdateAction)
منع فقدان البيانات أو تلفها بسبب البيانات التعريفية التي تم تخطيها
في Android 11 والإصدارات الأحدث، إذا كان جهاز التخزين يحتوي على ذاكرة تخزين مؤقت متقلبة للكتابة مرة أخرى، في ظل ظروف معينة، يتم تخطي البيانات التعريفية للدمج المكتمل، مما يؤدي إلى فقدان البيانات أو تلفها.
شروط:
- بعد الانتهاء من عملية دمج مجموعة واحدة من الاستثناءات، تم استدعاء
merge_callback(). - تم تحديث بيانات التعريف في جهاز COW الذي يتتبع اكتمال الدمج. (تم مسح هذا التحديث لجهاز COW بشكل نظيف.)
النتيجة: تعطل النظام بسبب عدم مسح ذاكرة التخزين المؤقت لجهاز التخزين الخاصة بالدمج الأخير.
راجع ما يلي لتنفيذ القرار:
تأكد من تكوين 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.
باستخدام تكوين الجهاز هذا، يؤدي أي خطأ حقيقي إلى تلف قسم vbmeta، ويجعل الأجهزة غير A/B غير قابلة للعمل. وبالمثل، إذا بدأت عملية الدمج، فقد تصبح أجهزة A/B أيضًا غير قابلة للتشغيل. استخدم فقط وضع التحقق AVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIO .
- قم بتعيين
CONFIG_DM_VERITY_AVB=nفي النواة - قم بتكوين الأجهزة لاستخدام وضع
AVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIOبدلاً من ذلك.
لمزيد من المعلومات، وعلى سبيل الممارسة، راجع وثائق التحقق: التعامل مع أخطاء dm-verity .
تخطي العمل الحقيقي استجابةً لخطأ الإدخال/الإخراج أثناء إيقاف تشغيل النظام في حالات الطوارئ
في نظام التشغيل Android 11 والإصدارات الأحدث، إذا تم استدعاء إيقاف تشغيل النظام في حالات الطوارئ (كما في حالة إيقاف التشغيل الحراري)، فيمكن أن يكون جهاز dm على قيد الحياة بينما لا يتمكن جهاز الحظر من معالجة طلبات الإدخال/الإخراج بعد الآن. في هذه الحالة، يمكن أن تؤدي أخطاء الإدخال/الإخراج التي تتم معالجتها بواسطة طلبات الإدخال/الإخراج الجديدة dm، أو تلك الموجودة بالفعل، إلى حالة تلف حقيقي، وهو ما يعتبر سوء تقدير.
لتخطي عمل الحقيقة استجابة لخطأ الإدخال/الإخراج عند إيقاف تشغيل النظام، استخدم ما يلي:
CL 1847875 (تخطي عمل الحقيقة استجابةً لخطأ الإدخال/الإخراج أثناء إيقاف التشغيل)
تأكد من إيقاف تشغيل DM_ANDROID_VERITY_AT_MOST_ONCE_DEFAULT_ENABLED
قد تحتوي أجهزة Android Go التي تعمل بالإصدار 4.19 kernel أو الإصدارات الأقدم على DM_ANDROID_VERITY_AT_MOST_ONCE_DEFAULT_ENABLED=y في تكوين kernel الخاص بها. هذا الإعداد غير متوافق مع Virtual A/B، ومن المعروف أنه يسبب مشكلات نادرة في تلف الصفحة عندما يتم تمكينهما معًا.
بالنسبة للنواة 4.19 والإصدارات الأقدم، قم بتعطيلها عن طريق تعيين CONFIG_DM_ANDROID_VERITY_AT_MOST_ONCE_DEFAULT_ENABLED=n في تكوين kernel.
بالنسبة للنواة 5.4 والإصدارات الأحدث، تمت إزالة الكود ولم يعد خيار التكوين متاحًا.
تأكد من تكوين الملف المدمج بشكل صحيح
إذا كنت تقوم بإنشاء صور النظام وصور البائعين بشكل منفصل، ثم تستخدم merge_target_files لدمجها، فقد يتم إسقاط تكوينات A/B الافتراضية بشكل غير صحيح أثناء عملية الدمج. للتحقق من صحة تكوينات A/B الافتراضية في الملف الهدف المدمج، قم بتطبيق التصحيحات التالية: CL 2084183 (دمج أزواج المفاتيح/القيم المتماثلة في معلومات القسم الديناميكي)
تحديث المكونات الضرورية
اعتبارًا من Android 13، تم نقل snapuserd من قرص ذاكرة الوصول العشوائي الخاص بالمورد إلى قرص ذاكرة الوصول العشوائي العام. إذا كان جهازك يقوم بالترقية إلى Android 13، فمن الممكن أن يحتوي كل من ramdisk المورّد وramdisk العام على نسخة من snapuserd . في هذه الحالة، يتطلب Virtual A/B نسخة النظام من snapuserd . للتأكد من وجود النسخة الصحيحة من snapuserd ، قم بتطبيق CL 2031243 (انسخ snapuserd إلى first_stage_ramdisk).