Android के शेयर किए गए सिस्टम की इमेज

इस पेज पर कई तरीके बताए गए हैं जिनका इस्तेमाल करके, Android डिवाइस बनाने वाली OEM कंपनियां, अपनी सभी प्रॉडक्ट लाइन में, शेयर की गई सिस्टम इमेज (एसएसआई) का इस्तेमाल कर सकती हैं. इसमें, OEM के मालिकाना हक वाली एसएसआई को AOSP की ओर से बनाई गई सामान्य सिस्टम इमेज (जीएसआई) पर आधारित करने का तरीका भी बताया गया है.

बैकग्राउंड

Project Treble की मदद से, एक ही मॉनोलिथिक Android को दो हिस्सों में बांटा गया है: हार्डवेयर से जुड़ा हिस्सा (वेंडर लागू करना) और सामान्य ओएस हिस्सा (Android OS फ़्रेमवर्क). हर सिस्टम के लिए सॉफ़्टवेयर, अलग-अलग पार्टीशन में इंस्टॉल होता है: हार्डवेयर के हिसाब से सॉफ़्टवेयर के लिए वेंडर पार्टीशन और सामान्य ओएस सॉफ़्टवेयर के लिए सिस्टम पार्टीशन. वेंडर इंटरफ़ेस (VINTF) को वर्शन वाले इंटरफ़ेस के तौर पर परिभाषित किया गया है. इसे दोनों पार्टीशन में लागू किया जाता है. डिवाइस के स्टोरेज को अलग-अलग हिस्सों में बांटने वाले इस सिस्टम का इस्तेमाल करके, वेंडर के हिस्से में बदलाव किए बिना सिस्टम के हिस्से में बदलाव किया जा सकता है. इसके अलावा, वेंडर के हिस्से में बदलाव किए बिना सिस्टम के हिस्से में भी बदलाव किया जा सकता है.

वजह

AOSP में रिलीज़ किया गया फ़्रेमवर्क कोड, Treble के आर्किटेक्चर के मुताबिक है. साथ ही, यह वेंडर के पुराने वर्शन के साथ काम करता है. उदाहरण के लिए, Android 10 AOSP के सोर्स से बनाई गई सामान्य सिस्टम इमेज, Android 8 या उसके बाद के वर्शन पर काम करने वाले, Treble के साथ काम करने वाले किसी भी डिवाइस पर चल सकती है. उपभोक्ता के डिवाइसों पर शिप किए जाने वाले Android वर्शन में, SoC वेंडर और OEM बदलाव करते हैं. (Android रिलीज़ का लाइफ़ साइकल देखें.) फ़्रेमवर्क में किए गए ये बदलाव और एक्सटेंशन, पहले के वर्शन के साथ काम करने की सुविधा बनाए रखने के लिए नहीं किए गए थे. इस वजह से, ऑपरेटिंग सिस्टम को अपग्रेड करने में ज़्यादा समय और पैसे लगते हैं. डिवाइस के हिसाब से किए गए बदलाव और संशोधन, Android OS के वर्शन को अपग्रेड करने की लागत और जटिलता को बढ़ाते हैं.

Android 11 से पहले, ऐसा कोई आर्किटेक्चर नहीं था जिससे पार्टनर, Android OS फ़्रेमवर्क में मॉड्यूलर एक्सटेंशन बना सकें. इस दस्तावेज़ में, एसएसआई बनाने के लिए SoC वेंडर और OEMs के लिए ज़रूरी चरणों के बारे में बताया गया है. इसका मतलब है कि एक इमेज, कई डिवाइसों पर फिर से इस्तेमाल करने के लिए, Android OS फ़्रेमवर्क सोर्स से बनाई गई है. इससे, वेंडर के लागू किए गए वर्शन के साथ बैकवर्ड कम्पैटिबिलिटी बनाए रखने के साथ-साथ, Android OS के अपग्रेड की जटिलता और लागत को कम करने में मदद मिलती है. एसएसआई बनाने के लिए, जीएसआई पर आधारित एसएसआई के लिए सुझाए गए चरण सेक्शन देखें. ध्यान दें कि आपको चारों चरणों का इस्तेमाल करना ज़रूरी नहीं है. आपको कौनसे चरण चुनने हैं, यह इस बात पर निर्भर करता है कि आपने इसे कैसे लागू किया है. उदाहरण के लिए, सिर्फ़ पहला चरण.

एसएसआई की खास जानकारी

