अक्सर पूछे जाने वाले सवाल

क्या Google ने किसी डिवाइस पर A/B OTA का उपयोग किया है?

हाँ। ए/बी अपडेट के लिए मार्केटिंग का नाम सीमलेस अपडेट है। अक्टूबर 2016 से Pixel और Pixel XL फ़ोन A/B के साथ भेजे गए, और सभी Chromebook A/B के समान update_engine कार्यान्वयन का उपयोग करते हैं। आवश्यक प्लेटफ़ॉर्म कोड कार्यान्वयन एंड्रॉइड 7.1 और उच्चतर में सार्वजनिक है।

ए/बी ओटीए बेहतर क्यों हैं?

अपडेट लेते समय ए/बी ओटीए बेहतर उपयोगकर्ता अनुभव प्रदान करते हैं। मासिक सुरक्षा अपडेट के माप से पता चलता है कि यह सुविधा पहले ही सफल साबित हो चुकी है: मई 2017 तक, 95% पिक्सेल मालिक 87% नेक्सस उपयोगकर्ताओं की तुलना में एक महीने के बाद नवीनतम सुरक्षा अपडेट चला रहे हैं, और पिक्सेल उपयोगकर्ता नेक्सस उपयोगकर्ताओं की तुलना में जल्दी अपडेट करते हैं। ओटीए के दौरान ब्लॉकों को अद्यतन करने में विफलता के परिणामस्वरूप अब कोई उपकरण बूट नहीं होगा; जब तक नई सिस्टम छवि सफलतापूर्वक बूट नहीं हो जाती, एंड्रॉइड पिछली कार्य प्रणाली छवि पर वापस आने की क्षमता बरकरार रखता है।

A/B ने 2016 पिक्सेल विभाजन आकार को कैसे प्रभावित किया?

निम्न तालिका में शिपिंग ए/बी कॉन्फ़िगरेशन बनाम आंतरिक रूप से परीक्षण किए गए गैर-ए/बी कॉन्फ़िगरेशन पर विवरण शामिल हैं:

A/B अपडेट के लिए फ़्लैश में केवल 320 MiB की वृद्धि की आवश्यकता होती है, पुनर्प्राप्ति विभाजन को हटाने से 32MiB की बचत होती है और कैश विभाजन को हटाने से 100MiB की बचत होती है। यह बूटलोडर, बूट विभाजन और रेडियो विभाजन के लिए बी विभाजन की लागत को संतुलित करता है। विक्रेता विभाजन आकार में दोगुना हो गया (अधिकांश आकार में वृद्धि)। पिक्सेल की ए/बी सिस्टम छवि मूल गैर-ए/बी सिस्टम छवि के आधे आकार की है।

आंतरिक रूप से परीक्षण किए गए पिक्सेल ए/बी और गैर-ए/बी वेरिएंट के लिए (केवल ए/बी शिप किया गया), उपयोग की गई जगह में केवल 320MiB का अंतर था। 32GiB डिवाइस पर, यह केवल 1% से कम है। 16GiB डिवाइस के लिए यह 2% से कम होगा, और 8GiB डिवाइस के लिए लगभग 4% (यह मानते हुए कि सभी तीन डिवाइसों की सिस्टम छवि समान थी)।

आपने स्क्वैशएफएस का उपयोग क्यों नहीं किया?

हमने स्क्वैशएफएस के साथ प्रयोग किया लेकिन उच्च-स्तरीय डिवाइस के लिए वांछित प्रदर्शन हासिल नहीं कर पाए। हम हैंडहेल्ड उपकरणों के लिए स्क्वैशएफएस का उपयोग या अनुशंसा नहीं करते हैं।

अधिक विशेष रूप से, स्क्वैशएफएस ने सिस्टम विभाजन पर लगभग 50% आकार की बचत प्रदान की, लेकिन अच्छी तरह से संपीड़ित फ़ाइलों का भारी बहुमत पूर्व-संकलित .odex फ़ाइलें थीं। उन फ़ाइलों में बहुत अधिक संपीड़न अनुपात (लगभग 80%) था, लेकिन शेष सिस्टम विभाजन के लिए संपीड़न अनुपात बहुत कम था। इसके अलावा, एंड्रॉइड 7.0 में स्क्वैशएफएस ने निम्नलिखित प्रदर्शन संबंधी चिंताओं को उठाया:

