एंड्रॉइड साझा सिस्टम छवि

यह पृष्ठ कई तंत्र प्रस्तुत करता है जिनका उपयोग एंड्रॉइड डिवाइस ओईएम उत्पाद लाइनों में अपनी स्वयं की साझा सिस्टम छवि (एसएसआई) रखने के लिए कर सकते हैं। यह AOSP-निर्मित जेनेरिक सिस्टम इमेज (GSI) पर OEM-स्वामित्व वाले SSI को आधारित करने की एक प्रक्रिया का भी प्रस्ताव करता है।

पृष्ठभूमि

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

प्रेरणा

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

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

एसएसआई सिंहावलोकन

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

ध्यान दें कि ओईएम और एसओसी विक्रेता एसएसआई का निर्माण करते हैं जिसमें वे सभी कस्टम सुविधाएँ और संशोधन शामिल होते हैं जिनकी एक ओईएम को आवश्यकता होती है। इस पृष्ठ पर उपलब्ध कराए गए तंत्र और सर्वोत्तम अभ्यास OEM के लिए इन प्रमुख लक्ष्यों तक पहुंचने के लिए उपयोग करने के लिए हैं:

  • एकाधिक डिवाइस SKU में SSI का पुन: उपयोग करें।
  • ओएस अपग्रेड को आसान बनाने के लिए मॉड्यूलर एक्सटेंशन के साथ एंड्रॉइड सिस्टम को अपडेट करें।

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

एसएसआई के आसपास विभाजन

चित्र 1 एसएसआई के चारों ओर विभाजन दिखाता है, और इंटरफ़ेस पर विभाजन और नीतियों में संस्करणित इंटरफ़ेस दिखाता है। यह अनुभाग प्रत्येक विभाजन और इंटरफ़ेस को विस्तार से बताता है।

Partitions and interfaces around SSI block diagram

चित्र 1. एसएसआई के आसपास विभाजन और इंटरफेस

छवियाँ और विभाजन

इस अनुभाग की जानकारी छवि और विभाजन शब्दों के बीच अंतर करती है।

  • एक छवि सॉफ्टवेयर का एक वैचारिक टुकड़ा है जिसे स्वतंत्र रूप से अपडेट किया जा सकता है।
  • विभाजन एक भौतिक भंडारण स्थान है जिसे स्वतंत्र रूप से अद्यतन किया जा सकता है।

चित्र 1 में अनुभागों को इस प्रकार परिभाषित किया गया है:

  • एसएसआई: एसएसआई वह छवि है जो ओईएम के लिए सामान्य है, और कई उपकरणों में मौजूद हो सकती है। इसमें कोई हार्डवेयर-विशिष्ट या उत्पाद-विशिष्ट घटक नहीं है। किसी दिए गए एसएसआई में सब कुछ, परिभाषा के अनुसार, उस एसएसआई का उपयोग करने वाले सभी उपकरणों के बीच साझा किया जाता है। एसएसआई या तो एक एकल /system छवि, या एक /system और /system_ext विभाजन से बना है, जैसा कि चित्र 1 में देखा गया है।

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

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

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

  • विक्रेता : एसओसी-विशिष्ट घटकों का एक संग्रह।

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

छवियों के बीच इंटरफेस

SSI के आसपास विक्रेता और उत्पाद छवियों के लिए दो मुख्य इंटरफ़ेस मौजूद हैं:

  • विक्रेता इंटरफ़ेस (VINTF) : VINTF उन घटकों का इंटरफ़ेस है जो विक्रेता और ODM छवियों में रहते हैं। उत्पाद और सिस्टम छवियों के घटक केवल इस इंटरफ़ेस के माध्यम से विक्रेता और ODM छवियों के साथ बातचीत कर सकते हैं। उदाहरण के लिए, एक विक्रेता छवि सिस्टम छवि के निजी भाग पर निर्भर नहीं हो सकती है, और इसके विपरीत भी। इसे मूल रूप से प्रोजेक्ट ट्रेबल में परिभाषित किया गया है, जो छवियों को सिस्टम और विक्रेता विभाजन में विभाजित करता है। इंटरफ़ेस को निम्नलिखित तंत्रों का उपयोग करके वर्णित किया गया है:

    • HIDL (पासथ्रू HAL केवल system और system_ext मॉड्यूल के लिए उपलब्ध है)
    • स्थिर एआईडीएल
    • विन्यास
      • सिस्टम गुण एपीआई
      • कॉन्फ़िग फ़ाइल स्कीमा एपीआई
    • वीएनडीके
    • एंड्रॉइड एसडीके एपीआई
    • जावा एसडीके लाइब्रेरी

  • उत्पाद इंटरफ़ेस : उत्पाद इंटरफ़ेस SSI और उत्पाद छवि के बीच का इंटरफ़ेस है। एक स्थिर इंटरफ़ेस को परिभाषित करने से एसएसआई में उत्पाद घटकों को सिस्टम घटकों से अलग कर दिया जाता है। उत्पाद इंटरफ़ेस को VINTF के समान स्थिर इंटरफ़ेस की आवश्यकता होती है। हालाँकि, केवल VNDK और Android SDK API Android 11 (और उच्चतर) के साथ लॉन्च होने वाले उपकरणों के लिए लागू किए गए हैं।

