Google की जेनेरिक कर्नेल छवि एंड्रॉइड की विखंडन समस्या को हल करने की दिशा में अगला कदम है

Google वर्षों से एंड्रॉइड पर विखंडन को कम करने पर काम कर रहा है, हालांकि इसका एक कारण एंड्रॉइड की अंतर्निहित प्रकृति और पसंद और स्वतंत्रता की दोधारी तलवार है। इस क्षेत्र में अनगिनत OEM सक्रिय हैं, और वे सभी अपने स्वयं के उपकरणों के लिए अपना स्वयं का संशोधन करना चाहते हैं। समस्या यह है कि ऐसा लगता है कि एंड्रॉइड ओएस अपडेट को बोर्ड भर में रोल आउट करने में धीमी गति से है, लेकिन Google वास्तव में OEM को अपने डिवाइस को अपडेट करने के लिए मजबूर करने के लिए बहुत कुछ नहीं कर सकता है। इस प्रकार, अगली सबसे अच्छी चीज़ जो Google कर सकता है वह है अपडेट प्रक्रिया को यथासंभव आसान और बाधा रहित बनाना।

एंड्रॉइड अपडेट की परेशानी को कम करना

विकास के बोझ को कम करने के लिए Google की दीर्घकालिक परियोजना में पहली बड़ी पहल थी प्रोजेक्ट ट्रेबल. 2017 में एंड्रॉइड 8.0 ओरेओ के साथ घोषित, प्रोजेक्ट ट्रेबल ने ओएस फ्रेमवर्क को विक्रेता कार्यान्वयन (एचएएल और डिवाइस-विशिष्ट लिनक्स कर्नेल फोर्क) से अलग करके एंड्रॉइड को मॉड्यूलर किया। इससे एंड्रॉइड ओईएम के लिए नवीनतम एओएसपी फ्रेमवर्क के शीर्ष पर अपने ओएस को रीबेस करना आसान हो गया, क्योंकि वे विक्रेताओं से अद्यतन कोड की आवश्यकता के बिना नवीनतम संस्करण को बूट कर सकते थे। परिणामस्वरूप, ओईएम अपने कस्टम एंड्रॉइड फोर्क्स को पहले की तुलना में तेजी से तैयार कर सकते हैं, और विस्तार से, प्रमुख ओएस अपडेट को और अधिक तेजी से रोल आउट कर सकते हैं।

Google की योजनाओं में अगला कदम प्रमुख एंड्रॉइड घटकों के लिए अपडेट की डिलीवरी को सुव्यवस्थित करना था। गूगल ने इस पहल को नाम दिया है प्रोजेक्ट मेनलाइन जब इसने 2019 में इसे एंड्रॉइड 10 के साथ पेश किया। Google ने अनिवार्य रूप से प्रमुख OS घटकों पर नियंत्रण कर लिया और OEM को उन्हें संशोधित करने से रोक दिया। फिर उन्होंने Google Play के माध्यम से एक वितरण तंत्र स्थापित किया ताकि वे OEM द्वारा स्वयं पैच लागू करने की प्रतीक्षा किए बिना इन प्रमुख घटकों के लिए दूरस्थ रूप से अपडेट रोल आउट कर सकें। मेनलाइन ने इस बात में काफी सुधार किया कि डिवाइस कितनी जल्दी महत्वपूर्ण ओएस घटकों के अद्यतन संस्करण प्राप्त करते हैं, जिससे समग्र रूप से एंड्रॉइड पारिस्थितिकी तंत्र की सुरक्षा में सुधार होता है।

हालाँकि, जब ट्रेबल की बात आती है, तो वास्तव में लिनक्स कर्नेल को बंद-स्रोत विक्रेता कोड के साथ नहीं जोड़ा जाना चाहिए। टोड कजोस पर इस वर्ष का लिनक्स प्लंबर सम्मेलन अतीत में एंड्रॉइड पर विखंडन की बात आने पर आने वाली कठिनाइयों के बारे में बताया गया है, और अब इसका अधिकांश हिस्सा लिनक्स कर्नेल के आसपास केंद्रित है जिसे ओईएम अपने उपकरणों के साथ शिप करते हैं। संदर्भ के लिए, Google प्रत्येक मेनलाइन लिनक्स कर्नेल को "एंड्रॉइड कॉमन कर्नेल(एसीके) शाखा, जो मेनलाइन रिलीज़ को बारीकी से ट्रैक करती है लेकिन कुछ एंड्रॉइड-विशिष्ट पैच जोड़ती है। क्वालकॉम, मीडियाटेक और सैमसंग जैसे एसओसी विक्रेता फिर कांटा लगाते हैं वह उनके द्वारा बनाए गए प्रत्येक SoC के लिए कर्नेल। फिर OEM उस SoC-विशिष्ट कर्नेल को लेते हैं और उस विशिष्ट हार्डवेयर के लिए समर्थन लागू करने के लिए अतिरिक्त पैच जोड़ते हैं जिसे वे शिप करना चाहते हैं।

