वर्चुअल A/B - पैच लागू करना

इन समस्याओं को ठीक करने के लिए, यहां दिए गए पैच चुनें.

साइडलोडिंग करते समय, असाइन की जा सकने वाली जगह की सही तरीके से जांच करना

अगर वर्चुअल 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 को चुनें, फिर से बनाएं, और बूट पार्टीशन को फ़्लैश करें. अगर डिवाइस बूट के तौर पर रिकवरी का इस्तेमाल नहीं करता है, तो रिकवरी पार्टीशन को फ़्लैश करें.

मर्ज करने के दौरान सेगमेंटेशन फ़ॉल्ट को ठीक किया गया

ओटीए अपडेट लागू करने के बाद, वीएबी मर्ज करने की प्रोसेस के दौरान, update_engine_client --cancel को कॉल करने पर CleanupPreviousUpdateAction क्रैश हो जाता है. markSlotSuccessful देर से आने पर, वाइल्ड पॉइंटर से जुड़ी गड़बड़ी भी हो सकती है.

StopActionInternal फ़ंक्शन जोड़कर, इस समस्या को हल कर दिया गया है. CleanupPreviousUpdateAction, डिस्ट्रॉय होने पर लंबित टास्क रद्द कर देता है. यह एक ऐसा वैरिएबल बनाए रखती है जो मैसेज लूप में मौजूद, बाकी काम के टास्क आईडी को ट्रैक करता है. destroy होने पर, सेगफ़ॉल्ट से बचने के लिए बाकी काम रद्द कर दिया जाता है.

मर्ज करने के दौरान update_engine में क्रैश की समस्या ठीक करने के लिए, पक्का करें कि Android 11 के सोर्स ट्री में ये बदलाव किए गए हों: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 वेरिटी मोड का इस्तेमाल करें.

1. कर्नल में CONFIG_DM_VERITY_AVB=n सेट करें.
2. डिवाइसों को AVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIO मोड का इस्तेमाल करने के लिए कॉन्फ़िगर करें.

ज़्यादा जानकारी के लिए, Verity का दस्तावेज़ देखें: dm-verity से जुड़ी गड़बड़ियों को ठीक करना.

पुष्टि करें कि मर्ज की गई फ़ाइल सही तरीके से कॉन्फ़िगर की गई है

अगर सिस्टम इमेज और वेंडर इमेज को अलग-अलग बनाया जा रहा है, तो उन्हें मर्ज करने के लिए merge_target_files का इस्तेमाल करने पर, मर्ज करने की प्रोसेस के दौरान वर्चुअल A/B कॉन्फ़िगरेशन गलत तरीके से हटाए जा सकते हैं. यह पुष्टि करने के लिए कि मर्ज की गई टारगेट फ़ाइल में वर्चुअल ए/बी कॉन्फ़िगरेशन सही हैं, ये पैच लागू करें: CL 2084183 (डाइनैमिक पार्टीशन की जानकारी में एक जैसे कुंजी/वैल्यू पेयर मर्ज करें)

ज़रूरी कॉम्पोनेंट अपडेट करना

Android 13 से, snapuserd को वेंडर रैमडिस्क से सामान्य रैमडिस्क में ले जाया गया है. अगर आपके डिवाइस को Android 13 पर अपग्रेड किया जा रहा है, तो हो सकता है कि वेंडर रैमडिस्क और सामान्य रैमडिस्क, दोनों में snapuserd की कॉपी मौजूद हो. इस स्थिति में, वर्चुअल ए/बी टेस्टिंग के लिए snapuserd की सिस्टम कॉपी की ज़रूरत होती है. यह पक्का करने के लिए कि snapuserd की सही कॉपी मौजूद है, CL 2031243 लागू करें (snapuserd को first_stage_ramdisk में कॉपी करें).