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

क्या Google ने किसी डिवाइस पर A/B OTA का इस्तेमाल किया है?

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

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

A/B OTA अपडेट करने पर, उपयोगकर्ताओं को बेहतर अनुभव मिलता है. हर महीने मिलने वाले सुरक्षा अपडेट से पता चलता है कि यह सुविधा पहले ही सफल साबित हो चुकी है: मई 2017 तक, Pixel के 95% मालिकों ने एक महीने के अंदर सुरक्षा से जुड़ा नया अपडेट इंस्टॉल कर लिया था. वहीं, Nexus के 87% उपयोगकर्ताओं ने ऐसा किया था. साथ ही, Pixel के उपयोगकर्ता, Nexus के उपयोगकर्ताओं की तुलना में सुरक्षा से जुड़ा नया अपडेट जल्दी इंस्टॉल करते हैं. ओटीए के दौरान ब्लॉक अपडेट न होने पर, डिवाइस बूट नहीं होगा. हालांकि, जब तक नई सिस्टम इमेज बूट नहीं हो जाती, तब तक Android के पास पिछली सिस्टम इमेज पर वापस जाने की सुविधा होती है.

system_other क्या है?

ऐप्लिकेशन को .apk फ़ाइलों में सेव किया जाता है. ये फ़ाइलें, असल में ZIP संग्रह होती हैं. हर .apk फ़ाइल में एक या उससे ज़्यादा .dex फ़ाइलें होती हैं. इनमें पोर्टेबल Dalvik बाइटकोड होता है. .odex फ़ाइल (ऑप्टिमाइज़ किया गया .dex) .apk फ़ाइल से अलग होती है. इसमें डिवाइस के हिसाब से मशीन कोड शामिल हो सकता है. अगर .odex फ़ाइल उपलब्ध है, तो Android, ऐप्लिकेशन को पहले से कंपाइल की गई स्पीड पर चला सकता है. इसके लिए, उसे ऐप्लिकेशन लॉन्च होने पर हर बार कोड के कंपाइल होने का इंतज़ार नहीं करना पड़ता. .odex फ़ाइल ज़रूरी नहीं है: Android, .dex कोड को सीधे तौर पर इंटरप्रेट करके या Just-In-Time (JIT) कंपाइलेशन के ज़रिए चला सकता है. हालांकि, अगर जगह उपलब्ध है, तो .odex फ़ाइल से ऐप्लिकेशन को लॉन्च करने और उसे चलाने की स्पीड सबसे अच्छी मिलती है.

उदाहरण: Android 7.1 पर चलने वाले Nexus 6P के installed-files.txt के लिए, सिस्टम इमेज का कुल साइज़ 2628MiB (2755792836 बाइट) है. फ़ाइल टाइप के हिसाब से, सिस्टम इमेज के कुल साइज़ में सबसे ज़्यादा योगदान देने वाली फ़ाइलों की जानकारी यहां दी गई है:

.odex	1391770312 बाइट	50.5%
.apk	84,68,78,259 बाइट	30.7%
.so (नेटिव C/C++ कोड)	202162479 बाइट	7.3%
.oat फ़ाइलें/.art इमेज	163892188 बाइट	5.9%
फ़ॉन्ट	3,89,52,361 बाइट	1.4%
icu locale data	27468687 बाइट	0.9%

ये आंकड़े अन्य डिवाइसों के लिए भी मिलते-जुलते हैं. इसलिए, Nexus/Pixel डिवाइसों पर .odex फ़ाइलें, सिस्टम पार्टीशन का करीब आधा हिस्सा लेती हैं. इसका मतलब है कि हम ext4 का इस्तेमाल जारी रख सकते हैं. हालांकि, फ़ैक्ट्री में .odex फ़ाइलों को B पार्टीशन में लिखा जाता है. इसके बाद, पहली बार बूट करने पर उन्हें /data में कॉपी किया जाता है. ext4 A/B के साथ इस्तेमाल किया गया स्टोरेज, SquashFS A/B के साथ इस्तेमाल किए गए स्टोरेज के बराबर होता है. ऐसा इसलिए, क्योंकि अगर हमने SquashFS का इस्तेमाल किया होता, तो हम system_b के बजाय system_a पर प्रीऑप्ट की गई .odex फ़ाइलें शिप करते.

क्या .odex फ़ाइलों को /data में कॉपी करने का मतलब यह नहीं है कि /system में सेव की गई जगह, /data में खो गई है?

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

तुलना करना मुश्किल है. इसकी कुछ मुख्य वजहें यहां दी गई हैं:

• Google Play से अपडेट किए गए ऐप्लिकेशन की .odex फ़ाइलें, /data पर हमेशा मौजूद होती हैं. ऐसा तब होता है, जब उन्हें पहला अपडेट मिलता है.
• जिन ऐप्लिकेशन को उपयोगकर्ता नहीं चलाता है उनके लिए .odex फ़ाइल की ज़रूरत नहीं होती.
• प्रोफ़ाइल के हिसाब से कंपाइल करने की सुविधा, ऐप्लिकेशन को पहले से कंपाइल करने की सुविधा की तुलना में छोटी .odex फ़ाइलें जनरेट करती है. इसकी वजह यह है कि यह सुविधा, सिर्फ़ परफ़ॉर्मेंस के लिए ज़रूरी कोड को ऑप्टिमाइज़ करती है.

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

क्या /data पर .odex फ़ाइलों की दो कॉपी नहीं हैं?

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

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

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

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

क्या लिखने/कॉपी करने से, फ़्लैश मेमोरी की उम्र कम नहीं हो जाती?

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

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

नहीं. Pixel में सिस्टम इमेज का साइज़ नहीं बढ़ा है. इसमें सिर्फ़ स्पेस को दो पार्टिशन में बांटा गया है.

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

