ए/बी (सीमलेस) सिस्टम अपडेट

ए/बी सिस्टम अपडेट, जिसे सीमलेस अपडेट के रूप में भी जाना जाता है, यह सुनिश्चित करता है कि ओवर-द-एयर (ओटीए) अपडेट के दौरान एक कार्यशील बूटिंग सिस्टम डिस्क पर बना रहे। यह दृष्टिकोण अपडेट के बाद डिवाइस के निष्क्रिय होने की संभावना को कम कर देता है, जिसका अर्थ है कि कम डिवाइस प्रतिस्थापन और मरम्मत और वारंटी केंद्रों पर डिवाइस को दोबारा फ्लैश किया जाएगा। अन्य व्यावसायिक-ग्रेड ऑपरेटिंग सिस्टम जैसे ChromeOS भी A/B अपडेट का सफलतापूर्वक उपयोग करते हैं।

ए/बी सिस्टम अपडेट और वे कैसे काम करते हैं, इसके बारे में अधिक जानकारी के लिए, विभाजन चयन (स्लॉट) देखें।

ए/बी सिस्टम अपडेट निम्नलिखित लाभ प्रदान करते हैं:

  • ओटीए अपडेट तब हो सकता है जब सिस्टम चल रहा हो, उपयोगकर्ता को बाधित किए बिना। उपयोगकर्ता ओटीए के दौरान अपने डिवाइस का उपयोग जारी रख सकते हैं - अपडेट के दौरान एकमात्र डाउनटाइम तब होता है जब डिवाइस अपडेटेड डिस्क विभाजन में रीबूट होता है।
  • अपडेट के बाद, रीबूट करने में नियमित रीबूट से अधिक समय नहीं लगता है।
  • यदि कोई ओटीए लागू करने में विफल रहता है (उदाहरण के लिए, खराब फ्लैश के कारण), तो उपयोगकर्ता प्रभावित नहीं होगा। उपयोगकर्ता पुराना ओएस चलाना जारी रखेगा, और क्लाइंट अपडेट का पुनः प्रयास करने के लिए स्वतंत्र है।
  • यदि ओटीए अपडेट लागू किया गया है लेकिन बूट करने में विफल रहता है, तो डिवाइस पुराने विभाजन में वापस रीबूट हो जाएगा और प्रयोग करने योग्य बना रहेगा। ग्राहक अद्यतन का पुनः प्रयास करने के लिए स्वतंत्र है।
  • कोई भी त्रुटि (जैसे कि I/O त्रुटियाँ) केवल अप्रयुक्त विभाजन सेट को प्रभावित करती है और उसका पुनः प्रयास किया जा सकता है। ऐसी त्रुटियों की संभावना भी कम हो जाती है क्योंकि उपयोगकर्ता अनुभव को खराब होने से बचाने के लिए I/O लोड जानबूझकर कम किया जाता है।
  • अपडेट को ए/बी डिवाइस पर स्ट्रीम किया जा सकता है, जिससे इंस्टॉल करने से पहले पैकेज को डाउनलोड करने की आवश्यकता समाप्त हो जाएगी। स्ट्रीमिंग का मतलब है कि उपयोगकर्ता के पास अपडेट पैकेज को /data या /cache पर संग्रहीत करने के लिए पर्याप्त खाली स्थान होना आवश्यक नहीं है।
  • कैश विभाजन का उपयोग अब ओटीए अद्यतन पैकेजों को संग्रहीत करने के लिए नहीं किया जाता है, इसलिए यह सुनिश्चित करने की कोई आवश्यकता नहीं है कि कैश विभाजन भविष्य के अपडेट के लिए पर्याप्त बड़ा है।
  • dm-verity गारंटी देता है कि एक उपकरण एक अदूषित छवि को बूट करेगा। यदि कोई डिवाइस खराब OTA या dm-verity समस्या के कारण बूट नहीं होता है, तो डिवाइस पुरानी छवि में रीबूट हो सकता है। (एंड्रॉइड सत्यापित बूट को ए/बी अपडेट की आवश्यकता नहीं है।)

ए/बी सिस्टम अपडेट के बारे में

