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

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

Device-mapper

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, और sSnapuserd.

कंप्रेस किए गए स्नैपशॉट के लिए 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 और उसके बाद के वर्शन में उपलब्ध है.)

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

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

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

एसडीएम-उपयोगकर्ता

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

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

snapuserd

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

XOR कंप्रेशन

Android 13 और उसके बाद के वर्शन वाले डिवाइसों के लिए, डिफ़ॉल्ट रूप से चालू रहने वाली एक्सओआर कंप्रेसन की सुविधा, यूज़रस्पेस स्नैपशॉट को चालू करती है. इससे, पुराने ब्लॉक और नए ब्लॉक के बीच एक्सओआर कंप्रेस किए गए बाइट को स्टोर किया जा सकता है. जब वर्चुअल A/B अपडेट में किसी ब्लॉक में सिर्फ़ कुछ बाइट बदले जाते हैं, तो XOR कंप्रेसन स्टोरेज स्कीम, डिफ़ॉल्ट स्टोरेज स्कीम की तुलना में कम जगह का इस्तेमाल करता है. ऐसा इसलिए होता है, क्योंकि स्नैपशॉट में पूरे 4K बाइट स्टोर नहीं होते. स्नैपशॉट के साइज़ में यह कमी मुमकिन है, क्योंकि XOR डेटा में कई शून्य होते हैं. साथ ही, रॉ डेटा की तुलना में 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 को शुरू करना चाहिए, ताकि पार्टीशन माउंट किए जा सकें. इस वजह से, समस्या आ सकती है: sepolicy के लोड होने और लागू होने पर, snapuserd को गलत कॉन्टेक्स्ट में डाल दिया जाता है. साथ ही, उसे पढ़ने के अनुरोध पूरे नहीं हो पाते हैं. इस वजह से, सर्वर के अनुरोध को अस्वीकार कर दिया जाता है.

इसे ठीक करने के लिए, 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.8G इमेज + 70 करोड़ रिज़र्व)	4.5 जीबी सुपर (3.8 जी इमेज + 700 एम बुक किया गया)
स्थैतिक विभाजन	/cache	कोई नहीं	कोई नहीं	कोई नहीं
ओटीए के दौरान अतिरिक्त स्टोरेज (ओटीए लागू करने के बाद वापस मिला स्टोरेज)	/data पर 1.4 जीबी	0	/data पर 3.8 जीबी2	/data पर 2.1 जीबी2
ओटीए लागू करने के लिए ज़रूरी कुल स्टोरेज	5.9 जीबी3 (सुपर और डेटा)	9 जीबी (सुपर)	8.3GB3 (सुपर और डेटा)	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 लागू करना देखें