• पहले के उपकरणों की तुलना में पिक्सेल में बहुत तेज़ फ्लैश है लेकिन बड़ी संख्या में अतिरिक्त सीपीयू चक्र नहीं हैं, इसलिए फ्लैश से कम बाइट्स पढ़ना लेकिन I/O के लिए अधिक सीपीयू की आवश्यकता एक संभावित बाधा थी।
• अनलोडेड सिस्टम पर चलने वाले कृत्रिम बेंचमार्क पर अच्छा प्रदर्शन करने वाले I/O परिवर्तन कभी-कभी वास्तविक-विश्व लोड (जैसे नेक्सस 6 पर क्रिप्टो) के तहत वास्तविक दुनिया के उपयोग के मामलों पर अच्छा काम नहीं करते हैं।
• बेंचमार्किंग ने कुछ स्थानों पर 85% प्रतिगमन दिखाया।

जैसे-जैसे स्क्वैशएफएस परिपक्व होता है और सीपीयू प्रभाव को कम करने के लिए सुविधाएँ जोड़ता है (जैसे कि सामान्य रूप से एक्सेस की जाने वाली फ़ाइलों की एक श्वेतसूची जिसे संपीड़ित नहीं किया जाना चाहिए), हम इसका मूल्यांकन करना जारी रखेंगे और डिवाइस निर्माताओं को सिफारिशें पेश करेंगे।

आपने स्क्वैशएफएस के बिना सिस्टम विभाजन का आकार आधा कैसे कर दिया?

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

उदाहरण: 2628MiB (2755792836 बाइट्स) के कुल सिस्टम छवि आकार के साथ Android 7.1 चलाने वाले Nexus 6P से इंस्टॉल किए गए-files.txt के लिए, फ़ाइल प्रकार के आधार पर समग्र सिस्टम छवि आकार में सबसे बड़े योगदानकर्ताओं का विवरण इस प्रकार है:

ये आंकड़े अन्य उपकरणों के लिए भी समान हैं, इसलिए नेक्सस/पिक्सेल उपकरणों पर, .odex फ़ाइलें सिस्टम विभाजन का लगभग आधा हिस्सा लेती हैं। इसका मतलब है कि हम ext4 का उपयोग जारी रख सकते हैं लेकिन .odex फ़ाइलों को फ़ैक्टरी में B पार्टीशन में लिख सकते हैं और फिर उन्हें पहले बूट पर /data में कॉपी कर सकते हैं। Ext4 A/B के साथ उपयोग किया जाने वाला वास्तविक भंडारण स्क्वैशFS A/B के समान है, क्योंकि यदि हमने स्क्वैशFS का उपयोग किया होता तो हम सिस्टम_b के बजाय सिस्टम_a पर प्रीऑप्टेड .odex फ़ाइलों को भेज देते।

क्या .odex फ़ाइलों को /डेटा में कॉपी करने का मतलब यह नहीं है कि /सिस्टम पर सहेजा गया स्थान /डेटा पर खो गया है?

बिल्कुल नहीं। पिक्सेल पर, .odex फ़ाइलों द्वारा ली गई अधिकांश जगह ऐप्स के लिए होती है, जो आमतौर पर /data पर मौजूद होती हैं। ये ऐप्स Google Play अपडेट लेते हैं, इसलिए सिस्टम छवि पर .apk और .odex फ़ाइलें डिवाइस के अधिकांश जीवन के लिए अप्रयुक्त रहती हैं। जब उपयोगकर्ता वास्तव में प्रत्येक ऐप का उपयोग करता है तो ऐसी फ़ाइलों को पूरी तरह से बाहर रखा जा सकता है और छोटी, प्रोफ़ाइल-संचालित .odex फ़ाइलों द्वारा प्रतिस्थापित किया जा सकता है (इस प्रकार उपयोगकर्ता द्वारा उपयोग नहीं किए जाने वाले ऐप्स के लिए कोई स्थान की आवश्यकता नहीं होती है)। विवरण के लिए, Google I/O 2016 टॉक द इवोल्यूशन ऑफ़ आर्ट देखें।

कुछ प्रमुख कारणों से तुलना कठिन है:

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