एसएसआई की मदद से, प्रॉडक्ट के हिसाब से सॉफ़्टवेयर कॉम्पोनेंट और OEM एक्सटेंशन को एक नए /product पार्टीशन में रखा जाता है. /product पार्टिशन में मौजूद कॉम्पोनेंट, /system पार्टिशन में मौजूद कॉम्पोनेंट के साथ इंटरैक्ट करने के लिए, अच्छी तरह से तय किए गए और स्थिर इंटरफ़ेस का इस्तेमाल करते हैं. OEM, एक एसएसआई बनाने का विकल्प चुन सकते हैं या एक से ज़्यादा डिवाइस SKU के लिए इस्तेमाल करने के लिए, कुछ एसएसआई बना सकते हैं. जब Android OS का नया वर्शन रिलीज़ होता है, तो OEM अपने एसएसआई को Android के नए वर्शन पर अपडेट करने के लिए सिर्फ़ एक बार खर्च करते हैं. वे /product पार्टीशन को अपडेट किए बिना, कई डिवाइसों को अपडेट करने के लिए एसएसआई का फिर से इस्तेमाल कर सकते हैं.

ध्यान दें कि OEM और SoC वेंडर, एसएसआई बनाते हैं. इनमें वे सभी कस्टम सुविधाएं और बदलाव शामिल होते हैं जिनकी किसी OEM को ज़रूरत होती है. इस पेज पर दिए गए तरीकों और सबसे सही तरीकों का मकसद, OEM को इन अहम लक्ष्यों को हासिल करने में मदद करना है:

• एक से ज़्यादा डिवाइसों के SKU के लिए, एसएसआई का फिर से इस्तेमाल करना.
• मॉड्यूलर एक्सटेंशन की मदद से, Android सिस्टम को अपडेट करें, ताकि ओएस को आसानी से अपग्रेड किया जा सके.

प्रॉडक्ट के हिसाब से कॉम्पोनेंट को प्रॉडक्ट के सेगमेंट में अलग करने का मुख्य आइडिया, SoC के हिसाब से कॉम्पोनेंट को वेंडर के सेगमेंट में अलग करने के Treble के आइडिया से मिलता-जुलता है. VINTF की तरह ही, प्रॉडक्ट इंटरफ़ेस की मदद से एसएसआई और प्रॉडक्ट पार्टीशन के बीच कम्यूनिकेशन किया जा सकता है. ध्यान दें कि एसएसआई के मामले में, “कॉम्पोनेंट” शब्द उन सभी रिसॉर्स, बाइनरी, टेक्स्ट, लाइब्रेरी वगैरह के बारे में बताता है जो इमेज में इंस्टॉल किए जाते हैं. ये इमेज, मुख्य रूप से पार्टीशन बन जाती हैं.

एसएसआई के आस-पास के पार्टीशन

पहली इमेज में, एसएसआई के पैर्टिशन और पैर्टिशन के हिसाब से वर्शन वाले इंटरफ़ेस दिखाए गए हैं. साथ ही, इंटरफ़ेस पर मौजूद नीतियां भी दिखाई गई हैं. इस सेक्शन में, हर सेगमेंट और इंटरफ़ेस के बारे में पूरी जानकारी दी गई है.

पहली इमेज. एसएसआई के आस-पास के पार्टीशन और इंटरफ़ेस

इमेज और पार्टीशन

इस सेक्शन में दी गई जानकारी से, इमेज और पार्टिशन शब्दों के बीच का अंतर पता चलता है.

• इमेज, सॉफ़्टवेयर का एक कॉन्सेप्ट है, जिसे अलग से अपडेट किया जा सकता है.
• पार्टिशन, स्टोरेज की एक जगह होती है. इसे अलग से अपडेट किया जा सकता है.

पहली इमेज में दिए गए सेक्शन इस तरह के हैं:

