Google 致力于为黑人社区推动种族平等。查看具体举措
此页面由 Cloud Translation API 翻译。
Switch to English

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

एंड्रॉयड 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_engine ) द्वारा किया जाता है update_engine बूटलोडर को बूट करने के लिए निर्देश दिया जा सके। सामान्य उदाहरण परिदृश्य और उनके संबंधित राज्यों में निम्नलिखित शामिल हैं:

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

स्ट्रीमिंग समर्थन का समर्थन

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

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

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

A / B अपडेट का जीवन

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

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

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

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

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

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

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

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

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

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

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

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

रिबूट के बाद

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

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