ओईएम के लिए उपलब्ध ट्यूनिंग विकल्पों के विवरण के लिए, एआरटी को कॉन्फ़िगर करना देखें।

क्या /डेटा पर .odex फ़ाइलों की दो प्रतियां नहीं हैं?

यह थोड़ा अधिक जटिल है... नई सिस्टम छवि लिखे जाने के बाद, नई .odex फ़ाइलें उत्पन्न करने के लिए dex2oat का नया संस्करण नई .dex फ़ाइलों के विरुद्ध चलाया जाता है। ऐसा तब होता है जब पुराना सिस्टम अभी भी चल रहा है, इसलिए पुरानी और नई .odex फ़ाइलें एक ही समय में /data पर होती हैं।

OtaDexoptService में कोड ( frameworks/base/+/main/services/core/java/com/android/server/pm/OtaDexoptService.java ) ओवर-फिलिंग /data से बचने के लिए प्रत्येक पैकेज को अनुकूलित करने से पहले getAvailableSpace कॉल करता है। ध्यान दें कि यहां उपलब्ध अभी भी रूढ़िवादी है: यह सामान्य सिस्टम कम स्थान सीमा तक पहुंचने से पहले छोड़ी गई जगह की मात्रा है (प्रतिशत और बाइट गिनती दोनों के रूप में मापा जाता है)। इसलिए यदि /data भरा हुआ है, तो प्रत्येक .odex फ़ाइल की दो प्रतियां नहीं होंगी। उसी कोड में BULK_DELETE_THRESHOLD भी है: यदि डिवाइस उपलब्ध स्थान को भरने के करीब पहुंच जाता है (जैसा कि अभी बताया गया है), तो उपयोग नहीं किए गए ऐप्स से संबंधित .odex फ़ाइलें हटा दी जाती हैं। यह प्रत्येक .odex फ़ाइल की दो प्रतियों के बिना एक और मामला है।

