वर्चुअल A/B की खास जानकारी

संग्रह की मदद से व्यवस्थित रहें अपनी प्राथमिकताओं के आधार पर, कॉन्टेंट को सेव करें और कैटगरी में बांटें.

वर्चुअल A/B, Android के अपडेट करने का मुख्य तरीका है. वर्चुअल A/B, लेगसी A/B अपडेट (A/B सिस्टम अपडेट देखें) और ऐसे अपडेट पर आधारित है जो A/B नहीं हैं. A/B अपडेट, अपडेट के लिए ज़्यादा जगह लेने की वजह से, 15 वर्शन में बंद कर दिए गए हैं.

असल में, वर्चुअल A/B में डाइनैमिक पार्टीशन के लिए कोई अतिरिक्त स्लॉट नहीं होता. डाइनैमिक पार्टीशन देखें. इसके बजाय, डेल्टा को स्नैपशॉट में लिखा जाता है. इसके बाद, डिवाइस के ठीक से बूट होने की पुष्टि करने के बाद, उसे बेस पार्टीशन में मर्ज कर दिया जाता है. वर्चुअल A/B, Android के लिए खास तौर पर बनाए गए स्नैपशॉट फ़ॉर्मैट का इस्तेमाल करता है. कंप्रेस किए गए स्नैपशॉट के लिए COW फ़ॉर्मैट देखें. इसकी मदद से, स्नैपशॉट को कंप्रेस किया जा सकता है और डिस्क के स्टोरेज का कम से कम इस्तेमाल किया जा सकता है. फ़ुल ओटीए में, कंप्रेस करने पर स्नैपशॉट का साइज़ करीब 45% कम हो जाता है. वहीं, इंक्रीमेंटल ओटीए में स्नैपशॉट का साइज़ करीब 55% कम हो जाता है.

Android 12 में, स्नैपशॉट किए गए सेगमेंट को कंप्रेस करने के लिए, वर्चुअल A/B कंप्रेशन का विकल्प मिलता है. वर्चुअल A/B से ये फ़ायदे मिलते हैं

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

बैकग्राउंड और शब्दावली

इस सेक्शन में, वर्चुअल A/B के साथ काम करने वाली टेक्नोलॉजी और शब्दावली के बारे में बताया गया है. ओटीए इंस्टॉलेशन के दौरान, नए ऑपरेटिंग सिस्टम का डेटा, फ़िज़िकल पार्टिशन के लिए नए स्लॉट में या Android के लिए बने किसी सीओडब्ल्यू डिवाइस में लिखा जाता है. डिवाइस को रीबूट करने के बाद, डाइनैमिक पार्टीशन का डेटा, dm-user और snapuserd डेमन का इस्तेमाल करके, उसके मूल डिवाइस में फिर से मर्ज हो जाता है. यह प्रोसेस पूरी तरह से उपयोगकर्ता के स्पेस में होती है.

Device-mapper

डिवाइस-मैपर, Linux की वर्चुअल ब्लॉक लेयर है. इसका इस्तेमाल Android में अक्सर किया जाता है. डाइनैमिक पार्टीशन की मदद से, /system जैसे पार्टीशन, लेयर वाले डिवाइसों का स्टैक होते हैं:

• स्टैक में सबसे नीचे, फ़िज़िकल सुपर पार्टीशन होता है. उदाहरण के लिए, /dev/block/by-name/super.
• बीच में एक dm-linear डिवाइस है, जो बताता है कि सुपर partition में कौनसे ब्लॉक, दिए गए डाइनैमिक partition को बनाते हैं. यह A/B डिवाइस पर /dev/block/mapper/system_[a|b] या A/B डिवाइस के अलावा किसी अन्य डिवाइस पर /dev/block/mapper/system के तौर पर दिखता है.
• सबसे ऊपर, dm-verity डिवाइस दिखता है. इसे पुष्टि किए गए पार्टीशन के लिए बनाया गया है. यह डिवाइस पुष्टि करता है कि dm-linear डिवाइस पर ब्लॉक सही तरीके से साइन किए गए हैं. यह /dev/block/mapper/system-verity के तौर पर दिखता है और /system माउंट पॉइंट का सोर्स होता है.

पहली इमेज में दिखाया गया है कि /system माउंट पॉइंट के नीचे मौजूद स्टैक कैसा दिखता है.

पहली इमेज. /system माउंट पॉइंट के नीचे स्टैक

कंप्रेस किए गए स्नैपशॉट

Android 12 और उसके बाद के वर्शन में, /data partition में जगह की ज़रूरत ज़्यादा हो सकती है. इसलिए, /data partition में जगह की ज़्यादा ज़रूरत को पूरा करने के लिए, अपने बिल्ड में कंप्रेस किए गए स्नैपशॉट चालू किए जा सकते हैं.

