इन समस्याओं को ठीक करने के लिए, यहां दिए गए पैच को चुनें.
साइडलोडिंग करते समय, असाइन की जा सकने वाली जगह की सही तरीके से जांच करना
वर्चुअल A/B डिवाइस पर पूरा OTA पैकेज साइडलोड करने पर, यह काम नहीं कर सकता. ऐसा तब होता है, जब सुपरपार्टिशन का साइज़ *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 को चुनें, फिर से बनाएं, और बूट पार्टीशन या रिकवरी पार्टीशन को फ़्लैश करें. ऐसा तब करें, जब डिवाइस बूट के तौर पर रिकवरी का इस्तेमाल न करता हो.
मर्ज करने के दौरान सेगमेंटेशन फ़ॉल्ट ठीक करना
ओटीए अपडेट लागू करने के बाद, वीएबी मर्ज करने की प्रोसेस के दौरान, update_engine_client --cancel को कॉल करने पर CleanupPreviousUpdateAction क्रैश हो जाता है. markSlotSuccessful देर से आने पर, वाइल्ड पॉइंटर से जुड़ी गड़बड़ी भी हो सकती है.
इस समस्या को StopActionInternal फ़ंक्शन जोड़कर हल किया गया.
CleanupPreviousUpdateAction डिस्ट्रॉय होने पर, पूरे नहीं किए गए टास्क रद्द कर देता है. यह एक ऐसा वैरिएबल बनाए रखता है जो मैसेज लूप में, पूरे किए जाने बाकी टास्क के आईडी को ट्रैक करता है. destroy होने पर, सेगफ़ॉल्ट से बचने के लिए, पेंडिंग टास्क रद्द कर दिया जाता है.
यह पक्का करें कि Android 11 के सोर्स ट्री में ये बदलाव किए गए हों, ताकि मर्ज करने के दौरान update_engine में होने वाली क्रैश की समस्याओं को ठीक किया जा सके:SIGSEGV
- CL 1439792 (CL 1439372 के लिए ज़रूरी है)
- CL 1439372
(
CleanupPreviousUpdateAction: cancel pending tasks on destroy) - CL 1663460 (जब
markSlotSuccessfulदेर से आता है, तब वाइल्ड पॉइंटर से जुड़ी संभावित गड़बड़ी को ठीक करता है)
Prevent update_engine premature merge
जब कोई डिवाइस बूट होता है (Android 11 और इसके बाद के वर्शन), और बूट पूरा हो जाता है, तो update_engine, ScheduleWaitMarkBootSuccessful(), और WaitForMergeOrSchedule() को कॉल करता है. इससे मर्ज करने की प्रोसेस शुरू हो जाती है. हालांकि, डिवाइस पुराने स्लॉट पर रीबूट हो जाता है. मर्ज करने की प्रोसेस पहले ही शुरू हो चुकी है. इसलिए, डिवाइस बूट नहीं हो पाता और काम नहीं करता.
अपने सोर्स ट्री में ये बदलाव जोड़ें. ध्यान दें कि CL 1664859 का इस्तेमाल करना ज़रूरी नहीं है.
- CL 1439792 (CL 1439372 के लिए ज़रूरी है)
- CL 1439372
(
CleanupPreviousUpdateAction: cancel pending tasks on destroy) - CL 1663460 (जब
markSlotSuccessfulदेर से आता है, तब वाइल्ड पॉइंटर से जुड़ी संभावित गड़बड़ी को ठीक करता है) - CL 1664859 (ज़रूरी नहीं -
CleanupPreviousUpdateActionके लिएunittestजोड़ें)
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मोड का इस्तेमाल करने के लिए कॉन्फ़िगर करें.
ज़्यादा जानकारी के लिए, Verity का दस्तावेज़ देखें: dm-verity से जुड़ी गड़बड़ियों को ठीक करना.
पुष्टि करें कि मर्ज की गई फ़ाइल सही तरीके से कॉन्फ़िगर की गई है
अगर सिस्टम इमेज और वेंडर इमेज अलग-अलग बनाई जा रही हैं, तो उन्हें मर्ज करने के लिए merge_target_files का इस्तेमाल करने पर, मर्ज करने की प्रोसेस के दौरान वर्चुअल A/B कॉन्फ़िगरेशन गलत तरीके से हटाए जा सकते हैं. यह पुष्टि करने के लिए कि मर्ज की गई टारगेट फ़ाइल में वर्चुअल A/B कॉन्फ़िगरेशन सही हैं, ये पैच लागू करें: CL 2084183 (डाइनैमिक पार्टीशन की जानकारी में एक जैसे कुंजी/वैल्यू पेयर मर्ज करें)
ज़रूरी कॉम्पोनेंट अपडेट करना
Android 13 से, snapuserd को वेंडर रैमडिस्क से सामान्य रैमडिस्क में ले जाया गया है. अगर आपके डिवाइस को Android 13 पर अपग्रेड किया जा रहा है, तो हो सकता है कि वेंडर रैमडिस्क और सामान्य रैमडिस्क, दोनों में snapuserd की कॉपी मौजूद हो. इस स्थिति में, वर्चुअल ए/बी टेस्टिंग के लिए snapuserd की सिस्टम कॉपी की ज़रूरत होती है. यह पक्का करने के लिए कि snapuserd की सही कॉपी मौजूद है, CL
2031243
लागू करें (snapuserd को first_stage_ramdisk में कॉपी करें).