ए/बी अपडेट के लिए क्लाइंट और सिस्टम दोनों में बदलाव की आवश्यकता होती है। हालाँकि, OTA पैकेज सर्वर में बदलाव की आवश्यकता नहीं होनी चाहिए: अपडेट पैकेज अभी भी HTTPS पर परोसे जाते हैं। Google के OTA बुनियादी ढांचे का उपयोग करने वाले उपकरणों के लिए, सिस्टम परिवर्तन सभी AOSP में होते हैं, और क्लाइंट कोड Google Play सेवाओं द्वारा प्रदान किया जाता है। Google के OTA बुनियादी ढांचे का उपयोग नहीं करने वाले OEM AOSP सिस्टम कोड का पुन: उपयोग करने में सक्षम होंगे, लेकिन उन्हें अपने स्वयं के क्लाइंट की आपूर्ति करने की आवश्यकता होगी।

अपने स्वयं के ग्राहक की आपूर्ति करने वाले ओईएम के लिए, ग्राहक को यह करना होगा:

  • तय करें कि अपडेट कब लेना है. क्योंकि ए/बी अपडेट पृष्ठभूमि में होते हैं, वे अब उपयोगकर्ता द्वारा शुरू नहीं किए जाते हैं। उपयोगकर्ताओं को बाधित होने से बचाने के लिए, यह अनुशंसा की जाती है कि जब डिवाइस निष्क्रिय रखरखाव मोड में हो, जैसे रात भर और वाई-फ़ाई पर हो तो अपडेट शेड्यूल किए जाएं। हालाँकि, आपका ग्राहक आपके इच्छित किसी भी अनुमान का उपयोग कर सकता है।
  • अपने ओटीए पैकेज सर्वर से जांच करें और निर्धारित करें कि कोई अपडेट उपलब्ध है या नहीं। यह अधिकतर आपके मौजूदा क्लाइंट कोड के समान होना चाहिए, सिवाय इसके कि आप यह संकेत देना चाहेंगे कि डिवाइस ए/बी का समर्थन करता है। (Google के क्लाइंट में उपयोगकर्ताओं के लिए नवीनतम अपडेट की जांच करने के लिए एक चेक नाउ बटन भी शामिल है।)
  • अपने अपडेट पैकेज के लिए HTTPS URL के साथ update_engine कॉल करें, यह मानते हुए कि एक उपलब्ध है। update_engine वर्तमान में अप्रयुक्त विभाजन पर कच्चे ब्लॉक को अद्यतन करेगा क्योंकि यह अद्यतन पैकेज को स्ट्रीम करता है।
  • update_engine परिणाम कोड के आधार पर, अपने सर्वर पर इंस्टॉलेशन की सफलताओं या विफलताओं की रिपोर्ट करें। यदि अद्यतन सफलतापूर्वक लागू किया जाता है, update_engine अगले रीबूट पर बूटलोडर को नए OS में बूट करने के लिए कहेगा। यदि नया ओएस बूट करने में विफल रहता है तो बूटलोडर पुराने ओएस पर वापस आ जाएगा, इसलिए क्लाइंट से कोई काम करने की आवश्यकता नहीं है। यदि अपडेट विफल हो जाता है, तो क्लाइंट को विस्तृत त्रुटि कोड के आधार पर यह तय करना होगा कि कब (और क्या) दोबारा प्रयास करना है। उदाहरण के लिए, एक अच्छा ग्राहक पहचान सकता है कि आंशिक ("diff") OTA पैकेज विफल हो गया है और इसके बजाय पूर्ण OTA पैकेज आज़मा सकता है।

वैकल्पिक रूप से, ग्राहक यह कर सकता है:

  • उपयोगकर्ता को रीबूट करने के लिए कहने वाली एक अधिसूचना दिखाएं। यदि आप ऐसी नीति लागू करना चाहते हैं जहां उपयोगकर्ता को नियमित रूप से अपडेट करने के लिए प्रोत्साहित किया जाता है, तो यह अधिसूचना आपके क्लाइंट में जोड़ी जा सकती है। यदि क्लाइंट उपयोगकर्ताओं को संकेत नहीं देता है, तो अगली बार रीबूट करने पर उपयोगकर्ताओं को अपडेट मिल जाएगा। (Google के क्लाइंट के पास प्रति-अद्यतन कॉन्फ़िगर करने योग्य विलंब है।)
  • उपयोगकर्ताओं को यह बताने वाली एक अधिसूचना दिखाएँ कि क्या उन्होंने नए OS संस्करण में बूट किया था या क्या उनसे ऐसा करने की अपेक्षा की गई थी लेकिन वे पुराने OS संस्करण पर वापस आ गए। (Google का क्लाइंट आमतौर पर ऐसा नहीं करता है।)