वर्चुअल A/B कंप्रेस किए गए स्नैपशॉट, Android 12 और उसके बाद के वर्शन में उपलब्ध इन कॉम्पोनेंट के आधार पर बनाए जाते हैं:

• dm-user, FUSE जैसा एक कर्नेल मॉड्यूल है. इससे उपयोगकर्ता स्पेस को ब्लॉक डिवाइसों को लागू करने की अनुमति मिलती है.
• snapuserd, नया स्नैपशॉट फ़ॉर्मैट लागू करने के लिए, उपयोगकर्ता स्पेस डेमन.

ये कॉम्पोनेंट, कंप्रेस करने की सुविधा चालू करते हैं. कंप्रेस किए गए स्नैपशॉट की सुविधाओं को लागू करने के लिए किए गए अन्य ज़रूरी बदलावों के बारे में अगले सेक्शन में बताया गया है: कंप्रेस किए गए स्नैपशॉट के लिए COW फ़ॉर्मैट, dm-user, और snapuserd.

कंप्रेस किए गए स्नैपशॉट के लिए COW फ़ॉर्मैट

Android 12 और उसके बाद के वर्शन में, कंप्रेस किए गए स्नैपशॉट, Android के लिए खास तौर पर बनाए गए COW फ़ॉर्मैट का इस्तेमाल करते हैं. COW फ़ॉर्मैट में, ओटीए के बारे में मेटाडेटा होता है. साथ ही, इसमें अलग-अलग बफ़र होते हैं, जिनमें COW ऑपरेशन और नए ऑपरेटिंग सिस्टम का डेटा होता है. Android के कंप्रेस किए गए स्नैपशॉट के COW फ़ॉर्मैट की तुलना में, कर्नेल स्नैपशॉट फ़ॉर्मैट में सिर्फ़ बदलने वाले ऑपरेशन (बेस इमेज में ब्लॉक X को स्नैपशॉट में ब्लॉक Y के कॉन्टेंट से बदलना) की अनुमति होती है. हालांकि, Android के कंप्रेस किए गए स्नैपशॉट के COW फ़ॉर्मैट में ज़्यादा काम किए जा सकते हैं. साथ ही, यह इन ऑपरेशन के साथ काम करता है:

• कॉपी करें: बेस डिवाइस में ब्लॉक X को, बेस डिवाइस में ब्लॉक Y से बदला जाना चाहिए.
• बदलें: बेस डिवाइस में मौजूद ब्लॉक X को स्नैपशॉट में मौजूद ब्लॉक Y के कॉन्टेंट से बदला जाना चाहिए. इनमें से हर ब्लॉक को gz से कंप्रेस किया गया है.
• शून्य: बेस डिवाइस में ब्लॉक X को सभी शून्य से बदल दिया जाना चाहिए.
• XOR: COW डिवाइस, ब्लॉक X और ब्लॉक Y के बीच XOR से कंप्रेस किए गए बाइट सेव करता है. (यह सुविधा Android 13 और उसके बाद के वर्शन में उपलब्ध है.)

ओटीए के ज़रिए किए जाने वाले पूरे अपडेट में, सिर्फ़ बदलें और शून्य ऑपरेशन शामिल होते हैं. इंक्रीमेंटल ओटीए अपडेट में, कॉपी करने की कार्रवाइयां भी हो सकती हैं.

डिस्क पर फ़ुल स्नैपशॉट लेआउट कुछ ऐसा दिखता है:

दूसरी इमेज. डिस्क पर Android COW फ़ॉर्मैट

dm-user

dm-user kernel module की मदद से, userspace डिवाइस-मैपर ब्लॉक डिवाइसों को लागू कर सकता है. dm-user टेबल की एंट्री, /dev/dm-user/<control-name> के तहत अन्य डिवाइस बनाती है. userspace प्रोसेस, डिवाइस को पोल कर सकती है, ताकि वह कर्नेल से पढ़ने और लिखने के अनुरोध पा सके. हर अनुरोध के लिए, उपयोगकर्ता स्पेस से जुड़ा एक बफ़र होता है, ताकि डेटा पढ़ने के लिए उसे पॉप्युलेट किया जा सके या लिखने के लिए उसे प्रोपेगेट किया जा सके.

dm-user कर्नेल मॉड्यूल, कर्नेल के लिए एक नया यूज़र-विज़िबल इंटरफ़ेस उपलब्ध कराता है. यह इंटरफ़ेस, अपस्ट्रीम kernel.org कोड बेस का हिस्सा नहीं है. जब तक ऐसा नहीं होता, तब तक Google के पास Android में dm-user इंटरफ़ेस में बदलाव करने का अधिकार सुरक्षित है.

