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

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

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

A/B OTAs बेहतर क्यों हैं?

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

system_other क्या है?

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

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

.odex	1391770312 बाइट	50.5%
.apk	846878259 बाइट	30.7%
.so (नेटिव C/C++ कोड)	20,216,2479 बाइट	7.3%
.oat फ़ाइलें/.art इमेज	163892188 बाइट	5.9%
फ़ॉन्ट	38,952,361 बाइट	1.4%
icu locale data	27468687 बाइट	0.9%

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

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

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

इन मुख्य वजहों से, तुलना करना मुश्किल है:

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

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

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

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

OtaDexoptService (frameworks/base/+/android16-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-release/services/core/java/com/android/server/pm/PackageManagerService.java#7215) इस प्रोसेस को मैनेज करता है. नया सिस्टम बूट होने के बाद, installd (frameworks/native/+/android16-release/cmds/installd/dexopt.cpp#2422) उन .odex फ़ाइलों को हटा सकता है जिनका इस्तेमाल पुराने सिस्टम ने किया था. इससे डिवाइस फिर से उस स्थिति में आ जाता है जहां सिर्फ़ एक कॉपी होती है.

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

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

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

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

नहीं. Pixel के सिस्टम इमेज साइज़ में कोई बदलाव नहीं हुआ है. इसमें सिर्फ़ जगह को दो सेक्शन में बांटा गया है.

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

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

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

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

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

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

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

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

नहीं. Android वेरिफ़ाइड बूट के लिए, ब्लॉक के हिसाब से अपडेट करना ज़रूरी है. हालांकि, इसके लिए A/B अपडेट करना ज़रूरी नहीं है.

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

नहीं.

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

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

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

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

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

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

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

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

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

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

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