सिस्टम पक्ष पर, ए/बी सिस्टम अपडेट निम्नलिखित को प्रभावित करते हैं:

  • विभाजन चयन (स्लॉट), update_engine डेमॉन और बूटलोडर इंटरैक्शन (नीचे वर्णित)
  • निर्माण प्रक्रिया और ओटीए अपडेट पैकेज निर्माण ( ए/बी अपडेट लागू करने में वर्णित)

विभाजन चयन (स्लॉट)

ए/बी सिस्टम अपडेट विभाजन के दो सेटों का उपयोग करते हैं जिन्हें स्लॉट कहा जाता है (सामान्यतः स्लॉट ए और स्लॉट बी)। सिस्टम वर्तमान स्लॉट से चलता है जबकि अप्रयुक्त स्लॉट में विभाजन सामान्य ऑपरेशन के दौरान रनिंग सिस्टम द्वारा एक्सेस नहीं किया जाता है। यह दृष्टिकोण अप्रयुक्त स्लॉट को फ़ॉलबैक के रूप में रखकर अपडेट को दोष प्रतिरोधी बनाता है: यदि अपडेट के दौरान या तुरंत बाद कोई त्रुटि होती है, तो सिस्टम पुराने स्लॉट पर वापस आ सकता है और कार्य प्रणाली जारी रख सकता है। इस लक्ष्य को प्राप्त करने के लिए, वर्तमान स्लॉट द्वारा उपयोग किए गए किसी भी विभाजन को ओटीए अपडेट के हिस्से के रूप में अद्यतन नहीं किया जाना चाहिए (उन विभाजनों सहित जिनके लिए केवल एक प्रति है)।

प्रत्येक स्लॉट में एक बूट करने योग्य विशेषता होती है जो बताती है कि स्लॉट में एक सही सिस्टम है जिससे डिवाइस बूट हो सकता है। जब सिस्टम चल रहा हो तो वर्तमान स्लॉट बूट करने योग्य होता है, लेकिन दूसरे स्लॉट में सिस्टम का पुराना (अभी भी सही) संस्करण, नया संस्करण या अमान्य डेटा हो सकता है। वर्तमान स्लॉट चाहे जो भी हो, एक स्लॉट है जो सक्रिय स्लॉट है (जिससे बूटलोडर अगले बूट पर बूट होगा) या पसंदीदा स्लॉट है।

प्रत्येक स्लॉट में उपयोगकर्ता स्थान द्वारा निर्धारित एक सफल विशेषता भी होती है, जो केवल तभी प्रासंगिक होती है जब स्लॉट भी बूट करने योग्य हो। एक सफल स्लॉट स्वयं को बूट करने, चलाने और अपडेट करने में सक्षम होना चाहिए। एक बूट करने योग्य स्लॉट जिसे सफल के रूप में चिह्नित नहीं किया गया था (उससे बूट करने के कई प्रयास किए जाने के बाद) को बूटलोडर द्वारा अनबूटेबल के रूप में चिह्नित किया जाना चाहिए, जिसमें सक्रिय स्लॉट को दूसरे बूट करने योग्य स्लॉट में बदलना शामिल है (आमतौर पर बूट करने के प्रयास से तुरंत पहले चलने वाले स्लॉट के लिए) नए, सक्रिय में)। इंटरफ़ेस का विशिष्ट विवरण boot_control.h में परिभाषित किया गया है।

इंजन डेमॉन को अद्यतन करें

