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

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

बैकग्राउंड

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

वजह

AOSP में रिलीज़ किया गया फ़्रेमवर्क कोड, Treble के आर्किटेक्चर के मुताबिक है. साथ ही, यह वेंडर के पुराने वर्शन के साथ काम करता है. उदाहरण के लिए, Android 10 AOSP के सोर्स से बनाई गई सामान्य सिस्टम इमेज, Treble के साथ काम करने वाले किसी भी ऐसे डिवाइस पर चल सकती है जो Android 8 या उसके बाद के वर्शन पर काम करता है. उपभोक्ता के डिवाइसों पर शिप किए जाने वाले 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 सिस्टम को मॉड्यूलर एक्सटेंशन की मदद से अपडेट करें.

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

एसएसआई का बंटवारा

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

एसएसआई ब्लॉक डायग्राम के आस-पास के पार्टीशन और इंटरफ़ेस

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    • HIDL (पासथ्रू एचएएल सिर्फ़ system और system_ext मॉड्यूल के लिए उपलब्ध है)
    • स्टेबल एआईडीएल
    • कॉन्फ़िगरेशन
      • सिस्टम प्रॉपर्टी एपीआई
      • कॉन्फ़िगरेशन फ़ाइल स्कीमा एपीआई
    • 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 का खास एक्सटेंशन माना गया है. इसके दोनों हिस्सों में कोई इंटरफ़ेस नहीं है. /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 पार्टीशन के बारे में कुछ जानकारी दी गई है. डिज़ाइन का लक्ष्य, सभी OEM के लिए बने कॉम्पोनेंट को /product सेगमेंट में शामिल करना था. इस बात से कोई फ़र्क़ नहीं पड़ता कि वे सामान्य हैं या नहीं. हालांकि, सभी कॉम्पोनेंट को एक साथ ट्रांसफ़र करना मुमकिन नहीं था. खास तौर पर, जब कुछ कॉम्पोनेंट /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 में एक /product पार्टीशन पेश किया गया है, जो /system पार्टीशन के साथ काम करता है. /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 partition के सार्वजनिक एपीआई और सिस्टम एपीआई का इस्तेमाल करना चाहिए. साथ ही, /system या /system_ext partition में मौजूद Java SDK लाइब्रेरी का इस्तेमाल करना चाहिए. कस्टम एपीआई के लिए, Java SDK लाइब्रेरी तय की जा सकती हैं.

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

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

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

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

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

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

पहला चरण. 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 की सिस्टम इमेज के लिए जेनरिक सिस्टम.mk को इनहेरिट किया जा रहा है

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

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

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

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

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

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

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

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

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

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

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

तय करें कि OEM GSI के पास AOSP GSI की तरह ही बाइनरी हैं

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

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

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

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

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

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

/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

अगर पूरी जानकारी वाले कॉन्फ़िगरेशन की ज़रूरत हो, तो अपने-आप जनरेट होने वाले कॉन्फ़िगरेशन का इस्तेमाल करने के बजाय, मैन्युअल तरीके से RRO को तय करें. ज़्यादा जानकारी के लिए, रनटाइम संसाधन ओवरले (आरआरओ) देखें. 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 फ़ाइल को अपडेट करने के लिए, गड़बड़ी की शिकायत दर्ज करें.