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

Android 11, product पार्टिशन को अनबंडल कर देता है ये सेगमेंट, system और vendor सेगमेंट से अलग हैं. इन बदलावों की वजह से, अब आपके पास नेटिव और Java के लिए, product पार्टीशन के ऐक्सेस को कंट्रोल करने का विकल्प है इंटरफ़ेस (यह ठीक उसी तरह काम करता है जैसे vendor के लिए इंटरफ़ेस पर, नीति उल्लंघन ठीक करने का तरीका (एनफ़ोर्समेंट) लागू किया जाता है विभाजन).

नेटिव इंटरफ़ेस लागू करें

नेटिव इंटरफ़ेस लागू करने के लिए, PRODUCT_PRODUCT_VNDK_VERSION सेट करें current तक. (शिपिंग के समय, वर्शन अपने-आप current पर सेट हो जाता है टारगेट के लिए एपीआई लेवल 29 से ज़्यादा है.) नीति उल्लंघन ठीक करने के तरीके (एनफ़ोर्समेंट) की मदद से ये काम किए जा सकते हैं:

• लिंक करने के लिए product पार्टिशन में नेटिव मॉड्यूल:
  • product विभाजन में मौजूद दूसरे मॉड्यूल के लिए स्टैटिक या डाइनैमिक तरीके से स्टैटिक, शेयर की गई या हेडर लाइब्रेरी शामिल करें.
  • system पार्टीशन में, VNDK लाइब्रेरी में डाइनैमिक तौर पर.
• लिंक करने के लिए, product पार्टीशन में मौजूद अनबंडल किए गए APK में जेएनआई लाइब्रेरी /product/lib या /product/lib64 में लाइब्रेरी (यह एनडीके लाइब्रेरी).

नीति उल्लंघन ठीक करने के तरीके (एनफ़ोर्समेंट) को लागू करने के बाद, product के अलावा, किसी अन्य हिस्से में लिंक जोड़ने की अनुमति नहीं है विभाजन.

बिल्ड टाइम नीति उल्लंघन ठीक करने का तरीका (Android.bp)

Android 11 में, सिस्टम मॉड्यूल एक प्रॉडक्ट बना सकते हैं कोर और वेंडर इमेज वैरिएंट के अलावा, इमेज वैरिएंट. नेटिव विज्ञापन इंटरफ़ेस लागू करने की सुविधा चालू है (PRODUCT_PRODUCT_VNDK_VERSION इस पर सेट है current):

• इसके बजाय, product पार्टीशन में मौजूद नेटिव मॉड्यूल, प्रॉडक्ट वैरिएंट में होते हैं .

• Android.bp फ़ाइलों में product_available: true वाले मॉड्यूल ये हैं जो प्रॉडक्ट वैरिएंट के लिए उपलब्ध होता है.

• जिन लाइब्रेरी या बाइनरी में product_specific: true बताया गया है वे यूआरएल से लिंक की जा सकती हैं ऐसी लाइब्रेरी जो product_specific: true या product_available: true को तय करती हैं अपनी Android.bp फ़ाइलों में.

• VNDK लाइब्रेरी की Android.bp फ़ाइलों में product_available: true होना ज़रूरी है इसलिए, product बाइनरी फ़ाइलें, VNDK लाइब्रेरी से लिंक की जा सकती हैं.

यहां दी गई टेबल में, इमेज बनाने के लिए इस्तेमाल की गई Android.bp प्रॉपर्टी की खास जानकारी दी गई है अलग-अलग वर्शन का इस्तेमाल करें.

Android.bp में प्रॉपर्टी	वैरिएंट बनाए गए
	नीति उल्लंघन ठीक करने के तरीके (एनफ़ोर्समेंट) से पहले	नीति उल्लंघन ठीक करने के तरीके (एनफ़ोर्समेंट) के बाद
डिफ़ॉल्ट (कोई नहीं)	कोर (/system, /system_ext और /product)	कोर (/system और /system_ext शामिल हैं, लेकिन नहीं /product)
system_ext_specific: true	कोर	कोर
product_specific: true	कोर	प्रॉडक्ट
vendor: true	वेंडर	वेंडर
vendor_available: true	कोर, वेंडर	कोर, वेंडर
product_available: true	लागू नहीं	कोर, प्रॉडक्ट
vendor_available: true और product_available: true	लागू नहीं	कोर, प्रॉडक्ट, वेंडर
system_ext_specific: true और vendor_available: true	कोर, वेंडर	कोर, वेंडर
product_specific: true और vendor_available: true	कोर, वेंडर	प्रॉडक्ट, वेंडर