ए/बी सिस्टम अपडेट सिस्टम को नए, अद्यतन संस्करण में बूट करने के लिए तैयार करने के लिए update_engine नामक एक पृष्ठभूमि डेमॉन का उपयोग करते हैं। यह डेमॉन निम्नलिखित क्रियाएं कर सकता है:

  • वर्तमान स्लॉट ए/बी विभाजन से पढ़ें और ओटीए पैकेज के निर्देशानुसार किसी भी डेटा को अप्रयुक्त स्लॉट ए/बी विभाजन में लिखें।
  • पूर्व-परिभाषित वर्कफ़्लो में boot_control इंटरफ़ेस को कॉल करें।
  • ओटीए पैकेज के निर्देशानुसार, सभी अप्रयुक्त स्लॉट विभाजनों को लिखने के बाद नए विभाजन से पोस्ट-इंस्टॉल प्रोग्राम चलाएं। (विवरण के लिए, पोस्ट-इंस्टॉलेशन देखें)।

चूँकि update_engine डेमॉन बूट प्रक्रिया में ही शामिल नहीं है, यह वर्तमान स्लॉट में SELinux नीतियों और सुविधाओं द्वारा अपडेट के दौरान क्या कर सकता है, इसमें सीमित है (ऐसी नीतियों और सुविधाओं को तब तक अपडेट नहीं किया जा सकता जब तक कि सिस्टम बूट न ​​हो जाए) नया संस्करण)। एक मजबूत प्रणाली को बनाए रखने के लिए, अद्यतन प्रक्रिया को विभाजन तालिका, वर्तमान स्लॉट में विभाजन की सामग्री, या गैर-ए/बी विभाजन की सामग्री को संशोधित नहीं करना चाहिए जिन्हें फ़ैक्टरी रीसेट के साथ मिटाया नहीं जा सकता है।

इंजन स्रोत अद्यतन करें

update_engine स्रोत system/update_engine में स्थित है। ए/बी ओटीए डेक्सॉप्ट फ़ाइलें installd और पैकेज मैनेजर के बीच विभाजित होती हैं:

  • frameworks/native/cmds/installd/ ota* में पोस्टइंस्टॉल स्क्रिप्ट, क्रोट के लिए बाइनरी, इंस्टाल क्लोन जो dex2oat को कॉल करता है, पोस्ट-ओटीए मूव-आर्टिफैक्ट्स स्क्रिप्ट और मूव स्क्रिप्ट के लिए आरसी फ़ाइल शामिल है।
  • frameworks/base/services/core/java/com/android/server/pm/OtaDexoptService.java (प्लस OtaDexoptShellCommand ) पैकेज मैनेजर है जो अनुप्रयोगों के लिए dex2oat कमांड तैयार करता है।

कार्यशील उदाहरण के लिए, /device/google/marlin/device-common.mk देखें।

इंजन लॉग अद्यतन करें

Android 8.x रिलीज़ और इससे पहले के संस्करणों के लिए, update_engine लॉग logcat और बग रिपोर्ट में पाए जा सकते हैं। फ़ाइल सिस्टम में update_engine लॉग उपलब्ध कराने के लिए, अपने बिल्ड में निम्नलिखित परिवर्तन पैच करें:

ये परिवर्तन नवीनतम update_engine लॉग की एक प्रति /data/misc/update_engine_log/update_engine. YEAR - TIME . वर्तमान लॉग के अलावा, पांच सबसे हालिया लॉग /data/misc/update_engine_log/ के अंतर्गत सहेजे गए हैं। लॉग समूह आईडी वाले उपयोगकर्ता फ़ाइल सिस्टम लॉग तक पहुंच सकेंगे।

बूटलोडर इंटरैक्शन

