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

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

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

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

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

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

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

डिवाइस-मैपर

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

• स्टैक में सबसे नीचे, फ़िज़िकल सुपर पार्टीशन होता है. उदाहरण के लिए, /dev/block/by-name/super.
• बीच में dm-linear डिवाइस है. इससे पता चलता है कि सुपर पार्टिशन के कौनसे ब्लॉक, दिए गए डाइनैमिक पार्टिशन को बनाते हैं. यह 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 पार्टीशन पर ज़्यादा जगह की ज़रूरत हो सकती है. इसलिए, /data पार्टीशन की ज़्यादा जगह की ज़रूरत को पूरा करने के लिए, अपने बिल्ड में कंप्रेस किए गए स्नैपशॉट की सुविधा चालू की जा सकती है.

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

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

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

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

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

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

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

डिस्क पर मौजूद पूरे स्नैपशॉट का लेआउट ऐसा दिखता है:

दूसरी इमेज. Android COW Format on Disk

dm-user

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

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

snapuserd

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

XOR कंप्रेशन

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

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

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

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

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

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

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

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

Init transitions

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

इस समस्या को हल करने के लिए, snapuserd init के साथ-साथ इन बदलावों को लागू करता है:

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

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

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

साइज़ पर असर	नॉन-ए/बी	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	3.8 जीबी2 on /data	2.1GB2 on /data
OTA अपडेट के लिए ज़रूरी कुल स्टोरेज	5.9 जीबी3 (सुपर और डेटा)	9 जीबी (सुपर)	8.3 जीबी3 (सुपर और डेटा)	6.6 जीबी3 (सुपर और डेटा)

¹यह Pixel मैपिंग के आधार पर तय किया गया लेआउट दिखाता है.

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

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

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

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

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

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

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