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

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

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

किसी वर्चुअल A/B डिवाइस पर पूरा OTA पैकेज साइडलोड करने पर, ऐसा हो सकता है कि वह काम न करे. ऐसा तब होता है, जब डिवाइस का सुपर पार्टिशन, *2 * sum(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 को चुनें. इसके बाद, बूट पार्टिशन या रिकवरी पार्टिशन को फिर से बनाएं और फ़्लैश करें. ऐसा तब करें, जब डिवाइस रिकवरी को बूट के तौर पर इस्तेमाल न करता हो.

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

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

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

मर्ज के दौरान SIGSEGV update_engine में होने वाली क्रैश की समस्या को ठीक करने के लिए, पक्का करें कि आपके Android 11 सोर्स ट्री में ये बदलाव किए गए हों:

  • CL 1439792 (ए CL 1439372 के लिए ज़रूरी है
  • CL 1439372 (CleanupPreviousUpdateAction: destroy पर, बाकी बचे टास्क रद्द करें)
  • CL 1663460 (इन्हें ठीक करें markSlotSuccessful के देर से आने पर संभावित वाइल्ड पॉइंटर गड़बड़ी)

अपडेट_इंजन को समय से पहले मर्ज होने से रोकें

जब कोई डिवाइस (Android 11 और उसके बाद के वर्शन) बूट होता है और बूट पूरा हो जाता है, तो update_engine, ScheduleWaitMarkBootSuccessful() और WaitForMergeOrSchedule() को कॉल करता है. इससे मर्ज करने की प्रोसेस शुरू हो जाती है. हालांकि, डिवाइस फिर से पुराने स्लॉट पर रीबूट हो जाता है. मर्ज की प्रोसेस पहले ही शुरू हो चुकी है, इसलिए डिवाइस को बूट नहीं किया जा सकता और वह काम नहीं करेगा.

अपने सोर्स ट्री में ये बदलाव जोड़ें. ध्यान दें कि CL 1664859 को शामिल करना ज़रूरी नहीं है.

  • CL 1439792 (ए CL 1439372 के लिए ज़रूरी है
  • CL 1439372 (CleanupPreviousUpdateAction: 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 मोड का इस्तेमाल करें.

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

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

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

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

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