boot_control HAL का उपयोग update_engine (और संभवतः अन्य डेमॉन) द्वारा बूटलोडर को यह निर्देश देने के लिए किया जाता है कि क्या बूट करना है। सामान्य उदाहरण परिदृश्यों और उनसे जुड़ी स्थितियों में निम्नलिखित शामिल हैं:

  • सामान्य मामला : सिस्टम अपने वर्तमान स्लॉट, या तो स्लॉट ए या बी से चल रहा है। अब तक कोई अपडेट लागू नहीं किया गया है। सिस्टम का वर्तमान स्लॉट बूट करने योग्य, सफल और सक्रिय स्लॉट है।
  • अद्यतन प्रगति पर है : सिस्टम स्लॉट बी से चल रहा है, इसलिए स्लॉट बी बूट करने योग्य, सफल और सक्रिय स्लॉट है। स्लॉट ए को अनबूटेबल के रूप में चिह्नित किया गया था क्योंकि स्लॉट ए की सामग्री अपडेट की जा रही है लेकिन अभी तक पूरी नहीं हुई है। इस स्थिति में रिबूट को स्लॉट बी से बूटिंग जारी रखनी चाहिए।
  • अपडेट लागू, रिबूट लंबित : सिस्टम स्लॉट बी से चल रहा है, स्लॉट बी बूट करने योग्य और सफल है, लेकिन स्लॉट ए को सक्रिय के रूप में चिह्नित किया गया था (और इसलिए बूट करने योग्य के रूप में चिह्नित किया गया है)। स्लॉट ए को अभी तक सफल के रूप में चिह्नित नहीं किया गया है और स्लॉट ए से बूट करने के कुछ प्रयास बूटलोडर द्वारा किए जाने चाहिए।
  • सिस्टम को नए अपडेट में रीबूट किया गया : सिस्टम पहली बार स्लॉट ए से चल रहा है, स्लॉट बी अभी भी बूट करने योग्य और सफल है जबकि स्लॉट ए केवल बूट करने योग्य है, और अभी भी सक्रिय है लेकिन सफल नहीं है। एक उपयोगकर्ता स्थान डेमॉन, update_verifier कुछ जांच करने के बाद स्लॉट ए को सफल के रूप में चिह्नित करना चाहिए।

स्ट्रीमिंग अद्यतन समर्थन

अद्यतन पैकेज़ को डाउनलोड करने के लिए उपयोगकर्ता उपकरणों के पास हमेशा /data पर पर्याप्त स्थान नहीं होता है। चूंकि न तो ओईएम और न ही उपयोगकर्ता /cache विभाजन पर जगह बर्बाद करना चाहते हैं, कुछ उपयोगकर्ता अपडेट के बिना रहते हैं क्योंकि डिवाइस में अपडेट पैकेज को संग्रहीत करने के लिए कहीं नहीं है। इस समस्या को हल करने के लिए, एंड्रॉइड 8.0 ने ए/बी अपडेट स्ट्रीमिंग के लिए समर्थन जोड़ा, जो डाउनलोड होते ही ब्लॉक को सीधे बी विभाजन में लिख देता है, ब्लॉक को /data पर संग्रहीत किए बिना। स्ट्रीमिंग ए/बी अपडेट के लिए लगभग किसी अस्थायी भंडारण की आवश्यकता नहीं होती है और लगभग 100 KiB मेटाडेटा के लिए पर्याप्त भंडारण की आवश्यकता होती है।

एंड्रॉइड 7.1 में स्ट्रीमिंग अपडेट सक्षम करने के लिए, निम्नलिखित पैच चुनें:

ये पैच एंड्रॉइड 7.1 और बाद में Google मोबाइल सेवाओं (जीएमएस) या किसी अन्य अपडेट क्लाइंट का उपयोग करते हुए स्ट्रीमिंग ए/बी अपडेट का समर्थन करने के लिए आवश्यक हैं।

ए/बी अपडेट का जीवन

अद्यतन प्रक्रिया तब शुरू होती है जब एक ओटीए पैकेज (कोड में पेलोड के रूप में संदर्भित) डाउनलोड करने के लिए उपलब्ध होता है। डिवाइस की नीतियां बैटरी स्तर, उपयोगकर्ता गतिविधि, चार्जिंग स्थिति या अन्य नीतियों के आधार पर पेलोड डाउनलोड और एप्लिकेशन को स्थगित कर सकती हैं। इसके अलावा, क्योंकि अपडेट बैकग्राउंड में चलता है, उपयोगकर्ताओं को शायद पता नहीं चलेगा कि अपडेट चल रहा है। इसका मतलब यह है कि अद्यतन प्रक्रिया नीतियों, अप्रत्याशित रीबूट या उपयोगकर्ता कार्यों के कारण किसी भी बिंदु पर बाधित हो सकती है।