एंड्रॉइड 11 में एसएसआई सक्षम करना

यह अनुभाग बताता है कि एंड्रॉइड 11 में एसएसआई का समर्थन करने के लिए नई सुविधाओं का उपयोग कैसे करें।

/system_ext विभाजन

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

क्योंकि दोनों विभाजन मजबूती से जुड़े हुए हैं, नया एंड्रॉइड संस्करण जारी होने पर दोनों विभाजन एक साथ अपग्रेड हो जाते हैं। 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 विभाजन में ले जाने के लिए तैयार नहीं हैं। SSI का लक्ष्य अंततः /system_ext विभाजन को समाप्त करना था।

हालाँकि, /system_ext विभाजन /system विभाजन को यथासंभव AOSP के करीब रखने के लिए उपयोगी है। SSI के साथ, अपग्रेड का अधिकांश प्रयास /system और /system_ext विभाजन के घटकों पर खर्च किया जाता है। जब सिस्टम छवि उन स्रोतों से बनाई जाती है जो AOSP में यथासंभव समान हैं, तो आप अपग्रेड प्रयास को system_ext छवि पर केंद्रित कर सकते हैं।

/system और /system_ext विभाजन से घटकों को /product विभाजन में अनबंडल करना

एंड्रॉइड 9 ने एक /product विभाजन पेश किया जो /system विभाजन के साथ युग्मित है। /product विभाजन में मॉड्यूल बिना किसी प्रतिबंध के सिस्टम संसाधनों का उपयोग करते हैं, और इसके विपरीत। एंड्रॉइड 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 विभाजन को अनबंडल करने के लिए, /product विभाजन में /vendor विभाजन के समान प्रवर्तन नीति होनी चाहिए जो पहले से ही प्रोजेक्ट ट्रेबल के साथ अनबंडल किया गया था।

एंड्रॉइड 11 में शुरू होकर, /product विभाजन के लिए मूल और जावा इंटरफेस नीचे वर्णित अनुसार लागू किए गए हैं। अधिक जानकारी के लिए, उत्पाद विभाजन इंटरफ़ेस लागू करना देखें।

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

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

Suggested partitions for GSI-based SSI

चित्र 2. जीएसआई-आधारित एसएसआई के लिए सुझाए गए विभाजन

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

OEM अपने SSI बनाने के लिए GSI का भी उपयोग कर सकते हैं। जैसा कि छवियाँ और विभाजन में बताया गया है, SSI में AOSP-परिभाषित घटकों के लिए सिस्टम छवि और OEM-परिभाषित घटकों के लिए system_ext छवि शामिल है। जब GSI को system छवि के रूप में उपयोग किया जाता है, तो OEM अपग्रेड के लिए system_ext छवि पर ध्यान केंद्रित कर सकता है।

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

चरण 1. ओईएम की सिस्टम छवि (ओईएम जीएसआई) के लिए जेनेरिक_सिस्टम.एमके को इनहेरिट करना

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

Inheriting `generic_system.mk` for OEM system image

चित्र 3. ओईएम की सिस्टम छवि के लिए generic_system.mk इनहेरिट करना

चरण 2. OEM GSI को AOSP GSI के साथ फ़ाइलों की समान सूची बनाना

इस स्तर पर OEM GSI में अतिरिक्त फ़ाइलें नहीं हो सकतीं। OEM की मालिकाना फ़ाइलों को system_ext या product विभाजन में ले जाया जाना चाहिए।

Moving added files out of the OEM GSI

चित्र 4. जोड़ी गई फ़ाइलों को OEM GSI से बाहर ले जाना

चरण 3. ओईएम जीएसआई में संशोधित फ़ाइलों को सीमित करने के लिए एक अनुमति सूची को परिभाषित करना

संशोधित फ़ाइलों की जाँच करने के लिए, OEM compare_images टूल का उपयोग कर सकते हैं, और AOSP GSI की तुलना OEM GSI से कर सकते हैं। AOSP लंच लक्ष्य generic_system_* से AOSP GSI प्राप्त करें।

allowlist पैरामीटर के साथ समय-समय पर compare_images टूल चलाकर, आप अनुमत सूची के बाहर के अंतरों की निगरानी कर सकते हैं। यह OEM GSI में अतिरिक्त संशोधनों की आवश्यकता को रोकता है।

Define an allowlist to reduce the list of modified files in OEM GSI

चित्र 5. ओईएम जीएसआई में संशोधित फ़ाइलों की सूची को कम करने के लिए एक अनुमति सूची को परिभाषित करें