उपरोक्त आरेख दिखाता है कि कैसे एक डिवाइस का कर्नेल परिवर्तन की कई परतों से गुजरता है जो इसे लिनक्स एलटीएस कर्नेल से दूर कर देता है। इसे सरल बनाने के लिए, हम लिनक्स कर्नेल से शुरू करते हैं, और यह कुछ बदलावों के साथ एंड्रॉइड कॉमन कर्नेल में विलय हो जाता है। वहां से, एंड्रॉइड कॉमन कर्नेल अपने स्वयं के संशोधनों और परिवर्तनों के साथ एक विक्रेता कर्नेल (क्वालकॉम, मीडियाटेक, आदि) में विलय हो जाता है। अंत में, विक्रेता कर्नेल को OEM के डिवाइस-विशिष्ट कर्नेल में विलय कर दिया जाता है। इस चरण तक, किसी एक डिवाइस का कर्नेल उस Linux LTS कर्नेल से बहुत दूर हो जाता है जिसके साथ इसकी शुरुआत हुई थी।

उन सभी फोर्क्स के परिणामस्वरूप, एंड्रॉइड डिवाइस पर चलने वाले 50% से अधिक कोड आउट-ऑफ-ट्री कोड हैं, जिसका अर्थ है कि यह अपस्ट्रीम लिनक्स या एओएसपी सामान्य कर्नेल से नहीं है। इससे अपस्ट्रीम परिवर्तनों को मर्ज करना अविश्वसनीय रूप से कठिन (समय लेने वाली और महंगा होने का उल्लेख नहीं) हो जाता है। ओईएम के लिए, ऐसा करने के लिए कोई प्रोत्साहन नहीं है, लेकिन यह अभ्यास डिवाइस सुरक्षा के लिए हानिकारक हो सकता है। यही कारण है कि बहुत सारे एंड्रॉइड डिवाइस पुराने एलटीएस कर्नेल रिलीज पर छोड़ दिए जाते हैं, जिसका दुष्प्रभाव यह होता है कि डिवाइस नई लिनक्स कर्नेल सुविधाओं तक पहुंच खो देते हैं।

एंड्रॉइड खंडित है, और Google इसे जानता है

Google अच्छी तरह से जानता है कि यह एक समस्या है, और उसके पास "" नामक एक अनुभाग भी है।विखंडन की लागत"एंड्रॉइड डेवलपर दस्तावेज़ में। गूगल ऐसा कहता है "अधिकांश फ्लैगशिप डिवाइस कर्नेल संस्करण के साथ आते हैं जो पहले से ही कम से कम 18 महीने पुराना है". इससे भी बुरी बात यह है कि गूगल भी यही कहता है "एंड्रॉइड 10 3.18, 4.4, 4.9, 4.14 और 4.19 कर्नेल को सपोर्ट करता है, जिसे कुछ मामलों में 2017 में एंड्रॉइड 8 के बाद से नई सुविधाओं के साथ नहीं बढ़ाया गया है।" इससे उन सुविधाओं को जोड़ना मुश्किल हो जाता है जिनके लिए नए लिनक्स कर्नेल संस्करणों की आवश्यकता होती है। लिनक्स कर्नेल 3.18 दिसंबर 2014 में लॉन्च किया गया था, जब एंड्रॉइड 5.0 लॉलीपॉप एंड्रॉइड का नवीनतम संस्करण था। यह स्पष्ट रूप से एक समस्या है और प्लेटफ़ॉर्म को पीछे खींच सकती है।