वैकल्पिक रूप से, ओटीए पैकेज में मेटाडेटा स्वयं इंगित करता है कि अपडेट को स्ट्रीम किया जा सकता है; उसी पैकेज का उपयोग गैर-स्ट्रीमिंग इंस्टॉलेशन के लिए भी किया जा सकता है। सर्वर क्लाइंट को यह बताने के लिए मेटाडेटा का उपयोग कर सकता है कि वह स्ट्रीमिंग कर रहा है, इसलिए क्लाइंट update_engine को सही ढंग से OTA सौंप देगा। डिवाइस निर्माता अपने स्वयं के सर्वर और क्लाइंट के साथ यह सुनिश्चित करके स्ट्रीमिंग अपडेट को सक्षम कर सकते हैं कि सर्वर यह पहचानता है कि अपडेट स्ट्रीमिंग है (या मान लें कि सभी अपडेट स्ट्रीमिंग हैं) और क्लाइंट स्ट्रीमिंग के लिए update_engine पर सही कॉल करता है। निर्माता इस तथ्य का उपयोग कर सकते हैं कि पैकेज स्ट्रीमिंग संस्करण का है, जिससे क्लाइंट को स्ट्रीमिंग के रूप में फ्रेमवर्क पक्ष को ट्रिगर करने के लिए एक ध्वज भेजा जा सके।

पेलोड उपलब्ध होने के बाद, अद्यतन प्रक्रिया इस प्रकार है:

कदम गतिविधियाँ
1 वर्तमान स्लॉट (या "स्रोत स्लॉट") को markBootSuccessful() के साथ सफल (यदि पहले से चिह्नित नहीं है) के रूप में चिह्नित किया गया है।
2 फ़ंक्शन setSlotAsUnbootable() को कॉल करके अप्रयुक्त स्लॉट (या "लक्ष्य स्लॉट") को अनबूटेबल के रूप में चिह्नित किया जाता है। बूटलोडर को अप्रयुक्त स्लॉट में वापस जाने से रोकने के लिए अपडेट की शुरुआत में वर्तमान स्लॉट को हमेशा सफल के रूप में चिह्नित किया जाता है, जिसमें जल्द ही अमान्य डेटा होगा। यदि सिस्टम उस बिंदु पर पहुंच गया है जहां वह अपडेट लागू करना शुरू कर सकता है, तो वर्तमान स्लॉट को सफल के रूप में चिह्नित किया जाता है, भले ही अन्य प्रमुख घटक टूट गए हों (जैसे क्रैश लूप में यूआई) क्योंकि इन्हें ठीक करने के लिए नए सॉफ़्टवेयर को पुश करना संभव है समस्या।

अपडेट पेलोड एक अपारदर्शी ब्लॉब है जिसमें नए संस्करण में अपडेट करने के निर्देश हैं। अद्यतन पेलोड में निम्नलिखित शामिल हैं:
  • मेटाडेटा । अद्यतन पेलोड का एक अपेक्षाकृत छोटा हिस्सा, मेटाडेटा में लक्ष्य स्लॉट पर नए संस्करण का उत्पादन और सत्यापन करने के लिए संचालन की एक सूची होती है। उदाहरण के लिए, एक ऑपरेशन एक निश्चित ब्लॉब को डीकंप्रेस कर सकता है और इसे लक्ष्य विभाजन में विशिष्ट ब्लॉकों में लिख सकता है, या स्रोत विभाजन से पढ़ सकता है, बाइनरी पैच लागू कर सकता है, और लक्ष्य विभाजन में कुछ ब्लॉकों में लिख सकता है।
  • अतिरिक्त डेटा . अद्यतन पेलोड के बड़े हिस्से के रूप में, संचालन से जुड़े अतिरिक्त डेटा में इन उदाहरणों में संपीड़ित ब्लॉब या बाइनरी पैच शामिल हैं।