चरण 4. ओईएम जीएसआई को एओएसपी जीएसआई के समान बायनेरिज़ बनाना

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

Make OEM GSI have the same binaries as AOSP GSI

चित्र 6. ओईएम जीएसआई को एओएसपी जीएसआई के समान बायनेरिज़ बनाना

ओईएम के लिए एसएसआई को परिभाषित करना

निर्माण के समय /सिस्टम विभाजन को सुरक्षित रखें

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

ओईएम /system विभाजन में उत्पाद-विशिष्ट मॉड्यूल को अस्थायी रूप से स्थापित करने की अनुमति देने के लिए एक सूची परिभाषित कर सकते हैं। हालाँकि, OEM GSI को OEM के सभी उत्पादों के लिए सामान्य बनाने के लिए सूची खाली होनी चाहिए। यह प्रक्रिया OEM GSI को परिभाषित करने के लिए है और AOSP GSI के चरणों से स्वतंत्र हो सकती है।

उत्पाद इंटरफ़ेस लागू करें

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

/system_ext विभाजन को सामान्य बनाना

/system_ext विभाजन विभिन्न डिवाइसों में भिन्न हो सकता है, क्योंकि इसमें डिवाइस-विशिष्ट, सिस्टम-बंडल मॉड्यूल हो सकते हैं। क्योंकि SSI में /system और /system_ext विभाजन शामिल हैं, /system_ext विभाजन में अंतर OEM को SSI को परिभाषित करने में बाधा डालता है। ओईएम के पास अपना स्वयं का एसएसआई हो सकता है और किसी भी अंतर को हटाकर और /system_ext विभाजन को सामान्य बनाकर उस एसएसआई को कई उपकरणों के बीच साझा कर सकते हैं।

यह अनुभाग /system_ext विभाजन को सामान्य बनाने के लिए सिफ़ारिशें देता है.

सिस्टम विभाजन में छिपे एपीआई को उजागर करें

कई उत्पाद विशिष्ट-एप्लिकेशन उत्पाद विभाजन में स्थापित नहीं किए जा सकते क्योंकि वे छिपे हुए एपीआई का उपयोग करते हैं, जो उत्पाद विभाजन में निषिद्ध हैं। डिवाइस-विशिष्ट एप्लिकेशन को उत्पाद विभाजन में ले जाने के लिए, छिपे हुए एपीआई का उपयोग हटा दें।

अनुप्रयोगों से छिपे हुए एपीआई को हटाने का पसंदीदा तरीका उन्हें बदलने के लिए वैकल्पिक सार्वजनिक या सिस्टम एपीआई ढूंढना है। यदि छिपे हुए एपीआई को बदलने के लिए कोई एपीआई नहीं है, तो ओईएम अपने उपकरणों के लिए नए सिस्टम एपीआई को परिभाषित करने के लिए एओएसपी में योगदान कर सकते हैं।

वैकल्पिक रूप से, ओईएम /system_ext विभाजन में अपनी स्वयं की जावा एसडीके लाइब्रेरी बनाकर कस्टम एपीआई को परिभाषित कर सकते हैं। यह सिस्टम विभाजन में छिपे हुए एपीआई का उपयोग कर सकता है, और उत्पाद या विक्रेता विभाजन में अनुप्रयोगों को एपीआई प्रदान कर सकता है। ओईएम को बैकवर्ड संगतता के लिए उत्पाद-सामना करने वाले एपीआई को फ्रीज करना होगा।

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

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

अधिक सटीक सेटिंग्स के लिए, एक प्रसारण रिसीवर घोषित करें जो अनावश्यक पैकेजों को अक्षम कर देता है। प्रसारण रिसीवर ACTION_BOOT_COMPLETED संदेश प्राप्त होने पर पैकेज को अक्षम करने के लिए setApplicationEnabledSetting को कॉल करता है।

स्थैतिक संसाधन ओवरले का उपयोग करने के बजाय आरआरओ को परिभाषित करें

एक स्थिर संसाधन ओवरले ओवरलेड पैकेजों में हेरफेर करता है। हालाँकि, यह एसएसआई को परिभाषित करने में बाधा उत्पन्न कर सकता है, इसलिए सुनिश्चित करें कि आरआरओ के लिए गुण चालू हैं और ठीक से सेट हैं। गुणों को निम्नानुसार सेट करके, ओईएम के पास आरआरओ के रूप में सभी ऑटो-जेनरेटेड ओवरले हो सकते हैं।

PRODUCT_ENFORCE_RRO_TARGETS := *
PRODUCT_ENFORCE_RRO_EXCLUDED_OVERLAYS := # leave it empty

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

अक्सर पूछे जाने वाले प्रश्न (FAQ)

क्या मैं एकाधिक एसएसआई परिभाषित कर सकता हूँ?

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

क्या मैं ओईएम जीएसआई के लिए generic_system.mk ( mainline_system.mk ) को संशोधित कर सकता हूं?

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

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

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