Google APEX पर काम कर रहा है: सिस्टम लाइब्रेरी को मानक लिनक्स डिस्ट्रो की तरह अपडेट कर रहा है। Android Q में अपेक्षित, प्रोजेक्ट ट्रेबल के बाद APEX सबसे बड़ी चीज़ हो सकती है।
प्रोजेक्ट ट्रेबल की शुरुआत के बाद से APEX को लागू करना संभवतः Google के लिए सबसे बड़ा सिरदर्द है। APEX क्या है और इसके आने से Android कैसे बदल जाएगा?
एपेक्स के पीछे का विचार अपने आप में रोजमर्रा के जीएनयू/लिनक्स वितरण में आम है: लिनक्स लाइब्रेरी सेट के विशिष्ट अनुभागों को लक्षित करने वाले पैकेज अपडेट। लेकिन यह कुछ ऐसा है जिसे Google ने कभी करने की कोशिश नहीं की, यह देखते हुए कि एंड्रॉइड ने एक RO (रीड-ओनली) विभाजन का उपयोग किया है जहां सभी सिस्टम लाइब्रेरी और फ़्रेमवर्क को अधिकांश लिनक्स वितरणों में उपयोग किए जाने वाले सामान्य आरडब्ल्यू (रीड-राइट) विभाजनों की तुलना में संग्रहीत किया जाता है, जो मानक अपग्रेड प्रक्रिया को प्रस्तुत करता है अनुपयुक्त.
लाइब्रेरीज़ पूर्व-संकलित कोड हैं जिनका उपयोग अन्य प्रोग्रामों में किया जा सकता है। आमतौर पर उपयोग की जाने वाली विधियों को एंड्रॉइड ऐप्स पर कॉल करने के लिए लाइब्रेरी में बनाया जा सकता है, जिससे एपीके का आकार कम हो जाएगा क्योंकि एक ही कोड को कई ऐप्स में दोबारा लागू करने की आवश्यकता नहीं होगी। आप /system/lib और /system/lib64 निर्देशिकाओं में कई पूर्व-स्थापित सिस्टम लाइब्रेरी पा सकते हैं। एंड्रॉइड सिस्टम लाइब्रेरीज़ को आमतौर पर व्यक्तिगत रूप से अपडेट नहीं किया जाता है - बल्कि, उन्हें ओटीए अपडेट के माध्यम से एंड्रॉइड प्लेटफ़ॉर्म अपग्रेड के हिस्से के रूप में अपडेट किया जाता है। दूसरी ओर, लिनक्स डिस्ट्रोस में लाइब्रेरीज़ को व्यक्तिगत रूप से अपडेट किया जा सकता है। APEX की शुरुआत के साथ, एंड्रॉइड में सिस्टम लाइब्रेरीज़ को एंड्रॉइड ऐप्स की तरह व्यक्तिगत रूप से अपडेट किया जा सकता है। इसका मुख्य लाभ यह है कि ऐप डेवलपर्स पूर्ण सिस्टम अपग्रेड के लिए ओईएम की प्रतीक्षा किए बिना अपडेटेड लाइब्रेरी का लाभ उठा सकेंगे। आइए APEX कैसे काम करता है इसके बारे में अधिक तकनीकी विवरण जानें।
APEX पुस्तकालयों को अद्यतन करने के तरीके को कैसे बदलेगा?
APEX एक पारिस्थितिकी तंत्र है जिसने Google को उस तरीके पर पुनर्विचार करने के लिए मजबूर किया है (या मजबूर कर रहा है) जिस तरह से एंड्रॉइड / सिस्टम से अलग एक गैर-मानक विभाजन से सभी पुस्तकालयों और फ़ाइलों को लोड करता है।
सबसे पहले, हमें साझा लाइब्रेरी और स्थिर लाइब्रेरी के बीच अंतर निर्दिष्ट करना होगा। एक साझा लाइब्रेरी एक लाइब्रेरी है (आमतौर पर libkind.so नाम की एक फ़ाइल) जिसमें चलाने के लिए आवश्यक सभी कोड शामिल नहीं होते हैं लेकिन वास्तव में यह अन्य लाइब्रेरी से "लिंक" होता है कोड प्रदान करना, जबकि एक स्थिर पुस्तकालय, जैसा कि आप अनुमान लगा सकते हैं, एक पुस्तकालय है जो किसी भी अन्य पुस्तकालयों पर निर्भर नहीं करता है और इसमें सब कुछ स्थिर रूप से शामिल है फ़ाइल।
एंड्रॉइड ने ऐतिहासिक रूप से लाइब्रेरी पथ (लिनक्स दुनिया में LD_LIBRARY_PATH के रूप में जाना जाता है) को एक फ़ाइल के साथ कॉन्फ़िगर किया है बाइनरी या किसी अन्य द्वारा आवश्यक साझा पुस्तकालयों के लिए अनुमत खोज पथों को कॉन्फ़िगर करने के लिए ld.config.txt [0] कहा जाता है पुस्तकालय। ये पथ कॉन्फ़िगरेशन में हार्डकोड किए गए हैं और विस्तार योग्य नहीं हैं। यह लेआउट, जिसमें रीड-ओनली सिस्टम विभाजन भी शामिल है, जब तक कि उपयोगकर्ता ओटीए एंड्रॉइड अपडेट इंस्टॉल नहीं करता है, तब तक अपडेट न करने योग्य लाइब्रेरी की ओर ले जाता है। Google ने एकल APEX पैकेजों को अपने स्वयं के ld.config.txt प्रदान करने की अनुमति देकर खोज पथ का विस्तार करने की अनुमति देकर इस समस्या को ठीक किया, जिसमें उनमें शामिल अतिरिक्त (और अद्यतन) लाइब्रेरी पथ शामिल थे।
हालाँकि इस कदम ने मुख्य मुद्दों में से एक को ठीक कर दिया, फिर भी कुछ गंभीर मुद्दों पर काबू पाना बाकी था। सबसे पहले: एबीआई (एप्लिकेशन बाइनरी इंटरफ़ेस) स्थिरता। पुस्तकालयों को हमेशा इंटरफेस का एक स्थिर सेट निर्यात करना चाहिए ताकि अन्य ऐप्स और पुस्तकालय उन्नत लाइब्रेरी के साथ भी समान प्रोटोकॉल के साथ काम करना जारी रख सकें। Google APEXed पुस्तकालयों के बीच एक स्थिर C इंटरफ़ेस बनाने का प्रयास करके सक्रिय रूप से उस पर काम कर रहा है।
लेकिन APEX केवल पुस्तकालयों और बायनेरिज़ तक ही सीमित नहीं है। वास्तव में, इसमें कॉन्फ़िगरेशन फ़ाइलें, टाइमज़ोन अपडेट और कुछ जावा फ्रेमवर्क (लेखन के समय कॉन्स्क्रिप्ट) शामिल हो सकते हैं।
AOSP द्वारा प्रदान किए गए वर्तमान APEX पैकेजों के कुछ उदाहरण यहां दिए गए हैं:
- com.android.runtime: ART और बायोनिक रनटाइम (बाइनरिज़ और लाइब्रेरीज़)
- com.android.tzdata: टाइमज़ोन और आईसीयू डेटा (लाइब्रेरी और कॉन्फ़िगरेशन डेटा)
- com.android.resolv: नेटवर्क से संबंधित अनुरोधों को हल करने के लिए एंड्रॉइड द्वारा उपयोग की जाने वाली लाइब्रेरी (पुस्तकालय)
- com.android.conscrypt: एक जावा सुरक्षा प्रदाता (जावा फ्रेमवर्क)
APEX पैकेज कैसे स्थापित और संरचित किया जाता है?
एपेक्स पैकेज एक सरल ज़िप संग्रह है (एपीके की तरह) जिसे हमारे सुविधाजनक एडीबी द्वारा स्थापित किया जा सकता है (विकास के इस बिंदु पर) और, बाद में, उपयोगकर्ता द्वारा स्वयं एक पैकेज मैनेजर के माध्यम से (जैसे Google Play या मैन्युअल रूप से एंड्रॉइड पैकेज के माध्यम से)। इंस्टॉलर)।
ज़िप लेआउट इस प्रकार है:
आइए उसमें गोता लगाएँ।
Apex_manifest.json पैकेज का नाम और संस्करण निर्दिष्ट करता है।
Apex_payload.img एक माइक्रो-फ़ाइलसिस्टम छवि है (EXT4 के रूप में स्वरूपित)।
अन्य फ़ाइलें पैकेज को स्थापित करने के लिए उपयोग की जाने वाली सत्यापन प्रक्रिया का हिस्सा हैं। चलो देखते हैं।
की उपस्थिति AndroidManifest.xml, भले ही इसका उपयोग मुख्य रूप से अनुप्रयोगों में किया जाता है, हमें यह समझने में मदद करता है कि मानक एपीके इंस्टॉलेशन के लिए उपयोग किए जाने वाले अधिकांश कार्यान्वयन का इन पैकेजों के लिए भी पुन: उपयोग किया जाता है। वास्तव में, उनके बीच अंतर करने के लिए केवल एक्सटेंशन की जाँच की जा रही है।
मेटा-आईएनएफ/ निर्देशिका में पैकेज प्रमाणपत्र है और यह सामान्य एपीके के समान तंत्र का उपयोग करता है। तो ये पैकेज उपयोगकर्ता को अपडेट इंस्टॉल करने की अनुमति देने से पहले रनटाइम पर एक निजी/सार्वजनिक कुंजी जोड़ी द्वारा सत्यापित किया जाता है। लेकिन Google के लिए यह पर्याप्त नहीं था, इसलिए उन्होंने सुरक्षा की 2 और परतें जोड़ीं। वे छवि की अखंडता की जांच करने के लिए dm-verity और AVB (एंड्रॉइड सत्यापित बूट) सत्यापन का उपयोग कर रहे हैं ताकि यह सुनिश्चित हो सके कि छवि एक विश्वसनीय स्रोत से आई है। सबसे खराब स्थिति में, एपेक्स पैकेज अस्वीकार कर दिया जाएगा।
यदि सभी सत्यापन चरण सफल होते हैं, तो छवि को वैध के रूप में चिह्नित किया जाएगा और अगले रीबूट पर सिस्टम संस्करण को बदल दिया जाएगा।
बूट पर एक छवि कैसे स्थापित की जाती है?
आइए मेरे डिवाइस (एक एम्यूलेटर) पर वर्तमान में स्थापित APEXes पर एक नज़र डालकर शुरुआत करें
जैसा कि आप देख सकते हैं, पूर्व-स्थापित पैकेज /system/apex/ में संग्रहीत हैं और वे सभी वर्तमान में संस्करण संख्या 1 पर हैं। लेकिन जब एक APEX सक्रिय होता है तो क्या होता है? हम एक उदाहरण के रूप में फिर से com.android.tzdata का उपयोग करेंगे।
आइए डिवाइस को रीबूट करें और लॉगकैट का विश्लेषण करें।
पहली 2 पंक्तियाँ पैकेज की उत्पत्ति और यह कहाँ होगा यह समझने के लिए पर्याप्त जानकारी प्रदान करती हैं स्थापित: /apex/, Android Q में पेश की गई एक नई निर्देशिका जिसका उपयोग सक्रिय को संग्रहीत करने के लिए किया जाएगा संकुल.
पैकेज को AVB के साथ सफलतापूर्वक सत्यापित करने और सार्वजनिक कुंजी से मेल खाने के बाद, APEX को लूप डिवाइस का उपयोग करके /dev/block/loop0 पर माउंट किया जाता है, जिससे EXT4 फ़ाइल सिस्टम सिस्टम के लिए पहुंच योग्य हो जाता है। लूप डिवाइस एक छद्म डिवाइस है जो किसी फ़ाइल को ब्लॉक डिवाइस के रूप में एक्सेस करने योग्य बनाता है, जिससे उस फ़ाइल की सामग्री को माउंट पॉइंट के रूप में एक्सेस किया जा सकता है।
इस बिंदु पर, @1 प्रत्यय (जो पैकेज संस्करण को इंगित करता है) के कारण APEX का अभी भी उपयोग नहीं किया जाता है। अंततः सिस्टम को यह बताने के लिए कि हमारा पैकेज सफलतापूर्वक सक्रिय हो गया है, इसे /apex/com.android.tzdata पर बाइंड-माउंट किया जाएगा जहां Android सक्रिय रूप से tzdata के रहने की उम्मीद करता है। एक बाइंड माउंट एक मौजूदा निर्देशिका या फ़ाइल को एक अलग बिंदु के अंतर्गत ओवरले करता है। [1]
APEX कार्यान्वयन पूरी तरह से AOSP के तहत एकल भंडार में समाहित है। [2] एपेक्सड (एपेक्स डेमॉन) निर्देशिका में कोड एंड्रॉइड पर चल रहा है। एपेक्सर निर्देशिका में एपेक्स पैकेज बनाने के लिए बिल्ड सिस्टम द्वारा उपयोग किया जाने वाला कोड होता है।
उद्देश्य क्या है?
इस बिंदु पर, मैं केवल अनुमान लगा सकता हूं। मेरा सबसे अच्छा अनुमान यह है कि Google APEX पैकेजों का एक मुख्य सेट बनाने का प्रयास कर रहा है जिसे संभवतः बनाने के लिए Google द्वारा अद्यतन किया जा सकता है एंड्रॉइड का एक एकीकृत बेस कोर विक्रेताओं के बीच साझा किया गया, जिससे "सिस्टम" अपडेट केवल संभव हो गया, लेकिन एकल पैकेज का उपयोग किया गया अद्यतन.
क्या सभी डिवाइस APEX को सपोर्ट करेंगे?
नहीं, उदाहरण के लिए, एपेक्सडी को सभी एंड्रॉइड मॉड्यूल को अपडेट करने के लिए बूट के ठीक बाद /डेटा/एपेक्स की आवश्यकता होती है। FDE (पूर्ण-डिस्क एन्क्रिप्शन) के साथ, /data/apex को तब तक एन्क्रिप्ट किया जाता है जब तक कि उपयोगकर्ता द्वारा डिवाइस को अनलॉक नहीं किया जाता है, जिससे APEX मूल रूप से बेकार हो जाता है क्योंकि केवल सिस्टम APEX वेरिएंट को बूट पर लोड किया जाएगा। इसके अलावा, सभी डिवाइस को APEX का समर्थन करना चाहिए, लेकिन उन्हें कुछ कर्नेल पैच की आवश्यकता होती है (जिनमें से कई लूप डिवाइस के साथ खेलते समय Google द्वारा पाए गए फिक्स हैं)। [3] [4]
स्रोत [0], [1], [2], [3], [4]