3 पेलोड मेटाडेटा डाउनलोड हो गया है।
4 मेटाडेटा में परिभाषित प्रत्येक ऑपरेशन के लिए, क्रम में, संबंधित डेटा (यदि कोई हो) को मेमोरी में डाउनलोड किया जाता है, ऑपरेशन लागू किया जाता है, और संबंधित मेमोरी को हटा दिया जाता है।
5 संपूर्ण विभाजन को अपेक्षित हैश के विरुद्ध पुनः पढ़ा और सत्यापित किया जाता है।
6 पोस्ट-इंस्टॉल चरण (यदि कोई हो) चलाया जाता है। किसी भी चरण के निष्पादन के दौरान त्रुटि की स्थिति में, अद्यतन विफल हो जाता है और संभवतः एक अलग पेलोड के साथ पुनः प्रयास किया जाता है। यदि अब तक के सभी चरण सफल हो गए हैं, तो अद्यतन सफल हो जाता है और अंतिम चरण निष्पादित हो जाता है।
7 अप्रयुक्त स्लॉट को setActiveBootSlot() पर कॉल करके सक्रिय के रूप में चिह्नित किया जाता है। अप्रयुक्त स्लॉट को सक्रिय के रूप में चिह्नित करने का मतलब यह नहीं है कि यह बूटिंग समाप्त कर देगा। बूटलोडर (या सिस्टम स्वयं) सक्रिय स्लॉट को वापस स्विच कर सकता है यदि वह सफल स्थिति नहीं पढ़ता है।
8 पोस्ट-इंस्टॉलेशन (नीचे वर्णित) में पुराने संस्करण में चलते समय "नए अपडेट" संस्करण से एक प्रोग्राम चलाना शामिल है। यदि ओटीए पैकेज में परिभाषित किया गया है, तो यह चरण अनिवार्य है और प्रोग्राम को निकास कोड 0 के साथ वापस आना होगा; अन्यथा, अद्यतन विफल हो जाता है.
9 सिस्टम सफलतापूर्वक नए स्लॉट में काफी दूर तक बूट होने और रिबूट के बाद की जांच पूरी करने के बाद, वर्तमान स्लॉट (पूर्व में "लक्ष्य स्लॉट") को markBootSuccessful() पर कॉल करके सफल के रूप में चिह्नित किया जाता है।

स्थापना के बाद

प्रत्येक विभाजन के लिए जहां एक पोस्ट-इंस्टॉल चरण परिभाषित किया गया है, update_engine नए विभाजन को एक विशिष्ट स्थान पर माउंट करता है और माउंट किए गए विभाजन के सापेक्ष ओटीए में निर्दिष्ट प्रोग्राम को निष्पादित करता है। उदाहरण के लिए, यदि पोस्ट-इंस्टॉल प्रोग्राम को सिस्टम विभाजन में usr/bin/postinstall के रूप में परिभाषित किया गया है, तो अप्रयुक्त स्लॉट से यह विभाजन एक निश्चित स्थान (जैसे /postinstall_mount ) और /postinstall_mount/usr/bin/postinstall में माउंट किया जाएगा। /postinstall_mount/usr/bin/postinstall कमांड निष्पादित किया गया है।

पोस्ट-इंस्टॉलेशन सफल होने के लिए, पुराने कर्नेल को निम्न में सक्षम होना चाहिए:

  • नया फ़ाइल सिस्टम प्रारूप माउंट करें . फ़ाइल सिस्टम प्रकार तब तक नहीं बदल सकता जब तक कि पुराने कर्नेल में इसके लिए समर्थन न हो, जिसमें संपीड़ित फ़ाइल सिस्टम (यानी स्क्वैशएफएस) का उपयोग करते समय उपयोग किए जाने वाले संपीड़न एल्गोरिदम जैसे विवरण शामिल हों।
  • नए विभाजन के पोस्ट-इंस्टॉल प्रोग्राम प्रारूप को समझें । यदि निष्पादन योग्य और लिंक करने योग्य प्रारूप (ईएलएफ) बाइनरी का उपयोग किया जाता है, तो इसे पुराने कर्नेल के साथ संगत होना चाहिए (उदाहरण के लिए पुराने 32-बिट कर्नेल पर चलने वाला 64-बिट नया प्रोग्राम यदि आर्किटेक्चर 32- से 64-बिट बिल्ड में स्विच हो जाता है)। जब तक लोडर ( ld ) को अन्य पथों का उपयोग करने या स्थिर बाइनरी बनाने का निर्देश नहीं दिया जाता है, लाइब्रेरीज़ को पुराने सिस्टम छवि से लोड किया जाएगा, न कि नए से।