• एसएसआई: एसएसआई एक ऐसी इमेज होती है जो किसी OEM के लिए सामान्य होती है और एक से ज़्यादा डिवाइसों पर मौजूद हो सकती है. इसमें हार्डवेयर या प्रॉडक्ट के हिसाब से कोई कॉम्पोनेंट नहीं होना चाहिए. किसी एसएसआई में मौजूद सभी जानकारी, उस एसएसआई का इस्तेमाल करने वाले सभी डिवाइसों के साथ शेयर की जाती है. एसएसआई, एक /system इमेज या /system और /system_ext सेक्शन से बना होता है, जैसा कि पहली इमेज में दिखाया गया है.

  • /system पार्टीशन में AOSP पर आधारित कॉम्पोनेंट होते हैं. वहीं, /system_ext को लागू करने पर, इसमें OEM और SoC वेंडर के एक्सटेंशन और ऐसे कॉम्पोनेंट होते हैं जो AOSP कॉम्पोनेंट के साथ ज़्यादा काम करते हैं. उदाहरण के लिए, OEM की Java फ़्रेमवर्क लाइब्रेरी, OEM के ऐप्लिकेशन के लिए कस्टम एपीआई उपलब्ध कराती है. यह लाइब्रेरी, /system सेक्शन के बजाय /system_ext सेक्शन में बेहतर तरीके से काम करती है. /system और /system_ext, दोनों सेक्शन के लिए कॉन्टेंट, OEM के बनाए गए Android सोर्स से बनाया जाता है.

  • /system_ext पार्टीशन बनाना ज़रूरी नहीं है. हालांकि, AOSP पर आधारित कॉम्पोनेंट के साथ ज़्यादा काम करने वाली कस्टम सुविधाओं और एक्सटेंशन के लिए, इसका इस्तेमाल करना फ़ायदेमंद होता है. इस अंतर की मदद से, आपको उन बदलावों की पहचान करने में मदद मिलती है जिन्हें आपको समय के साथ, ऐसे कॉम्पोनेंट को /system_ext से /product में ले जाने के लिए करना होगा.

• प्रॉडक्ट: प्रॉडक्ट या डिवाइस के हिसाब से कॉम्पोनेंट का कलेक्शन, जो Android OS में OEM के कस्टमाइज़ेशन और एक्सटेंशन दिखाता है. SoC के हिसाब से बने कॉम्पोनेंट को /vendor पार्टीशन में डालें. SoC वेंडर, सही कॉम्पोनेंट के लिए /product पार्टिशन का इस्तेमाल भी कर सकते हैं. जैसे, SoC से स्वतंत्र कॉम्पोनेंट. उदाहरण के लिए, अगर कोई SoC वेंडर अपने OEM ग्राहकों को SoC से अलग कोई कॉम्पोनेंट उपलब्ध कराता है (जिसे प्रॉडक्ट के साथ शिप करना ज़रूरी नहीं है), तो SoC वेंडर उस कॉम्पोनेंट को प्रॉडक्ट इमेज में दिखा सकता है. किसी कॉम्पोनेंट की जगह, उसके मालिकाना हक से नहीं तय होती, बल्कि उसके मकसद से तय होती है.

• वेंडर: SoC के हिसाब से कॉम्पोनेंट का कलेक्शन.

• ओडीएम: बोर्ड के हिसाब से कॉम्पोनेंट का कलेक्शन, जो SoC से नहीं मिलता. आम तौर पर, SoC वेंडर के पास वेंडर इमेज का मालिकाना हक होता है, जबकि डिवाइस बनाने वाले के पास ओडीएम इमेज का मालिकाना हक होता है. अगर कोई अलग /odm पार्टीशन नहीं है, तो SoC वेंडर और ODM, दोनों इमेज को /vendor पार्टीशन में मर्ज कर दिया जाता है.

इमेज के बीच इंटरफ़ेस

एसएसआई के लिए, वेंडर और प्रॉडक्ट इमेज के दो मुख्य इंटरफ़ेस मौजूद हैं:

• वेंडर इंटरफ़ेस (VINTF): VINTF, वेंडर और ओडीएम इमेज में मौजूद कॉम्पोनेंट का इंटरफ़ेस है. प्रॉडक्ट और सिस्टम इमेज में मौजूद कॉम्पोनेंट, सिर्फ़ इस इंटरफ़ेस की मदद से वेंडर और ओडीएम इमेज के साथ इंटरैक्ट कर सकते हैं. उदाहरण के लिए, वेंडर इमेज, सिस्टम इमेज के निजी हिस्से पर निर्भर नहीं हो सकती. इसके अलावा, सिस्टम इमेज भी वेंडर इमेज के निजी हिस्से पर निर्भर नहीं हो सकती. मूल रूप से, इसे Project Treble में तय किया गया है. यह इमेज को सिस्टम और वेंडर के पार्टीशन में बांटता है. इंटरफ़ेस के बारे में इन तरीकों से बताया गया है:

  • HIDL (पासथ्रू एचएएल सिर्फ़ system और system_ext मॉड्यूल के लिए उपलब्ध है)
  • स्टैबल एआईडीएल
  • कॉन्फ़िगरेशन
    • System properties API
    • कॉन्फ़िगरेशन फ़ाइल स्कीमा एपीआई
  • VNDK
  • Android SDK टूल के एपीआई
  • Java SDK टूल की लाइब्रेरी