उदाहरण के लिए, कोड ऑरोरा फ़ोरम, या संक्षेप में CAF, विभिन्न क्वालकॉम स्नैपड्रैगन SoCs के लिए स्रोत कोड को होस्ट करता है। क्वालकॉम, एक SoC के रूप में विक्रेता, OEM/ODMs को लिनक्स कर्नेल का एक फोर्क्ड संस्करण वितरित करता है, और फिर वे कंपनियां शिपिंग पर डिवाइस-विशिष्ट परिवर्तन जोड़ती हैं उपकरण। यही विखंडन की कई परतें जोड़ता है। इसके अलावा, क्वालकॉम कंपनी के प्रत्येक स्नैपड्रैगन मोबाइल प्लेटफॉर्म के लिए एंड्रॉइड को अनुकूलित करने के लिए एओएसपी ढांचे में बदलाव करता है। क्वालकॉम निजी तौर पर अपने संशोधित लिनक्स कर्नेल, एओएसपी फ्रेमवर्क और अन्य सॉफ्टवेयर टूल को बोर्ड सपोर्ट पैकेज या बीएसपी के हिस्से के रूप में अपने भागीदारों को वितरित करता है। सीएएफ वह जगह है जहां क्वालकॉम इन लिनक्स कर्नेल परिवर्तनों और एओएसपी फ्रेमवर्क परिवर्तनों को सार्वजनिक रूप से प्रकाशित करता है।

यह CAF रिलीज़ कस्टम ROM डेवलपर्स के लिए उपयोगी हो सकता है जो इसे शुद्ध AOSP के बजाय शुरुआती बिंदु के रूप में उपयोग करना चाहते हैं, यही कारण है कि आप कभी-कभी देखते हैं हमारे मंचों पर "सीएएफ-आधारित" रोम. क्या आपको स्नैपड्रैगन 625 याद है जो सालों तक कई मिड-रेंज स्मार्टफोन को पावर देता रहा? यह लिनक्स कर्नेल 3.18 के साथ लॉन्च हुआ, और केवल 2018 के अंत में (चिपसेट लॉन्च होने के दो साल बाद) क्वालकॉम ने कर्नेल स्रोतों को अपडेट किया और उन्हें प्रकाशित किया सीएएफ एमएसएम8953 (स्नैपड्रैगन 625 का चिपसेट नाम) के लिए लिनक्स कर्नेल 4.9 के लिए समर्थन ला रहा है। समस्या यह है कि अधिकांश ओ.ई.एम चिप के दो साल बाद इस नए लिनक्स कर्नेल संस्करण में फोन को अपडेट नहीं किया जाएगा, खासकर मध्य-श्रेणी के फोन को नहीं जारी किया। माना कि, इस तरह का कोई बड़ा कर्नेल अपडेट पहली बार में ही होना बहुत दुर्लभ है, लेकिन मुद्दा यह है कि यह है हुआ, इसलिए यह सिर्फ एक असंभव परिदृश्य नहीं है।

कुल मिलाकर, हल्के ढंग से कहें तो एंड्रॉइड में वर्तमान विखंडन एक गड़बड़ है। उस विखंडन को ठीक करने के लिए Google के नवीनतम प्रयास जेनेरिक कर्नेल इमेज या GKI के रूप में आते हैं।

जेनेरिक कर्नेल छवि का परिचय

इस विखंडन को संबोधित करने के लिए, Google ने Android जेनेरिक कर्नेल इमेज (GKI) पर काम किया। यह अनिवार्य रूप से एक ACK शाखा से सीधे संकलित कर्नेल है। GKI SoC विक्रेता और OEM अनुकूलन को प्लगइन मॉड्यूल से अलग करता है, आउट-ऑफ-ट्री कोड को समाप्त करता है और Google को कर्नेल अपडेट को सीधे अंतिम उपयोगकर्ता तक पहुंचाने की अनुमति देता है। एक वर्ष से अधिक समय से, Google Play Store के माध्यम से GKI अपडेट वितरित करने के तरीके पर काम कर रहा है, मेनलाइन मॉड्यूल के उपयोग के माध्यम से.

परिणामस्वरूप, एंड्रॉइड 12 के साथ लॉन्च होने वाले डिवाइस जो लिनक्स कर्नेल 5.10.43 या उच्चतर चलाते हैं, उन्हें निम्नलिखित में से एक करना होगा, मिशाल रहमान के अनुसार.

• Google-हस्ताक्षरित बूट छवि परिनियोजित करें

या

• कर्नेल के साथ एक बूट छवि तैनात करें जो KMI (कर्नेल मॉड्यूल इंटरफ़ेस) निर्यात करती है जो GKI द्वारा निर्यात किए गए KMI का एक सबसेट है, एक यूजरस्पेस एपीआई निर्यात करता है जो जीकेआई द्वारा उजागर यूएपीआई का एक सुपरसेट है, और संबंधित जीकेआई की सभी सुविधाओं का समर्थन करता है संस्करण