snapuserd

snapuserd से dm-user तक का यूज़रस्पेस कॉम्पोनेंट, वर्चुअल A/B compression लागू करता है. Snapuserd, यूज़रस्पेस डेमन है. यह Android COW डिवाइसों में डेटा लिखने और पढ़ने का काम करता है. स्नैपशॉट के लिए सभी I/O, इस सेवा से होने चाहिए. ओटीए इंस्टॉलेशन के दौरान, नए ऑपरेटिंग सिस्टम का डेटा, स्नैपशॉट में लिखा जाता है. ऐसा, स्नैपयूज़र्ड की मदद से किया जाता है. यहां मेटाडेटा को पार्स करने और नए ब्लॉक डेटा को अनपैक करने की प्रोसेस भी मैनेज की जाती है.

XOR कम्प्रेशन

Android 13 और इसके बाद के वर्शन वाले डिवाइसों के लिए, डिफ़ॉल्ट रूप से चालू रहने वाली एक्सओआर कंप्रेसन की सुविधा, यूज़रस्पेस स्नैपशॉट को चालू करती है. इससे, पुराने ब्लॉक और नए ब्लॉक के बीच एक्सओआर कंप्रेस किए गए बाइट को स्टोर किया जा सकता है. जब वर्चुअल A/B अपडेट में किसी ब्लॉक में सिर्फ़ कुछ बाइट बदले जाते हैं, तो XOR कंप्रेसन स्टोरेज स्कीम, डिफ़ॉल्ट स्टोरेज स्कीम की तुलना में कम जगह का इस्तेमाल करता है. ऐसा इसलिए होता है, क्योंकि स्नैपशॉट में पूरे 4K बाइट स्टोर नहीं होते. स्नैपशॉट के साइज़ में यह कमी इसलिए आती है, क्योंकि XOR डेटा में कई शून्य होते हैं और इसे रॉ ब्लॉक डेटा के मुकाबले आसानी से कंप्रेस किया जा सकता है. Pixel डिवाइसों पर, XOR कंप्रेसन की सुविधा से स्नैपशॉट का साइज़ 25% से 40% तक कम हो जाता है.

Android 13 और उसके बाद के वर्शन पर अपग्रेड करने वाले डिवाइसों के लिए, XOR compression चालू होना चाहिए. ज़्यादा जानकारी के लिए, XOR कंप्रेसन देखें.

स्नैपशॉट मर्ज करना

Android 13 और उसके बाद के वर्शन वाले डिवाइसों के लिए, वर्चुअल A/B कंप्रेसन में स्नैपशॉट और स्नैपशॉट मर्ज करने की प्रोसेस, snapuserd यूज़रस्पेस कॉम्पोनेंट की मदद से की जाती है. Android 13 और उसके बाद के वर्शन पर अपग्रेड करने वाले डिवाइसों के लिए, यह सुविधा चालू होनी चाहिए. ज़्यादा जानकारी के लिए, Userspace को मर्ज करना लेख पढ़ें.

वर्चुअल A/B कंप्रेसन प्रोसेस के बारे में यहां बताया गया है:

1. फ़्रेमवर्क, dm-verity डिवाइस के /system पार्टीशन को माउंट करता है, जो dm-user डिवाइस के ऊपर स्टैक किया गया है. इसका मतलब है कि रूट फ़ाइल सिस्टम से हर I/O को dm-user पर भेजा जाता है.
2. dm-user, I/O को यूज़रस्पेस snapuserd डेमन पर भेजता है, जो I/O अनुरोध को मैनेज करता है.
3. मर्ज करने की प्रोसेस पूरी होने के बाद, फ़्रेमवर्क dm-linear (system_base) के ऊपर dm-verity को छोटा कर देता है और dm-user को हटा देता है.

तीसरी इमेज. वर्चुअल A/B कंप्रेसन प्रोसेस

स्नैपशॉट मर्ज करने की प्रोसेस में रुकावट आ सकती है. अगर मर्ज करने की प्रोसेस के दौरान डिवाइस को रीबूट किया जाता है, तो रीबूट होने के बाद मर्ज करने की प्रोसेस फिर से शुरू हो जाती है.

ट्रांज़िशन शुरू करना

कंप्रेस किए गए स्नैपशॉट से बूट करते समय, snapuserd को माउंट करने के लिए, पहले चरण का init शुरू होना चाहिए. इससे एक समस्या आती है: जब sepolicy को लोड और लागू किया जाता है, तो snapuserd को गलत कॉन्टेक्स्ट में डाल दिया जाता है. साथ ही, selinux के अस्वीकार करने की वजह से, इसके पढ़ने के अनुरोध पूरे नहीं होते.