• प्रॉडक्ट इंटरफ़ेस: प्रॉडक्ट इंटरफ़ेस, एसएसआई और प्रॉडक्ट इमेज के बीच का इंटरफ़ेस होता है. स्थिर इंटरफ़ेस तय करने से, एसएसआई में प्रॉडक्ट के कॉम्पोनेंट को सिस्टम के कॉम्पोनेंट से अलग किया जा सकता है. प्रॉडक्ट इंटरफ़ेस के लिए, VINTF जैसे ही स्थिर इंटरफ़ेस की ज़रूरत होती है. हालांकि, Android 11 और उसके बाद के वर्शन वाले डिवाइसों के लिए, सिर्फ़ VNDK और Android SDK टूल के एपीआई का इस्तेमाल करना ज़रूरी है.

Android 11 में एसएसआई (एसएसआई) चालू करना

इस सेक्शन में, Android 11 में एसएसआई के साथ काम करने वाली नई सुविधाओं को इस्तेमाल करने का तरीका बताया गया है.

/system_ext पार्टीशन

/system_ext पार्टीशन को Android 11 में, वैकल्पिक पार्टीशन के तौर पर पेश किया गया था. (यह उन गैर-AOSP कॉम्पोनेंट के लिए जगह है जो /system पार्टीशन में, AOSP के तय किए गए कॉम्पोनेंट के साथ ज़्यादा काम करते हैं.) /system_ext पार्टिशन को /system पार्टिशन का OEM-specific एक्सटेंशन माना जाता है. इसमें दोनों पार्टिशन के लिए कोई इंटरफ़ेस तय नहीं किया जाता. /system_ext partition में मौजूद कॉम्पोनेंट, /system partition में निजी एपीआई कॉल कर सकते हैं. साथ ही, /system partition में मौजूद कॉम्पोनेंट, /system_ext partition में निजी एपीआई कॉल कर सकते हैं.

दोनों पार्टीशन एक-दूसरे से जुड़े होते हैं. इसलिए, Android का नया वर्शन रिलीज़ होने पर, दोनों पार्टीशन एक साथ अपग्रेड हो जाते हैं. Android के पिछले वर्शन के लिए बनाए गए /system_ext पार्टीशन को, Android के अगले वर्शन के /system पार्टीशन के साथ काम करने की ज़रूरत नहीं है.

/system_ext पार्टीशन में कोई मॉड्यूल इंस्टॉल करने के लिए, Android.bp फ़ाइल में system_ext_specific: true जोड़ें. जिन डिवाइसों में /system_ext पार्टिशन नहीं है उनके लिए, ऐसे मॉड्यूल को /system पार्टिशन में ./system_ext सबडायरेक्ट्री में इंस्टॉल करें.

इतिहास

यहां /system_ext पार्टीशन के बारे में कुछ जानकारी दी गई है. डिज़ाइन का लक्ष्य, /product पार्टीशन में OEM के सभी कॉम्पोनेंट को रखना था. भले ही, वे कॉम्पोनेंट सामान्य हों या नहीं. हालांकि, सभी कॉम्पोनेंट को एक साथ ट्रांसफ़र करना मुमकिन नहीं था. खास तौर पर, जब कुछ कॉम्पोनेंट /system से जुड़े थे. किसी टाइटली कपल्ड कॉम्पोनेंट को /product पार्टीशन में ले जाने के लिए, प्रॉडक्ट इंटरफ़ेस को बड़ा करना होगा. इसके लिए, अक्सर कॉम्पोनेंट को फिर से डिज़ाइन करना पड़ता है. इसमें काफ़ी समय और मेहनत लगती है. /system_ext सेगमेंट को उन कॉम्पोनेंट को कुछ समय के लिए होस्ट करने के मकसद से शुरू किया गया था जो /product सेगमेंट में ट्रांसफ़र होने के लिए तैयार नहीं थे. एसएसआई का लक्ष्य, /system_ext पार्टीशन को हटाना था.

हालांकि, /system_ext partition, /system partition को AOSP के ज़्यादा से ज़्यादा करीब रखने के लिए काम का है. एसएसआई के साथ, अपग्रेड करने में ज़्यादातर समय /system और /system_ext सेक्शन के कॉम्पोनेंट पर खर्च होता है. जब सिस्टम इमेज को उन सोर्स से बनाया जाता है जो AOSP में मौजूद सोर्स से मिलते-जुलते हों, तो अपग्रेड करने के लिए system_ext इमेज पर फ़ोकस किया जा सकता है.