हां. अगर आपने किसी डिवाइस का इस्तेमाल किया है, ओटीए लिया है, और फ़ैक्ट्री रीसेट किया है, तो पहली बार रीबूट होने में ज़्यादा समय लगेगा. ऐसा इसलिए, क्योंकि पहले ओटीए के बाद B से .odex फ़ाइलें मिट जाएंगी. इसलिए, उन्हें /data में कॉपी नहीं किया जा सकेगा. उदाहरण के लिए, Pixel XL पर रीबूट होने में 1 मिनट 40 सेकंड लगेंगे, जबकि आम तौर पर 40 सेकंड लगते हैं. यह एक तरह का समझौता है.

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

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

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

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

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

क्या AVB2.0 के लिए A/B OTA ज़रूरी हैं?

नहीं. Android वेरिफ़ाइड बूट के लिए, हमेशा ब्लॉक-आधारित अपडेट की ज़रूरत होती है. हालांकि, A/B अपडेट की ज़रूरत नहीं होती.

क्या A/B OTA के लिए AVB2.0 ज़रूरी है?

नहीं.

क्या A/B OTA, AVB2.0 की रोलबैक प्रोटेक्शन की सुविधा को बंद कर देते हैं?

नहीं. यहां कुछ भ्रम है, क्योंकि अगर कोई A/B सिस्टम नई सिस्टम इमेज में बूट नहीं हो पाता है, तो वह (आपके बूटलोडर के तय किए गए कुछ बार के बाद) अपने-आप "पिछली" सिस्टम इमेज पर वापस आ जाएगा. हालांकि, यहां मुख्य बात यह है कि A/B के हिसाब से "पिछली" इमेज, असल में अब भी "मौजूदा" सिस्टम इमेज है. जैसे ही डिवाइस नई इमेज को बूट करता है, रोलबैक सुरक्षा की सुविधा चालू हो जाती है. इससे यह पक्का होता है कि आपके पास वापस जाने का विकल्प नहीं है. हालांकि, जब तक नई इमेज को बूट नहीं किया जाता, तब तक रोलबैक सुरक्षा इसे मौजूदा सिस्टम इमेज नहीं मानती.

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

नॉन-ए/बी अपडेट का मकसद, अपडेट को जल्द से जल्द इंस्टॉल करना होता है. ऐसा इसलिए, क्योंकि अपडेट लागू होने के दौरान उपयोगकर्ता इंतज़ार कर रहा होता है और अपने डिवाइस का इस्तेमाल नहीं कर पाता. A/B अपडेट के मामले में, ऐसा नहीं होता. उपयोगकर्ता अब भी अपने डिवाइस का इस्तेमाल कर रहा होता है. इसलिए, हमारा लक्ष्य होता है कि अपडेट का असर कम से कम हो. इसलिए, अपडेट को जान-बूझकर धीरे-धीरे किया जाता है. Java सिस्टम अपडेट क्लाइंट में मौजूद लॉजिक के ज़रिए, Android यह भी तय करने की कोशिश करता है कि अपडेट कब इंस्टॉल किया जाए. इससे यह पक्का किया जाता है कि अपडेट के दौरान, उपयोगकर्ता अपने डिवाइसों का इस्तेमाल न कर रहे हों. Google के लिए, यह GmsCore है. यह GMS की ओर से उपलब्ध कराया गया मुख्य पैकेज है. यह प्लैटफ़ॉर्म, अपडेट को रोकने/फिर से शुरू करने की सुविधा देता है. अगर उपयोगकर्ता डिवाइस का इस्तेमाल करना शुरू कर देता है, तो क्लाइंट इस सुविधा का इस्तेमाल करके अपडेट को रोक सकता है. इसके बाद, जब डिवाइस का इस्तेमाल नहीं किया जा रहा हो, तब अपडेट को फिर से शुरू किया जा सकता है.

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

दूसरे फ़ेज़ में, dex2oat को चलाया जाता है, ताकि नई सिस्टम इमेज को पहले से कंपाइल किया जा सके. ज़ाहिर है, इसकी ज़रूरी शर्तों के बारे में साफ़ तौर पर कम जानकारी दी गई है, क्योंकि यह असल ऐप्लिकेशन को कंपाइल करता है. ज़ाहिर है, किसी बड़े और जटिल ऐप्लिकेशन को कंपाइल करने में, छोटे और आसान ऐप्लिकेशन की तुलना में ज़्यादा काम करना पड़ता है. वहीं, पहले फ़ेज़ में कोई भी डिस्क ब्लॉक, दूसरे डिस्क ब्लॉक से बड़ा या ज़्यादा जटिल नहीं होता.

यह प्रोसेस, उस प्रोसेस की तरह ही होती है जब Google Play, 5 ऐप्लिकेशन अपडेट किए गए सूचना दिखाने से पहले, बैकग्राउंड में ऐप्लिकेशन का अपडेट इंस्टॉल करता है. ऐसा कई सालों से किया जा रहा है.

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

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

अपडेट लागू न होने पर क्या होता है?

नॉन-ए/बी अपडेट के दौरान, अगर कोई अपडेट लागू नहीं होता था, तो उपयोगकर्ता के पास ऐसा डिवाइस बचता था जिसका इस्तेमाल नहीं किया जा सकता था. हालांकि, अगर ऐप्लिकेशन शुरू होने से पहले ही गड़बड़ी हो जाती है, तो उसे इस नियम से छूट मिलती है. जैसे, पैकेज की पुष्टि नहीं हो पाई. A/B अपडेट की मदद से, अपडेट लागू न होने पर भी, मौजूदा सिस्टम पर कोई असर नहीं पड़ता. अपडेट करने की प्रोसेस को बाद में फिर से आज़माया जा सकता है.