बिल्ड टाइम नीति उल्लंघन ठीक करने का तरीका (Android.mk)

नेटिव इंटरफ़ेस एनफ़ोर्समेंट चालू होने पर, नेटिव मॉड्यूल product विभाजन में native:product का ऐसा लिंक है जो सिर्फ़ इससे लिंक हो सकता है अन्य native:product या native:vndk मॉड्यूल. किसी पेज से लिंक करने की कोशिश की जा रही है इन मॉड्यूल के अलावा, बिल्ड सिस्टम लिंक टाइप की जांच जनरेट करता है गड़बड़ी.

रनटाइम के दौरान नीति उल्लंघन ठीक करने का तरीका

जब नेटिव इंटरफ़ेस एनफ़ोर्समेंट चालू होता है, तो बायोनिक लिंकर, सिस्टम प्रोसेस को product लाइब्रेरी इस्तेमाल करने की अनुमति नहीं देता. product प्रक्रिया के लिए product सेक्शन बना कर, जो लिंक नहीं कर सकता product पार्टिशन के बाहर की लाइब्रेरी (हालांकि, ऐसी प्रोसेस एक-दूसरे से लिंक हो सकती हैं (VNDK लाइब्रेरी)). रनटाइम लिंक कॉन्फ़िगरेशन का उल्लंघन करने की कोशिशों की वजह से प्रोसेस पूरी नहीं हुई और CANNOT LINK EXECUTABLE गड़बड़ी का मैसेज जनरेट हुआ.

Java इंटरफ़ेस लागू करें

Java इंटरफ़ेस को लागू करने की सुविधा चालू करने के लिए, true के लिए PRODUCT_ENFORCE_PRODUCT_PARTITION_INTERFACE. (मान है जब टारगेट के लिए शिपिंग एपीआई लेवल यह होता है, तो अपने-आप true पर सेट हो जाता है 29 से ज़्यादा हो.) इसे चालू करने पर, नीति उल्लंघन ठीक करने के तरीके (एनफ़ोर्समेंट) की मदद से इन्हें अनुमति या अस्वीकार किया जाता है access:

एपीआई	/system	/system_ext	/product	/vendor	/data
सार्वजनिक एपीआई
@SystemApi
@छिपाएं एपीआई

जैसा कि vendor पार्टीशन के दौरान होता है, product में मौजूद कोई ऐप्लिकेशन या Java लाइब्रेरी विभाजन की मदद से सिर्फ़ सार्वजनिक और सिस्टम एपीआई का इस्तेमाल किया जा सकता है; किसी लाइब्रेरी से लिंक करना छिपे हुए एपीआई का इस्तेमाल करने वाले एपीआई की अनुमति नहीं है. इस पाबंदी में बिल्ड से लिंक करना शामिल है रनटाइम में समय और रिफ़्लेक्शन की जानकारी मिलती है.

बिल्ड टाइम एनफ़ॉर्समेंट

बिल्ड के समय, Make और Sug ने इस बात की पुष्टि की है कि product में Java मॉड्यूल मौजूद है विभाजन, platform_apis की जांच करके छिपे हुए API का इस्तेमाल नहीं करता है और sdk_version फ़ील्ड. product विभाजन में ऐप्लिकेशन के sdk_version को यह होना चाहिए उसे एपीआई के current, system_current या अंकों वाले वर्शन से भरा जाना चाहिए और platform_apis फ़ील्ड खाली होना चाहिए.

रनटाइम के दौरान नीति उल्लंघन ठीक करने का तरीका

Android रनटाइम इस बात की पुष्टि करता है कि product पार्टिशन में मौजूद ऐप्लिकेशन इसका इस्तेमाल नहीं करते छिपे हुए एपीआई, जिनमें रिफ़्लेक्शन भी शामिल है. ज़्यादा जानकारी के लिए, इन पर लागू होने वाली पाबंदियां देखें SDK टूल के अलावा कोई अन्य ऐप्लिकेशन इंटरफ़ेस में बदल सकते हैं.

प्रॉडक्ट इंटरफ़ेस पर नीति उल्लंघन ठीक करने का तरीका (एनफ़ोर्समेंट) चालू करें

