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

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

बैकग्राउंड

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

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

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

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

लागू करने से जुड़ी जानकारी के लिए, GSI पर आधारित एसएसआई के लिए सुझाए गए चरण देखें. ये चरण मॉड्यूलर हैं. अपने आर्किटेक्चर के हिसाब से, सभी चरणों के बजाय कुछ खास चरणों (जैसे कि पहला चरण: ओईएम सिस्टम इमेज (ओईएम जीएसआई) के लिए generic_system.mk इनहेरिट करना) को लागू किया जा सकता है.

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

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

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

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

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

एसएसआई के हिसाब से बनाए गए पार्टीशन

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

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

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

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

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

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

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

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

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

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

/system_ext पार्टिशन

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

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

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

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

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

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

• प्रॉडक्ट इंटरफ़ेस: प्रॉडक्ट इंटरफ़ेस, एसएसआई और प्रॉडक्ट की इमेज के बीच का इंटरफ़ेस होता है. स्थिर इंटरफ़ेस तय करने से, एसएसआई में प्रॉडक्ट कॉम्पोनेंट, सिस्टम कॉम्पोनेंट से अलग हो जाते हैं.

एसएसआई चालू करना

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

कॉम्पोनेंट को अनबंडल करना

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

चौथा चरण: ओईएम जीएसआई में, एओएसपी जीएसआई वाले बाइनरी शामिल करें

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

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

एसएसआई को परिभाषित करें

ओईएम, एसएसआई तय करने के लिए यहां दिए गए दिशा-निर्देशों का इस्तेमाल कर सकते हैं.

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

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

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

/system_ext पार्टिशन को सामान्य बनाना

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

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

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

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

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

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

SKU के हिसाब से ऐप्लिकेशन बंद करने की सुविधा को बदलना

Android 16 में, हार्डवेयर एसकेयू के आधार पर एपीके को चुनिंदा तौर पर बंद करने के लिए, लेगसी सिस्टम को बंद कर दिया गया है और हटा दिया गया है. इसके लिए, फ़्रेमवर्क रिसॉर्स ओवरले (config_disableApksUnlessMatchedSku_apk_list और config_disableApkUnlessMatchedSku_skus_list) का इस्तेमाल किया जाता है. ज़्यादा जानकारी के लिए, aosp/3444399 देखें.

हमारा सुझाव है कि एसकेयू के हिसाब से बनी डायरेक्ट्री में, install-in-user-type सिस्टम कॉन्फ़िगरेशन का इस्तेमाल करें. इससे किसी एसकेयू पर मौजूद किसी भी उपयोगकर्ता के लिए पैकेज इंस्टॉल नहीं किया जा सकेगा. इसके बजाय, इसे इंस्टॉल होने के बाद बंद कर दिया जाएगा.

1. इमेज में सभी APK शामिल करें. ये APK, आपकी सिस्टम इमेज में मौजूद सभी एसकेयू के लिए सभी संभावित ऐप्लिकेशन का सुपरसेट होते हैं. आम तौर पर, इन्हें /product पार्टिशन में शामिल किया जाता है.

2. पक्का करें कि ro.boot.hardware.sku सिस्टम प्रॉपर्टी में डिवाइस का एसकेयू सही तरीके से सेट किया गया हो. इस प्रॉपर्टी का इस्तेमाल सिस्टम, बूट होने के समय डिवाइस के एसकेयू की पहचान करने के लिए करता है.

3. /product/etc/sysconfig/ में, एसकेयू के हिसाब से sysconfig सबडायरेक्ट्री बनाएं. इसके लिए, sku_<SKU_NAME> नाम रखने के नियम का इस्तेमाल करें. सिस्टम, ro.boot.hardware.sku प्रॉपर्टी से मेल खाने वाली डायरेक्ट्री से कॉन्फ़िगरेशन अपने-आप लोड करता है. पाथ का उदाहरण: /product/etc/sysconfig/sku_basic_model/.

4. ऐप्लिकेशन इंस्टॉल होने से रोकने की सुविधा कॉन्फ़िगर करें. एसकेयू के हिसाब से डायरेक्ट्री में जाकर, एक एक्सएमएल कॉन्फ़िगरेशन फ़ाइल बनाएं. उदाहरण के लिए, disabled_apps.xml. इसके बाद, <do-not-install-in> टैग का इस्तेमाल करके, कुछ पैकेज को बाहर रखें.

एक्सएमएल का उदाहरण (/product/etc/sysconfig/sku_basic_model/disabled_apps.xml):

<?xml version="1.0" encoding="utf-8"?>
<config>
    <!-- Prevents this package from being installed for ANY user on this SKU -->
    <install-in-user-type package="com.example.premium.feature.app" >
        <do-not-install-in user-type="FULL" />
        <do-not-install-in user-type="SYSTEM" />
    </install-in-user-type>
</config>

यहां दोनों तरीकों की तुलना की गई है:

अगर आपको ज़्यादा विस्तृत तरीके से कंट्रोल करना है (यानी कि किसी ऐसे ऐप्लिकेशन को बंद करना है जो आम तौर पर सभी एसकेयू में डिफ़ॉल्ट रूप से इंस्टॉल होता है), तो Android, sysconfig में disabled-in-sku और enabled-in-sku-override टैग का इस्तेमाल करने की सुविधा भी देता है:

• <disabled-in-sku package="com.example.app" /> से, ऐप्लिकेशन को दुनिया भर में बंद कर दिया जाता है.

• <enabled-in-sku-override package="com.example.app" /> को उससे जुड़ी sku_<name> डायरेक्ट्री में रखने पर, यह किसी एसकेयू के लिए ऐप्लिकेशन को फिर से चालू कर देता है.

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

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

PRODUCT_ENFORCE_RRO_TARGETS := *
PRODUCT_ENFORCE_RRO_EXCLUDED_OVERLAYS := # leave it empty

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

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

एसएसआई के बारे में अक्सर पूछे जाने वाले सवाल यहां दिए गए हैं.

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

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

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

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