सबसे खराब स्थिति में जहां /data पूरी तरह से भरा हुआ है, अपडेट तब तक प्रतीक्षा करता है जब तक कि डिवाइस नए सिस्टम में रीबूट नहीं हो जाता है और अब पुराने सिस्टम की .odex फ़ाइलों की आवश्यकता नहीं होती है। पैकेजमैनेजर इसे संभालता है: ( frameworks/base/+/main/services/core/java/com/android/server/pm/PackageManagerService.java#7215 )। नए सिस्टम के सफलतापूर्वक बूट होने के बाद, installd ( frameworks/native/+/main/cmds/installd/dexopt.cpp#2422 ) पुराने सिस्टम द्वारा उपयोग की गई .odex फ़ाइलों को हटा सकता है, जिससे डिवाइस वापस स्थिर स्थिति में आ जाता है। जहां केवल एक प्रति है.

इसलिए, जबकि यह संभव है कि /data में सभी .odex फ़ाइलों की दो प्रतियां हों, (ए) यह अस्थायी है और (बी) केवल तभी होता है जब आपके पास वैसे भी /data पर बहुत सारी खाली जगह हो। अद्यतन के दौरान को छोड़कर, केवल एक प्रति होती है। और एआरटी की सामान्य मजबूती सुविधाओं के हिस्से के रूप में, यह कभी भी /data .odex फ़ाइलों से नहीं भरेगा (क्योंकि यह गैर-ए/बी सिस्टम पर भी एक समस्या होगी)।

क्या यह सब लिखने/कॉपी करने से फ्लैश घिसाव नहीं बढ़ता?

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

क्या दो सिस्टम विभाजनों को फ़्लैश करने से फ़ैक्टरी फ़्लैशिंग समय बढ़ जाता है?

नहीं, पिक्सेल ने सिस्टम छवि आकार में वृद्धि नहीं की (इसने केवल स्थान को दो विभाजनों में विभाजित किया)।

क्या .odex फ़ाइलों को B पर रखने से फ़ैक्टरी डेटा रीसेट के बाद रीबूटिंग धीमी हो जाती है?

हाँ। यदि आपने वास्तव में एक डिवाइस का उपयोग किया है, ओटीए लिया है, और फ़ैक्टरी डेटा रीसेट किया है, तो पहला रीबूट अन्यथा धीमा होगा (पिक्सेल एक्सएल पर 1m40s बनाम 40s) क्योंकि .odex फ़ाइलें खो गई होंगी पहले ओटीए के बाद बी और इसलिए /data में कॉपी नहीं किया जा सकता है। वह समझौता है।

नियमित बूट की तुलना में फ़ैक्टरी डेटा रीसेट एक दुर्लभ ऑपरेशन होना चाहिए, इसलिए इसमें लगने वाला समय कम महत्वपूर्ण है। (यह उन उपयोगकर्ताओं या समीक्षकों को प्रभावित नहीं करता है जो फ़ैक्टरी से अपना उपकरण प्राप्त करते हैं, क्योंकि उस स्थिति में बी विभाजन उपलब्ध है।) जेआईटी कंपाइलर के उपयोग का मतलब है कि हमें सब कुछ पुन: संकलित करने की आवश्यकता नहीं है, इसलिए यह आपके जितना बुरा नहीं है शायद सोचा। मेनिफेस्ट में coreApp="true" का उपयोग करके ऐप्स को समय से पहले संकलन की आवश्यकता के रूप में चिह्नित करना भी संभव है: ( frameworks/base/+/main/packages/SystemUI/AndroidManifest.xml#23 )। यह वर्तमान में system_server द्वारा उपयोग किया जाता है क्योंकि सुरक्षा कारणों से इसे JIT की अनुमति नहीं है।

क्या .odex फ़ाइलों को /system के बजाय /data पर रखने से OTA के बाद रीबूटिंग धीमी हो जाती है?

नहीं, जैसा कि ऊपर बताया गया है, नया dex2oat तब चलता है जब पुराने सिस्टम की छवि अभी भी उन फ़ाइलों को उत्पन्न करने के लिए चल रही होती है जिनकी नए सिस्टम को आवश्यकता होगी। जब तक वह कार्य पूरा नहीं हो जाता तब तक अद्यतन उपलब्ध नहीं माना जाता है।

क्या हमें 32GiB A/B डिवाइस शिप करना चाहिए? 16जीबी? 8GiB?

32GiB अच्छी तरह से काम करता है जैसा कि Pixel पर सिद्ध हुआ था, और 16GiB में से 320MiB का मतलब 2% की कमी है। इसी तरह, 8GiB में से 320MiB में 4% की कमी आई है। स्पष्ट रूप से 4GiB वाले उपकरणों पर A/B अनुशंसित विकल्प नहीं होगा, क्योंकि 320MiB ओवरहेड कुल उपलब्ध स्थान का लगभग 10% है।

क्या AVB2.0 को A/B OTA की आवश्यकता है?

नहीं, एंड्रॉइड सत्यापित बूट को हमेशा ब्लॉक-आधारित अपडेट की आवश्यकता होती है, लेकिन जरूरी नहीं कि ए/बी अपडेट हो।

क्या ए/बी ओटीए को AVB2.0 की आवश्यकता है?

नहीं।

क्या A/B OTAs AVB2.0 की रोलबैक सुरक्षा को तोड़ते हैं?

नहीं, यहां कुछ भ्रम है क्योंकि यदि कोई ए/बी सिस्टम नई सिस्टम छवि में बूट करने में विफल रहता है तो यह (आपके बूटलोडर द्वारा निर्धारित कुछ संख्या में पुनः प्रयास के बाद) स्वचालित रूप से "पिछली" सिस्टम छवि पर वापस आ जाएगा। हालाँकि यहाँ मुख्य बात यह है कि ए/बी अर्थ में "पिछला" वास्तव में अभी भी "वर्तमान" सिस्टम छवि है। जैसे ही डिवाइस एक नई छवि को सफलतापूर्वक बूट करता है, रोलबैक सुरक्षा शुरू हो जाती है और यह सुनिश्चित करती है कि आप वापस नहीं जा सकते। लेकिन जब तक आप वास्तव में नई छवि को सफलतापूर्वक बूट नहीं कर लेते, रोलबैक सुरक्षा इसे वर्तमान सिस्टम छवि नहीं मानती है।

यदि आप सिस्टम के चलने के दौरान कोई अपडेट इंस्टॉल कर रहे हैं, तो क्या यह धीमा नहीं है?

गैर-ए/बी अपडेट के साथ, लक्ष्य जितनी जल्दी हो सके अपडेट को इंस्टॉल करना है क्योंकि अपडेट लागू होने के दौरान उपयोगकर्ता इंतजार कर रहा है और अपने डिवाइस का उपयोग करने में असमर्थ है। ए/बी अपडेट के साथ, विपरीत सच है; क्योंकि उपयोगकर्ता अभी भी अपने डिवाइस का उपयोग कर रहा है, लक्ष्य पर जितना संभव हो उतना कम प्रभाव पड़ेगा, इसलिए अपडेट जानबूझकर धीमा है। जावा सिस्टम अपडेट क्लाइंट (जो Google के लिए GmsCore है, GMS द्वारा प्रदान किया गया कोर पैकेज है) में तर्क के माध्यम से, एंड्रॉइड एक ऐसा समय चुनने का भी प्रयास करता है जब उपयोगकर्ता अपने डिवाइस का बिल्कुल भी उपयोग नहीं कर रहे हों। प्लेटफ़ॉर्म अपडेट को रोकने/फिर से शुरू करने का समर्थन करता है, और यदि उपयोगकर्ता डिवाइस का उपयोग करना शुरू कर देता है तो क्लाइंट अपडेट को रोकने के लिए इसका उपयोग कर सकता है और डिवाइस के दोबारा निष्क्रिय होने पर इसे फिर से शुरू कर सकता है।

ओटीए लेते समय दो चरण होते हैं, जिन्हें यूआई में प्रगति पट्टी के नीचे 2 में से चरण 1 और 2 में से 2 चरण के रूप में स्पष्ट रूप से दिखाया गया है। चरण 1 डेटा ब्लॉक लिखने से संबंधित है, जबकि चरण 2 .dex फ़ाइलों को पूर्व-संकलित करने से संबंधित है। प्रदर्शन प्रभाव की दृष्टि से ये दोनों चरण काफी भिन्न हैं। पहला चरण सरल I/O है। इसके लिए संसाधनों (रैम, सीपीयू, आई/ओ) की बहुत कम आवश्यकता होती है क्योंकि यह बस धीरे-धीरे ब्लॉकों की प्रतिलिपि बना रहा है।

दूसरा चरण नई सिस्टम छवि को प्रीकंपाइल करने के लिए dex2oat चलाता है। इसकी आवश्यकताओं पर स्पष्ट रूप से कम स्पष्ट सीमाएँ हैं क्योंकि यह वास्तविक ऐप्स संकलित करता है। और एक छोटे और सरल ऐप की तुलना में एक बड़े और जटिल ऐप को संकलित करने में स्पष्ट रूप से बहुत अधिक काम शामिल है; जबकि चरण 1 में कोई भी डिस्क ब्लॉक नहीं है जो दूसरों की तुलना में बड़ा या अधिक जटिल हो।

यह प्रक्रिया वैसी ही है जब Google Play 5 ऐप्स अपडेट अधिसूचना दिखाने से पहले पृष्ठभूमि में एक ऐप अपडेट इंस्टॉल करता है, जैसा कि वर्षों से किया जाता रहा है।

यदि कोई उपयोगकर्ता वास्तव में अपडेट का इंतजार कर रहा है तो क्या होगा?

GmsCore में वर्तमान कार्यान्वयन पृष्ठभूमि अपडेट और उपयोगकर्ता द्वारा शुरू किए गए अपडेट के बीच अंतर नहीं करता है, लेकिन भविष्य में ऐसा हो सकता है। ऐसे मामले में जहां उपयोगकर्ता ने स्पष्ट रूप से अपडेट इंस्टॉल करने के लिए कहा है या अपडेट प्रगति स्क्रीन देख रहा है, हम इस धारणा पर अपडेट कार्य को प्राथमिकता देंगे कि वे सक्रिय रूप से इसके समाप्त होने की प्रतीक्षा कर रहे हैं।

यदि अद्यतन लागू करने में विफलता होती है तो क्या होगा?

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

चिप पर कौन से सिस्टम (एसओसी) ए/बी का समर्थन करते हैं?

2017-03-15 तक, हमारे पास निम्नलिखित जानकारी है:

शेड्यूल के विवरण के लिए, अपने SoC संपर्कों से जाँच करें। ऊपर सूचीबद्ध नहीं किए गए SoCs के लिए, सीधे अपने SoC से संपर्क करें।