प्रॉडक्ट इंटरफ़ेस पर, नीति उल्लंघन ठीक करने के तरीके (एनफ़ोर्समेंट) को चालू करने के लिए, इस सेक्शन में दिया गया तरीका अपनाएं.

चरण	टास्क	ज़रूरी है
1	अपना खुद का सिस्टम Makefile तय करें जो system पार्टिशन चुनें. इसके बाद, आर्टफ़ैक्ट पाथ की ज़रूरी शर्तों की जांच सेट करें device.mk में (नॉन-सिस्टम मॉड्यूल इंस्टॉल होने से रोकने के लिए) को system पार्टीशन में जोड़ता है).	नहीं
2	अनुमति वाली सूची से स्टोरेज खाली करें.	नहीं
3	नेटिव इंटरफ़ेस लागू करें और रनटाइम लिंक के काम न करने की समस्याओं की पहचान करें (ये Java लागू करने के साथ-साथ).	Y
4	Java इंटरफ़ेस लागू करें और रनटाइम के व्यवहार की पुष्टि करें (साथ-साथ चलाया जा सकता है) करने के लिए कहा जाएगा.	Y
5	रनटाइम के व्यवहार देखें.	Y
6	प्रॉडक्ट इंटरफ़ेस पर नीति उल्लंघन ठीक करने के तरीके (एनफ़ोर्समेंट) की मदद से device.mk को अपडेट करें.	Y

पहला चरण: मेकफ़ाइल बनाएं और आर्टफ़ैक्ट के पाथ की जांच करने की सुविधा चालू करें

इस चरण में, system मेकफ़ाइल सेट की जाती है.

1. ऐसी मेकफ़ाइल बनाएं जो system पार्टीशन के लिए पैकेज के बारे में जानकारी देती हो. इसके लिए उदाहरण के लिए, इनका इस्तेमाल करके एक oem_system.mk फ़ाइल बनाएं:

   $(call inherit-product, $(SRC_TARGET_DIR)/product/handheld_system.mk)
   $(call inherit-product, $(SRC_TARGET_DIR)/product/telephony_system.mk)
   
   # Applications
   PRODUCT_PACKAGES += \
       CommonSystemApp1 \
       CommonSystemApp2 \
       CommonSystemApp3 \
   
   # Binaries
   PRODUCT_PACKAGES += \
       CommonSystemBin1 \
       CommonSystemBin2 \
       CommonSystemBin3 \
   
   # Libraries
   PRODUCT_PACKAGES += \
       CommonSystemLib1 \
       CommonSystemLib2 \
       CommonSystemLib3 \
   
   PRODUCT_SYSTEM_NAME := oem_system
   PRODUCT_SYSTEM_BRAND := Android
   PRODUCT_SYSTEM_MANUFACTURER := Android
   PRODUCT_SYSTEM_MODEL := oem_system
   PRODUCT_SYSTEM_DEVICE := generic
   
   # For system-as-root devices, system.img should be mounted at /, so we
   # include ROOT here.
   _my_paths := \
    $(TARGET_COPY_OUT_ROOT)/ \
    $(TARGET_COPY_OUT_SYSTEM)/ \
   
   $(call require-artifacts-in-path, $(_my_paths),)
   

2. device.mk फ़ाइल में, system के लिए सामान्य मेकफ़ाइल को इनहेरिट करें विभाजन करें और आर्टफ़ैक्ट पाथ की ज़रूरी शर्तों की जांच करें. उदाहरण के लिए:

   $(call inherit-product, $(SRC_TARGET_DIR)/product/oem_system.mk)
   
   # Enable artifact path requirements checking
   PRODUCT_ENFORCE_ARTIFACT_PATH_REQUIREMENTS := strict
   

आर्टफ़ैक्ट पाथ की ज़रूरी शर्तों के बारे में जानकारी

जब PRODUCT_ENFORCE_ARTIFACT_PATH_REQUIREMENTS को true या strict पर सेट किया जाता है, तो बिल्ड सिस्टम, अन्य मेकफ़ाइल में तय किए गए पैकेज को require-artifacts-in-path में बताए गए पाथ और पैकेज को रोकते हैं पाथ के बाहर आर्टफ़ैक्ट इंस्टॉल करने से, मौजूदा Makefile में तय किए गए require-artifacts-in-path में परिभाषित किया गया है.