/system और /system_ext पार्टीशन से कॉम्पोनेंट को /product पार्टीशन में अनबंड करना

Android 9 में, /system पार्टीशन के साथ /product पार्टीशन का इस्तेमाल किया गया है. /product partition में मौजूद मॉड्यूल, सिस्टम के संसाधनों का इस्तेमाल बिना किसी पाबंदी के करते हैं. इसके अलावा, सिस्टम के संसाधनों का इस्तेमाल करने वाले मॉड्यूल, /product partition में मौजूद मॉड्यूल के संसाधनों का इस्तेमाल नहीं कर सकते. Android 10 में एसएसआई की सुविधा उपलब्ध कराने के लिए, प्रॉडक्ट के कॉम्पोनेंट को /system_ext और /product सेक्शन में बांटा गया है. /system_ext पार्टीशन को सिस्टम कॉम्पोनेंट इस्तेमाल करने से जुड़ी उन पाबंदियों का पालन नहीं करना पड़ता जो /product पार्टीशन को Android 9 में करना पड़ता था. Android 10 से, /product पार्टिशन को /system से अनबंड किया जाना चाहिए. साथ ही, /system और /system_ext सेटअप के लिए, स्थिर इंटरफ़ेस का इस्तेमाल किया जाना चाहिए.

/system_ext पार्टीशन का मुख्य मकसद, बंडल किए गए प्रॉडक्ट मॉड्यूल को इंस्टॉल करने के बजाय, सिस्टम की सुविधाओं को बढ़ाना है. इस बारे में /system_ext partition सेक्शन में बताया गया है. ऐसा करने के लिए, प्रॉडक्ट के हिसाब से बने मॉड्यूल को अनबंड करें और उन्हें /product पार्टीशन में ले जाएं. प्रॉडक्ट के हिसाब से बंडल किए गए मॉड्यूल को अलग करने पर, /system_ext सभी डिवाइसों के लिए सामान्य हो जाता है. ज़्यादा जानकारी के लिए, /system_ext पार्टीशन को सामान्य बनाना लेख पढ़ें.

/product partition को सिस्टम कॉम्पोनेंट से अनबंड करने के लिए, /product partition में वही नीति लागू होनी चाहिए जो /vendor partition में पहले से लागू है. /vendor partition को Project Treble की मदद से पहले ही अनबंड किया जा चुका है.

Android 11 से, /product पार्टीशन के लिए नेटिव और Java इंटरफ़ेस का इस्तेमाल करना ज़रूरी है. इनका इस्तेमाल करने का तरीका यहां बताया गया है. ज़्यादा जानकारी के लिए, प्रॉडक्ट के लिए पार्टीशन इंटरफ़ेस लागू करना लेख पढ़ें.

• नेटिव इंटरफ़ेस: /product पार्टीशन में मौजूद नेटिव मॉड्यूल को, अन्य पार्टीशन से अलग करना ज़रूरी है. प्रॉडक्ट मॉड्यूल से सिर्फ़ /system partition में मौजूद कुछ VNDK लाइब्रेरी (इनमें LLNDK भी शामिल है) इस्तेमाल की जा सकती हैं. प्रॉडक्ट ऐप्लिकेशन जिन JNI लाइब्रेरी पर निर्भर करते हैं वे NDK लाइब्रेरी होनी चाहिए.
• Java इंटरफ़ेस: /product पार्टीशन में मौजूद Java (ऐप्लिकेशन) मॉड्यूल, छिपे हुए एपीआई का इस्तेमाल नहीं कर सकते, क्योंकि वे अस्थिर होते हैं. इन मॉड्यूल को सिर्फ़ /system सेक्शन के सार्वजनिक एपीआई और सिस्टम एपीआई का इस्तेमाल करना चाहिए. साथ ही, /system या /system_ext सेक्शन में मौजूद Java SDK लाइब्रेरी का इस्तेमाल करना चाहिए. कस्टम एपीआई के लिए, Java SDK लाइब्रेरी तय की जा सकती हैं.

जीएसआई पर आधारित एसएसआई के लिए सुझाए गए तरीके

दूसरी इमेज. जीएसआई पर आधारित एसएसआई के लिए सुझाए गए पार्टीशन