विक्रेता ऐसे मॉड्यूल बना सकते हैं जो GKI में प्लग होते हैं, लेकिन GKI का विचार यह है कि Google कर्नेल परिवर्तनों को संभालने की जिम्मेदारी लेता है। कर्नेल मॉड्यूल इंटरफ़ेस (या KMI, लेख के बाद के हिस्सों में इस पर अधिक जानकारी) प्रभावी रूप से वह जगह है जहां आउट-ऑफ़-ट्री कोड जाने की उम्मीद है।

Google Pixel 6 सीरीज़ एंड्रॉइड 12 के साथ लॉन्च हुई और लिनक्स कर्नेल 5.10 के साथ आती है, और यह GKI के साथ आने वाला पहला फोन है। क्योंकि Google संभावित रूप से प्ले स्टोर के माध्यम से कर्नेल को अपडेट कर सकता है, हम बार-बार कर्नेल अपडेट भी देख सकते हैं, क्योंकि एलटीएस कर्नेल अपडेट आम तौर पर साप्ताहिक रूप से जारी किए जाते हैं. किसी भी तरह से, यह ओटीए के माध्यम से अद्यतन करने की वर्तमान-बोझिल विधि की तुलना में बहुत बेहतर प्रणाली है, हालांकि इसका मतलब यह है कि यह स्वाभाविक रूप से जीएमएस ढांचे से जुड़ा हुआ है।

Google GKI को बस निम्नलिखित के रूप में परिभाषित करता है:

• इसे ACK स्रोतों से बनाया गया है।
• यह एक एकल-कर्नेल बाइनरी प्लस संबद्ध लोड करने योग्य मॉड्यूल प्रति आर्किटेक्चर, प्रति एलटीएस रिलीज़ है (वर्तमान में केवल आर्म64 के लिए) android11-5.4 और android12-5.4).
• इसका परीक्षण उन सभी Android प्लेटफ़ॉर्म रिलीज़ों के साथ किया गया है जो संबंधित ACK के लिए समर्थित हैं। GKI कर्नेल संस्करण के जीवनकाल के लिए कोई सुविधा बहिष्करण नहीं है
• यह किसी दिए गए LTS के भीतर ड्राइवरों को एक स्थिर KMI दिखाता है।
• इसमें SoC या बोर्ड-विशिष्ट कोड शामिल नहीं है।

Google 2023 तक ऐसी स्थिति में आना चाहता है जहां वह "अपस्ट्रीम फर्स्ट" विकास मॉडल अपना सके। इससे Google को यह सुनिश्चित करने में मदद मिलेगी कि नया कोड पहले मेनलाइन लिनक्स कर्नेल में आएगा, जिससे एंड्रॉइड डिवाइस पर आउट-ऑफ-ट्री कोड पर जमा होने वाले "तकनीकी ऋण" में कमी आएगी।

कर्नेल मॉड्यूल इंटरफ़ेस (KMI)

कर्नेल मॉड्यूल इंटरफ़ेस, या KMI, Android में चल रहे विखंडन के लिए Google के समाधान का हिस्सा है। संक्षेप में, एसओसी और बोर्ड समर्थन अब कोर कर्नेल में स्थित नहीं हैं और इसके बजाय लोड करने योग्य मॉड्यूल में स्थानांतरित हो गए हैं। कर्नेल और मॉड्यूल दोनों को स्वतंत्र रूप से अपडेट किया जा सकता है, जैसे मॉड्यूल अपडेट किए जाते हैं /lib/modules. जीकेआई को यथासंभव स्वच्छ और सामान्य माना जाता है, जो अब आउट-ऑफ-ट्री कोड को अलग-अलग मॉड्यूल में लोड करके संभव बनाया गया है।

टेड कजोस के रूप में पर समझाया गया इस साल के लिनक्स प्लंबर सम्मेलन में, "बड़ा बहु-वर्षीय प्रयास सभी हार्डवेयर-विशिष्ट कोड को जेनेरिक कर्नेल से बाहर और विक्रेता मॉड्यूल में लाना है। हमें उन विक्रेता मॉड्यूल और जेनेरिक कर्नेल के बीच एक स्थिर इंटरफ़ेस रखना होगा ताकि वे एसिंक्रोनस रूप से शिप कर सकें।" GKI 1.0 अनिवार्य रूप से एक "अनुपालन परीक्षण" है।