ऊपर दिए गए उदाहरण में, PRODUCT_ENFORCE_ARTIFACT_PATH_REQUIREMENTS के साथ strict, oem_system.mk से बाहर की प्रोसेसिंग में, इस डिवाइस पर इंस्टॉल किए गए मॉड्यूल शामिल नहीं किए जा सकते root या system विभाजन. इन मॉड्यूल को शामिल करने के लिए, आपको या तो उन्हें oem_system.mk फ़ाइल में या शामिल की गई मेकफ़ाइल में परिभाषित किया जा सकता है. अस्वीकार किए गए पाथ पर मॉड्यूल इंस्टॉल करने की कोशिश करने पर, बिल्ड ब्रेक होता है. समस्या ठीक करने के लिए ब्रेक होता है, तो इनमें से कोई एक काम करें:

• पहला विकल्प: इसमें शामिल मेकफ़ाइल में सिस्टम मॉड्यूल शामिल करना oem_system.mk. इससे यह पक्का होता है कि आर्टफ़ैक्ट पाथ की ज़रूरी शर्त पूरी हो जाए (जैसा कि मॉड्यूल अब शामिल मेकफ़ाइल में मौजूद होते हैं) और इसलिए, `ज़रूरी आर्टफ़ैक्ट-इन-पाथ में पाथ का सेट है.

• दूसरा विकल्प: system_ext या product पार्टीशन में मॉड्यूल इंस्टॉल करें (और system पार्टीशन में मॉड्यूल इंस्टॉल न करें).

• तीसरा विकल्प: इसमें मॉड्यूल जोड़ना PRODUCT_ARTIFACT_PATH_REQUIREMENT_ALLOWED_LIST. इसमें अनुमति वाले मॉड्यूल की सूची है इंस्टॉल करने के लिए.

दूसरा चरण: अनुमति वाली सूची खाली करना

इस चरण में, आप PRODUCT_ARTIFACT_PATH_REQUIREMENT_ALLOWED_LIST खाली है, ताकि oem_system.mk को शेयर करने वाले सभी डिवाइस भी एक system को शेयर कर सकें इमेज. अनुमति वाली सूची को खाली करने के लिए, सूची के सभी मॉड्यूल फ़ाइलें बनाने के लिए, system_ext या product पार्टीशन करें या उन्हें system में जोड़ें. यह चरण ज़रूरी नहीं है, क्योंकि आम system इमेज तय करना ज़रूरी नहीं है उसे प्रॉडक्ट इंटरफ़ेस पर लागू करने की सुविधा मिलती है. हालांकि, अनुमति वाली सूची को खाली करना system_ext के साथ system सीमा तय करने में मदद मिली.

तीसरा चरण: नेटिव इंटरफ़ेस लागू करें

इस चरण में, आप PRODUCT_PRODUCT_VNDK_VERSION := current सेट करते हैं, फिर यह देखते हैं बनाने और रनटाइम की गड़बड़ियों के बारे में जानने के लिए. डिवाइस के बूट और लॉग की जांच करने के लिए और रनटाइम लिंक के काम न करने वाले लिंक का पता लगाकर, उन्हें ठीक करें:

1. PRODUCT_PRODUCT_VNDK_VERSION := current सेट करें.

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

   • जिस भी hidl_interface मॉड्यूल में product_specific: true है वह सिस्टम मॉड्यूल के लिए उपलब्ध है. इसे ठीक करने के लिए, product_specific: true को बदलें system_ext_specific: true के साथ.
   • ऐसा हो सकता है कि प्रॉडक्ट के लिए ज़रूरी प्रॉडक्ट वैरिएंट, मॉड्यूल में उपलब्ध न हो मॉड्यूल देखें. इसे ठीक करने के लिए, उस मॉड्यूल को इसके अनुसार product पार्टीशन में उपलब्ध कराएं product_available: true सेटिंग कर रहा है या मॉड्यूल को product में ले जा सकता है product_specific: true को सेट करके सेगमेंट किया गया.

3. बिल्ड की गड़बड़ियां ठीक करें और पक्का करें कि डिवाइस सही से बन जाए.

4. इमेज को फ़्लैश करें और डिवाइस के बूट और लॉग में रनटाइम की गड़बड़ियां देखें.

   • अगर टेस्ट केस लॉग का linker टैग, CANNOT LINK EXECUTABLE दिखाता है मैसेज दिखाई देता है, तो मेक फ़ाइल में डिपेंडेंसी नहीं है (और इस पर कैप्चर नहीं किया गया था) बिल्ड टाइम).
   • बिल्ड सिस्टम से इसकी जांच करने के लिए, ज़रूरी लाइब्रेरी को shared_libs: या required: फ़ील्ड.

5. ऊपर दिए गए निर्देशों का इस्तेमाल करके, छूटी हुई डिपेंडेंसी हल करें.

चौथा चरण: Java इंटरफ़ेस लागू करें

इस चरण में आपने PRODUCT_ENFORCE_PRODUCT_PARTITION_INTERFACE := true, इसके बाद, बिल्ड से जुड़ी गड़बड़ियों का पता लगाकर उन्हें ठीक करें. दो तरह की गड़बड़ियों को देखें:

• लिंक टाइप से जुड़ी गड़बड़ियां. इस गड़बड़ी का मतलब है कि कोई ऐप्लिकेशन Java मॉड्यूल से लिंक है जिनका बड़ा sdk_version है. इसे ठीक करने के लिए, आप अपने ऐप्लिकेशन के sdk_version या लाइब्रेरी की sdk_version प्रतिबंधित करें. गड़बड़ी का उदाहरण:

  error: frameworks/base/packages/SystemUI/Android.bp:138:1: module "SystemUI" variant "android_common": compiles against system API, but dependency "telephony-common" is compiling against private API.Adjust sdk_version: property of the source or target module so that target module is built with the same or smaller API set than the source.
  

• सिंबल से जुड़ी गड़बड़ियां. इस गड़बड़ी से पता चलता है कि कोई सिंबल नहीं मिल सकता, क्योंकि वह छिपे हुए एपीआई में होता है. ठीक करने के लिए, किसी दृश्यमान (गैर-छिपा हुआ) API का उपयोग करें या किसी वैकल्पिक है. गड़बड़ी का उदाहरण:

  frameworks/opt/net/voip/src/java/com/android/server/sip/SipSessionGroup.java:1051: error: cannot find symbol
              ProxyAuthenticate proxyAuth = (ProxyAuthenticate)response.getHeader(
                                             ^
    symbol:   class ProxyAuthenticate
    location: class SipSessionGroup.SipSessionImpl
  

पांचवां चरण: रनटाइम के व्यवहार देखना

इस चरण में यह पुष्टि की जाती है कि रनटाइम के व्यवहार उम्मीद के मुताबिक हैं. उन ऐप्लिकेशन के लिए जो डीबग करने लायक, आप StrictMode.detectNonSdkApiUsage (यह तब एक लॉग जनरेट करता है, जब ऐप्लिकेशन छिपा हुआ एपीआई). वैकल्पिक रूप से, आप वेरिडेक्स इस्तेमाल का टाइप (लिंक करने या रिफ़्लेक्शन) पाने के लिए, स्टैटिक विश्लेषण टूल पाबंदी लेवल, और कॉल स्टैक की जानकारी शामिल की जाती है.

• Veridex सिंटैक्स:

  ./art/tools/veridex/appcompat.sh --dex-file={apk file}
  

• veridex नतीजे का उदाहरण:

  #1: Linking greylist-max-o Landroid/animation/AnimationHandler;-><init>()V use(s):
         Lcom/android/systemui/pip/phone/PipMotionHelper;-><init>(Landroid/content/Context;Landroid/app/IActivityManager;Landroid/app/IActivityTaskManager;Lcom/android/systemui/pip/phone/PipMenuActivityController;Lcom/android/internal/policy/PipSnapAlgorithm;Lcom/android/systemui/statusbar/FlingAnimationUtils;)V
  
  #1332: Reflection greylist Landroid/app/Activity;->mMainThread use(s):
         Landroidx/core/app/ActivityRecreator;->getMainThreadField()Ljava/lang/reflect/Field;
  

veridex के इस्तेमाल के बारे में जानकारी के लिए, veridex का इस्तेमाल करके टेस्ट करना देखें टूल है.

छठा चरण: device.mk को अपडेट करना

बिल्ड और रनटाइम की सभी गड़बड़ियों को ठीक करने और उस रनटाइम की पुष्टि करने के बाद व्यवहार उम्मीद के मुताबिक हैं, device.mk में इन्हें सेट करें:

• PRODUCT_PRODUCT_VNDK_VERSION := current
• PRODUCT_ENFORCE_PRODUCT_PARTITION_INTERFACE := true