इस समस्या को ठीक करने के लिए, snapuserd init के साथ लॉक-स्टेप में ट्रांज़िशन करता है. इसके लिए, यह तरीका अपनाएं:

1. पहले चरण में init, रैमडिस्क से snapuserd को लॉन्च करता है और किसी एनवायरमेंट वैरिएबल में, खुली फ़ाइल-डिस्क्रिप्टर को सेव करता है.
2. पहले चरण में init, रूट फ़ाइल सिस्टम को सिस्टम पार्टीशन पर स्विच करता है. इसके बाद, init की सिस्टम कॉपी को चलाता है.
3. init की सिस्टम कॉपी, स्ट्रिंग में जोड़ी गई sepolicy को पढ़ती है.
4. Init, ext4 फ़ाइल सिस्टम वाले सभी पेजों पर mlock() को चालू करता है. इसके बाद, यह स्नैपशॉट डिवाइसों के लिए सभी डिवाइस-मैपर टेबल बंद कर देता है और snapuserd को बंद कर देता है. इसके बाद, डिवाइस के अलग-अलग हिस्सों से पढ़ने की अनुमति नहीं है. ऐसा करने पर, डेटा को ऐक्सेस करने में रुकावट आती है.
5. snapuserd की ramdisk कॉपी के लिए ओपन डिस्क्रिप्टर का इस्तेमाल करके, init डेमन को सही selinux कॉन्टेक्स्ट के साथ फिर से लॉन्च करता है. स्नैपशॉट डिवाइसों के लिए, डिवाइस-मैपर टेबल फिर से चालू हो जाती हैं.
6. Init, munlockall() को कॉल करता है - फिर से आईओ करना सुरक्षित है.

स्पेस का इस्तेमाल

यहां दी गई टेबल में, Pixel के ओएस और ओटीए के साइज़ का इस्तेमाल करके, ओटीए के अलग-अलग तरीकों के लिए जगह के इस्तेमाल की तुलना की गई है.

साइज़ का असर	नॉन-A/B	A/B	वर्चुअल A/B	वर्चुअल A/B (कंप्रेस किया गया)
ओरिजनल फ़ैक्ट्री इमेज	4.5 जीबी सुपर (3.8 जीबी इमेज + 700 एमबी रिज़र्व)1	9 जीबी सुपर (दो स्लॉट के लिए, 3.8 जीबी + 700 एमबी रिज़र्व)	4.5 जीबी सुपर (3.8 जीबी इमेज + 700 एमबी रिज़र्व)	4.5 जीबी सुपर (3.8 जीबी इमेज + 700 एमबी रिज़र्व)
अन्य स्टैटिक पार्टीशन	/cache	कोई नहीं	कोई नहीं	कोई नहीं
ओटीए के दौरान अतिरिक्त स्टोरेज (ओटीए लागू करने के बाद वापस मिला स्टोरेज)	/data में 1.4 जीबी	0	/data पर 3.8 जीबी2	/data पर 2.1 जीबी2
ओटीए लागू करने के लिए ज़रूरी कुल स्टोरेज	5.9 जीबी3 (सुपर और डेटा)	9 जीबी (सुपर)	8.3 जीबी3 (सुपर और डेटा)	6.6 जीबी3 (सुपर और डेटा)

¹, पिक्सल मैपिंग के आधार पर अनुमानित लेआउट दिखाता है.

²यह मानता है कि नई सिस्टम इमेज का साइज़, ओरिजनल इमेज के साइज़ जैसा ही है.

³रिबूट होने तक, स्पेस की ज़रूरत नहीं होती.

Android 11 वर्चुअल A/B

वर्चुअल A/B के Android 11 ने Kernel COW फ़ॉर्मैट का इस्तेमाल करके, डाइनैमिक पार्टीशन में लिखा. बाद में, इसे बंद कर दिया गया, क्योंकि Kernel COW फ़ॉर्मैट में डेटा को कम नहीं किया जा सकता.

Android 12 वर्चुअल A/B

Android 12 में, Android के हिसाब से COW फ़ॉर्मैट में कंप्रेस किया जा सकता है. वर्चुअल A/B के इस वर्शन के लिए, Android के हिसाब से COW को Kernel COW फ़ॉर्मैट में बदलना ज़रूरी था. आखिरकार, इसे Android 13 में बदल दिया गया. इसकी वजह से, Kernel COW फ़ॉर्मैट और dm-snapshot पर निर्भरता खत्म हो गई.

वर्चुअल A/B लागू करने या कंप्रेस किए गए स्नैपशॉट की सुविधाओं का इस्तेमाल करने के लिए, वर्चुअल A/B लागू करना देखें