वास्तव में, जीकेआई अनुकूलता का मतलब है कि डिवाइस जेनेरिक सिस्टम इमेज (जीएसआई) के साथ वीटीएस और सीटीएस-ऑन-जीएसआई+जीकेआई परीक्षण पास करता है। और जीकेआई बूट छवि को बूट विभाजन में और जीएसआई सिस्टम छवि को सिस्टम में फ्लैश करके जीकेआई कर्नेल स्थापित किया गया है विभाजन. वेंडर टेस्ट सूट, या वीटीएस, एक स्वचालित परीक्षण है जिसे प्रोजेक्ट ट्रेबल के साथ संगत माने जाने के लिए सभी उपकरणों को पास करना होगा। Google के अनुप्रयोगों के सुइट तक पहुंचने के लिए संगतता परीक्षण सुइट या सीटीएस की आवश्यकता है।

डिवाइस एक अलग उत्पाद कर्नेल के साथ शिप कर सकते हैं और लोड करने योग्य मॉड्यूल का उपयोग कर सकते हैं जो जीकेआई प्रदान नहीं करता है। हालाँकि, उत्पाद और GKI कर्नेल दोनों को समान विक्रेता_बूट और विक्रेता विभाजन से मॉड्यूल लोड करना होगा। इसलिए, सभी उत्पाद कर्नेल में समान बाइनरी कर्नेल मॉड्यूल इंटरफ़ेस (KMI) होना आवश्यक है।

उपरोक्त चित्र दिखाता है कि Google क्या है चाहता हे करने के लिए, और बताता है कि उस तक पहुंचने का उसका इरादा कैसे है। जेनेरिक कर्नेल और जीकेआई मॉड्यूल एओएसपी का हिस्सा होंगे, और जीकेआई एंड्रॉइड फ्रेमवर्क और हार्डवेयर एब्स्ट्रैक्शन लेयर (एचएएल) के साथ संचार कर सकता है जिसे एक विक्रेता लागू कर सकता है। विशिष्ट मालिकाना कोड जो एक विक्रेता कर्नेल में चाहता है (उदाहरण के लिए, कैमरा ड्राइवर) को इसके बजाय एक विक्रेता मॉड्यूल में धकेल दिया जाएगा जो KMI के माध्यम से GKI का विस्तार बन जाता है।

GKI एंड्रॉइड की विखंडन समस्या को हल करने में कैसे मदद कर सकता है

Google स्मार्टफ़ोन की विकास प्रक्रिया को सुव्यवस्थित करने के लिए बहुत काम कर रहा है। प्रत्येक ओईएम अपनी स्वयं की ब्रांड पहचान चाहता है, और प्रत्येक ओईएम अपने उपकरणों का स्वामित्व रखने में सक्षम होना चाहता है। एंड्रॉइड वन प्रोग्राम के विपरीत, एंड्रॉइड स्मार्टफ़ोन लगभग वही हो सकते हैं जो वे चाहते हैं, जब तक कि वे जीएमएस लाइसेंस प्राप्त करने के लिए Google द्वारा निर्धारित नियमों के सेट का पालन करते हैं। हालाँकि, अतीत में, Google ने Android डिवाइस विकास में दबदबा बनाने के लिए बहुत कुछ नहीं किया है प्रोजेक्ट ट्रेबल, मेनलाइन और अब जीकेआई जैसे बदलाव एंड्रॉइड में हाल ही में आए हैं इतिहास।

लेकिन क्या इससे मदद मिलेगी? ऐसा करना चाहिए, हालाँकि यह एक बहु-वर्षीय मामला होने की संभावना है जिसका बाद में स्पष्ट फल मिलेगा। यह केवल एंड्रॉइड 12 के साथ लॉन्च होने वाले डिवाइस पर लागू होगा, जिसका अर्थ है कि हम आने वाले वर्षों में ऐसे डिवाइस देखेंगे जिनमें GKI नहीं है। जब इसकी घोषणा की गई थी तब यह प्रोजेक्ट ट्रेबल की भी आलोचना थी, हालांकि जाहिर तौर पर आजकल लॉन्च किए गए सभी डिवाइस इसका समर्थन करते हैं। इन चीज़ों में समय लगता है, और जैसे-जैसे Google धीरे-धीरे Android पर नियंत्रण स्थापित करता है, सभी OEM के लिए विकास प्रक्रिया आसान हो जाती है एंड्रॉइड पारिस्थितिकी तंत्र, भले ही उनमें से कुछ एंड्रॉइड पर उपयोग किए जाने वाले लिनक्स कर्नेल पर पूर्ण नियंत्रण बनाए रखना चाहेंगे स्मार्टफोन्स।