सामान्य सिस्टम इमेज (जीएसआई), सीधे तौर पर AOSP से बनाई गई सिस्टम इमेज होती है. इसका इस्तेमाल, Treble की शर्तों के मुताबिक काम करने की जांच के लिए किया जाता है. उदाहरण के लिए, जीएसआई पर सीटीएस. साथ ही, इसे रेफ़रंस प्लैटफ़ॉर्म के तौर पर भी इस्तेमाल किया जाता है. ऐप्लिकेशन डेवलपर, इस प्लैटफ़ॉर्म का इस्तेमाल अपने ऐप्लिकेशन के काम करने की जांच करने के लिए कर सकते हैं. ऐसा तब किया जाता है, जब उनके पास Android का ज़रूरी वर्शन चलाने वाला कोई असली डिवाइस न हो.

OEM, एसएसआई बनाने के लिए जीएसआई का भी इस्तेमाल कर सकते हैं. इमेज और पार्टिशन में बताए गए मुताबिक, एसएसआई में AOSP के तय किए गए कॉम्पोनेंट के लिए सिस्टम इमेज और OEM के तय किए गए कॉम्पोनेंट के लिए system_ext इमेज शामिल होती है. जब GSI का इस्तेमाल system इमेज के तौर पर किया जाता है, तो OEM अपग्रेड के लिए system_ext इमेज पर फ़ोकस कर सकता है.

इस सेक्शन में, उन OEM के लिए गाइड दी गई है जो AOSP या AOSP जैसी सिस्टम इमेज का इस्तेमाल करते हुए, अपने पसंद के मुताबिक किए गए बदलावों को /system_ext और /product पार्टीशन में मॉड्यूलर बनाना चाहते हैं. अगर OEM, AOSP के सोर्स से सिस्टम इमेज बनाते हैं, तो वे AOSP की ओर से उपलब्ध कराए गए GSI के साथ, अपनी बनाई गई सिस्टम इमेज को बदल सकते हैं. हालांकि, OEM को एक साथ GSI का इस्तेमाल करके, आखिरी चरण तक पहुंचने की ज़रूरत नहीं है.

पहला चरण. OEM की सिस्टम इमेज (OEM GSI) के लिए generic_system.mk को इनहेरिट करना

सिस्टम इमेज (OEM GSI) में, generic_system.mk (जिसे Android 11 में mainline_system.mk और AOSP में generic_system.mk नाम दिया गया था) को इनहेरिट करके, वे सभी फ़ाइलें शामिल होती हैं जो AOSP GSI में होती हैं. OEM इन फ़ाइलों में बदलाव कर सकते हैं, ताकि OEM GSI में AOSP GSI फ़ाइलों के साथ-साथ OEM की मालिकाना हक वाली फ़ाइलें भी शामिल की जा सकें. हालांकि, OEM के पास generic_system.mk फ़ाइल में बदलाव करने की अनुमति नहीं है.

तीसरी इमेज. OEM की सिस्टम इमेज के लिए generic_system.mk को इनहेरिट करना

दूसरा चरण. OEM GSI में AOSP GSI की फ़ाइलों की सूची एक ही हो

इस चरण में, OEM GSI में कोई और फ़ाइल नहीं हो सकती. OEM की मालिकाना हक वाली फ़ाइलों को system_ext या product वाले पार्टीशन में ले जाया जाना चाहिए.

चौथी इमेज. जोड़ी गई फ़ाइलों को OEM GSI से बाहर ले जाना

चरण 3. OEM GSI में बदली गई फ़ाइलों को सीमित करने के लिए, अनुमति वाली सूची तय करना

बदली गई फ़ाइलों की जांच करने के लिए, OEM, compare_images टूल का इस्तेमाल कर सकते हैं. साथ ही, AOSP GSI की तुलना OEM GSI से कर सकते हैं. AOSP लंच टारगेट generic_system_* से AOSP GSI पाएं.

allowlist पैरामीटर के साथ समय-समय पर compare_images टूल चलाकर, अनुमति वाली सूची के बाहर के अंतर को मॉनिटर किया जा सकता है. इससे OEM GSI में और बदलाव करने की ज़रूरत नहीं पड़ती.

पांचवीं इमेज. OEM GSI में बदली गई फ़ाइलों की सूची को कम करने के लिए, अनुमति वाली सूची तय करना

चौथा चरण. OEM GSI में AOSP GSI जैसी ही बाइनरी होनी चाहिए

अनुमति वाली सूची को हटाने से, OEM अपने प्रॉडक्ट के लिए, AOSP GSI का इस्तेमाल सिस्टम इमेज के तौर पर कर सकते हैं. अनुमति वाली सूची को साफ़ करने के लिए, OEM, OEM GSI में किए गए बदलावों को छोड़ सकते हैं या अपने बदलावों को AOSP में अपस्ट्रीम कर सकते हैं, ताकि AOSP GSI में उनके बदलाव शामिल किए जा सकें.

