ए/बी (निर्बाध) सिस्टम अपडेट

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

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

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

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

A/B सिस्टम अपडेट के बारे में

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

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

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

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

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

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

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

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

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

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

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

इंजन डेमॉन अपडेट करें

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

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

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

इंजन स्रोत अपडेट करें

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

  • frameworks/native/cmds/installd/ ota* में पोस्टइंस्टॉल स्क्रिप्ट, chroot के लिए बाइनरी, इंस्टाल्ड क्लोन जो dex2oat को कॉल करता है, पोस्ट-OTA मूव-आर्टिफैक्ट्स स्क्रिप्ट, और मूव स्क्रिप्ट के लिए rc फाइल शामिल है।
  • 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 , को कुछ जाँचों के बाद स्लॉट A को सफल के रूप में चिह्नित करना चाहिए।

स्ट्रीमिंग अपडेट सपोर्ट

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

रिबूट के बाद

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

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