उदाहरण के लिए, आप शेल स्क्रिप्ट का उपयोग पोस्ट-इंस्टॉल प्रोग्राम के रूप में कर सकते हैं, जिसे पुराने सिस्टम के शेल बाइनरी द्वारा #! शीर्ष पर मार्कर), फिर अधिक जटिल बाइनरी पोस्ट-इंस्टॉल प्रोग्राम निष्पादित करने के लिए नए वातावरण से लाइब्रेरी पथ सेट करें। वैकल्पिक रूप से, आप बैकवर्ड संगतता समस्याओं या स्टेपिंग-स्टोन अपडेट के बिना मुख्य सिस्टम विभाजन में फ़ाइल सिस्टम प्रारूप को अद्यतन करने में सक्षम करने के लिए एक समर्पित छोटे विभाजन से पोस्ट-इंस्टॉल चरण चला सकते हैं; यह उपयोगकर्ताओं को फ़ैक्टरी छवि से सीधे नवीनतम संस्करण में अपडेट करने की अनुमति देगा।

नया पोस्ट-इंस्टॉल प्रोग्राम पुराने सिस्टम में परिभाषित SELinux नीतियों द्वारा सीमित है। जैसे, पोस्ट-इंस्टॉल चरण किसी दिए गए डिवाइस पर डिज़ाइन के लिए आवश्यक कार्यों या अन्य सर्वोत्तम प्रयास वाले कार्यों को करने के लिए उपयुक्त है (यानी ए/बी-सक्षम फर्मवेयर या बूटलोडर को अपडेट करना, नए संस्करण के लिए डेटाबेस की प्रतियां तैयार करना आदि)। ). रिबूट से पहले एकमुश्त बग फिक्स के लिए पोस्ट-इंस्टॉल चरण उपयुक्त नहीं है जिसके लिए अप्रत्याशित अनुमति की आवश्यकता होती है।

चयनित पोस्ट-इंस्टॉल प्रोग्राम postinstall SELinux संदर्भ में चलता है। नए माउंट किए गए विभाजन की सभी फ़ाइलों को postinstall_file के साथ टैग किया जाएगा, भले ही उस नए सिस्टम में रीबूट करने के बाद उनकी विशेषताएँ कुछ भी हों। नए सिस्टम में SELinux विशेषताओं में परिवर्तन पोस्ट-इंस्टॉल चरण को प्रभावित नहीं करेगा। यदि पोस्ट-इंस्टॉल प्रोग्राम को अतिरिक्त अनुमतियों की आवश्यकता है, तो उन्हें पोस्ट-इंस्टॉल संदर्भ में जोड़ा जाना चाहिए।

रिबूट के बाद

रीबूट करने के बाद, update_verifier dm-verity का उपयोग करके अखंडता जांच को ट्रिगर करता है। यह जाँच जाइगोट से पहले शुरू होती है ताकि जावा सेवाओं द्वारा कोई अपरिवर्तनीय परिवर्तन न किया जा सके जो सुरक्षित रोलबैक को रोक सके। इस प्रक्रिया के दौरान, यदि सत्यापित बूट या dm-verity किसी भ्रष्टाचार का पता लगाता है, तो बूटलोडर और कर्नेल भी रीबूट को ट्रिगर कर सकते हैं। जाँच पूरी होने के बाद, update_verifier बूट को सफल चिह्नित करता है।

update_verifier केवल /data/ota_package/care_map.txt में सूचीबद्ध ब्लॉक को पढ़ेगा, जो AOSP कोड का उपयोग करते समय A/B OTA पैकेज में शामिल है। जावा सिस्टम अपडेट क्लाइंट, जैसे कि GmsCore, care_map.txt को निकालता है, डिवाइस को रीबूट करने से पहले एक्सेस अनुमति सेट करता है, और सिस्टम के नए संस्करण में सफलतापूर्वक बूट होने के बाद निकाली गई फ़ाइल को हटा देता है।