छठी इमेज. OEM GSI में AOSP GSI जैसी ही बाइनरी का इस्तेमाल करना

OEM के लिए एसएसआई तय करना

बिल्ड के समय /system पार्टिशन को सुरक्षित रखना

/system पार्टीशन में, प्रॉडक्ट के हिसाब से होने वाले बदलावों से बचने और OEM GSI तय करने के लिए, OEMs require-artifacts-in-path नाम के मेकफ़ाइल मैक्रो का इस्तेमाल कर सकते हैं. इससे मैक्रो के कॉल होने के बाद, सिस्टम मॉड्यूल का एलान होने से रोका जा सकता है. मेकफ़ाइल बनाना और आर्टफ़ैक्ट के पाथ की जांच करने की सुविधा चालू करने का उदाहरण देखें.

OEM, प्रॉडक्ट के हिसाब से बनाए गए मॉड्यूल को /system पार्टीशन में कुछ समय के लिए इंस्टॉल करने की अनुमति देने के लिए, एक सूची तय कर सकते हैं. हालांकि, OEM के सभी प्रॉडक्ट के लिए OEM GSI को सामान्य बनाने के लिए, सूची खाली होनी चाहिए. यह प्रोसेस, OEM के जीएसआई को तय करने के लिए है. यह एओएसपी के जीएसआई के लिए तय किए गए चरणों से अलग हो सकती है.

प्रॉडक्ट इंटरफ़ेस लागू करना

/product पार्टीशन को अनबंड किए जाने की गारंटी देने के लिए, OEM यह पक्का कर सकते हैं कि उनके डिवाइसों पर प्रॉडक्ट इंटरफ़ेस लागू हों. इसके लिए, नेटिव मॉड्यूल के लिए PRODUCT_PRODUCT_VNDK_VERSION:= current और Java मॉड्यूल के लिए PRODUCT_ENFORCE_PRODUCT_PARTITION_INTERFACE:= true को सेट करें. अगर डिवाइस का PRODUCT_SHIPPING_API_LEVEL, 30 से ज़्यादा या इसके बराबर है, तो ये वैरिएबल अपने-आप सेट हो जाते हैं. ज़्यादा जानकारी के लिए, प्रॉडक्ट के लिए अलग-अलग इंटरफ़ेस लागू करना लेख पढ़ें.

/system_ext पार्टीशन को सामान्य बनाएं

डिवाइस के हिसाब से /system_ext पार्टीशन अलग-अलग हो सकता है, क्योंकि इसमें डिवाइस के हिसाब से, सिस्टम के साथ बंडल किए गए मॉड्यूल हो सकते हैं. एसएसआई में /system और /system_ext सेक्शन होते हैं. इसलिए, /system_ext सेक्शन में अंतर होने की वजह से, OEM, एसएसआई तय नहीं कर पाते. OEM के पास अपना एसएसआई हो सकता है. साथ ही, वे उस एसएसआई को कई डिवाइसों के बीच शेयर कर सकते हैं. इसके लिए, उन्हें डिवाइसों के बीच के अंतर को हटाना होगा और /system_ext पार्टीशन को सामान्य बनाना होगा.

इस सेक्शन में, /system_ext पार्टीशन को सामान्य बनाने के लिए सुझाव दिए गए हैं.

सिस्टम पार्टीशन में छिपे हुए एपीआई को एक्सपोज़ करना

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

ऐप्लिकेशन से छिपे हुए एपीआई हटाने का सबसे सही तरीका यह है कि उनके बदले, सार्वजनिक या सिस्टम के अन्य एपीआई ढूंढें. अगर छिपाए गए एपीआई को बदलने के लिए कोई एपीआई नहीं है, तो OEM अपने डिवाइसों के लिए नए सिस्टम एपीआई तय करने के लिए, AOSP में योगदान दे सकते हैं.

इसके अलावा, OEM /system_ext पार्टीशन में अपनी Java SDK लाइब्रेरी बनाकर, कस्टम एपीआई तय कर सकते हैं. यह सिस्टम पार्टीशन में छिपे हुए एपीआई का इस्तेमाल कर सकता है. साथ ही, प्रॉडक्ट या वेंडर पार्टीशन में मौजूद ऐप्लिकेशन को एपीआई उपलब्ध करा सकता है. पुराने सिस्टम के साथ काम करने की सुविधा के लिए, OEM को प्रॉडक्ट के लिए उपलब्ध एपीआई को फ़्रीज़ करना होगा.

