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

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

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

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

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

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

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

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

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

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

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

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

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

आकृति 1 में दिए गए सेक्शन के बारे में यहां बताया गया है:

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

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

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

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

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

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

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

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

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

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

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

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

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

/system_ext पार्टिशन

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

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

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

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

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

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

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

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

GSI पर आधारित एसएसआई के लिए सुझाए गए चरण

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

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

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

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

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

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

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

दूसरा चरण. OEM GSI में, AOSP GSI वाली फ़ाइलों की सूची शामिल करें

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

चौथी इमेज. जोड़ी गई फ़ाइलों को ओईएम जीएसआई से दूसरी जगह ले जाना

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

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

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

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

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

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

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

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

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

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

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

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

यह पक्का करने के लिए कि /product पार्टीशन अनबंडल किया गया है, ओईएम यह पक्का कर सकते हैं कि उनके डिवाइस, प्रॉडक्ट इंटरफ़ेस लागू करें. इसके लिए, वे नेटिव मॉड्यूल के लिए 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 के पास अपना एसएसआई हो सकता है. साथ ही, वे /system_ext पार्टीशन को सामान्य बनाकर और सभी अंतरों को हटाकर, उस एसएसआई को कई डिवाइसों के साथ शेयर कर सकते हैं.

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

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

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

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

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

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

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

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

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

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

PRODUCT_ENFORCE_RRO_TARGETS := *
PRODUCT_ENFORCE_RRO_EXCLUDED_OVERLAYS := # leave it empty

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

अक्सर पूछे जाने वाले सवाल (एफ़एक्यू)

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

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

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

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

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

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