सभी APK का सुपरसेट शामिल करें और हर डिवाइस के लिए कुछ पैकेज इंस्टॉल करने से बचें

सिस्टम के साथ बंडल किए गए कुछ पैकेज, सभी डिवाइसों में उपलब्ध नहीं होते. इन APK मॉड्यूल को अनबंड करके, उन्हें प्रॉडक्ट या वेंडर पार्टीशन में ले जाना मुश्किल हो सकता है. कुछ समय के लिए, OEM SSI में सभी मॉड्यूल शामिल कर सकते हैं. इसके बाद, SKU प्रॉपर्टी (ro.boot.hardware.sku) का इस्तेमाल करके, अनचाहे मॉड्यूल को फ़िल्टर कर सकते हैं. फ़िल्टर का इस्तेमाल करने के लिए, OEM फ़्रेमवर्क के रिसॉर्स config_disableApkUnlessMatchedSku_skus_list और config_disableApksUnlessMatchedSku_apk_list को ओवरले करते हैं.

ज़्यादा सटीक सेटिंग के लिए, ऐसा ब्रॉडकास्ट रिसीवर तय करें जो ज़रूरत के मुताबिक न होने वाले पैकेज बंद कर दे. ब्रॉडकास्ट रिसीवर, ACTION_BOOT_COMPLETED मैसेज मिलने पर, पैकेज को बंद करने के लिए setApplicationEnabledSetting को कॉल करता है.

स्टैटिक रिसॉर्स ओवरले का इस्तेमाल करने के बजाय, आरआरओ तय करना

स्टैटिक रिसॉर्स ओवरले, ओवरले किए गए पैकेज में बदलाव करता है. हालांकि, इससे एसएसआई तय करने में रुकावट आ सकती है. इसलिए, पक्का करें कि आरआरओ के लिए प्रॉपर्टी चालू हों और सही तरीके से सेट हों. प्रॉपर्टी को इस तरह सेट करके, OEM के पास अपने-आप जनरेट हुए सभी ओवरले को आरआरओ के तौर पर सेट करने का विकल्प होता है.

PRODUCT_ENFORCE_RRO_TARGETS := *
PRODUCT_ENFORCE_RRO_EXCLUDED_OVERLAYS := # leave it empty

अगर आपको ज़्यादा जानकारी वाले कॉन्फ़िगरेशन की ज़रूरत है, तो अपने-आप जनरेट होने वाले आरआरओ पर भरोसा करने के बजाय, मैन्युअल रूप से आरआरओ तय करें. ज़्यादा जानकारी के लिए, रनटाइम संसाधन ओवरले (आरआरओ) देखें. OEM, सिस्टम प्रॉपर्टी के आधार पर शर्तों के साथ आरआरओ भी तय कर सकते हैं. इसके लिए, android:requiredSystemPropertyName और android:requiredSystemPropertyValue एट्रिब्यूट का इस्तेमाल करें.

अक्सर पूछे जाने वाले सवाल

क्या एक से ज़्यादा एसएसआई तय किए जा सकते हैं?

यह डिवाइसों (या डिवाइस ग्रुप) की समानता और विशेषताओं पर निर्भर करता है. OEM, system_ext पार्टीशन को सामान्य बनाने की कोशिश कर सकते हैं. इसके बारे में system_ext पार्टीशन को सामान्य बनाने में बताया गया है. अगर किसी डिवाइस ग्रुप में कई अंतर हैं, तो एक से ज़्यादा एसएसआई तय करना बेहतर होता है.

क्या किसी OEM जीएसआई के लिए, generic_system.mk (mainline_system.mk) में बदलाव किया जा सकता है?

नहीं. हालांकि, OEM किसी OEM GSI के लिए नई मेकफ़ाइल तय कर सकते हैं, जो generic_system.mk फ़ाइल को इनहेरिट करती है और नई मेकफ़ाइल का इस्तेमाल करती है. उदाहरण के लिए, प्रॉडक्ट के लिए अलग-अलग इंटरफ़ेस लागू करना देखें.

क्या मुझे generic_system.mk से ऐसे मॉड्यूल हटाने की अनुमति है जो मेरे लागू किए गए मॉड्यूल से मेल नहीं खाते?

नहीं. GSI में, बूट किए जा सकने वाले और जिनकी जांच की जा सकती है ऐसे कम से कम मॉड्यूल होते हैं. अगर आपको लगता है कि कोई मॉड्यूल ज़रूरी नहीं है, तो कृपया AOSP में generic_system.mk फ़ाइल को अपडेट करने के लिए, गड़बड़ी की शिकायत दर्ज करें.