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 से ज़्यादा हो.) इसे चालू करने पर, नीति उल्लंघन ठीक करने के तरीके (एनफ़ोर्समेंट) की मदद से इन्हें अनुमति या अस्वीकार किया जाता है
ऐक्सेस:
एपीआई | /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
मेकफ़ाइल सेट की जाती है.
ऐसी मेकफ़ाइल बनाएं जो
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),)
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
सेट करते हैं, फिर यह देखते हैं
बनाने और रनटाइम की गड़बड़ियों के बारे में जानने के लिए. डिवाइस के बूट और लॉग की जांच करने के लिए
और रनटाइम लिंक के काम न करने वाले लिंक का पता लगाकर, उन्हें ठीक करें:
PRODUCT_PRODUCT_VNDK_VERSION := current
सेट करें.डिवाइस बनाएं और बिल्ड से जुड़ी गड़बड़ियां देखें. आपको थोड़ी-बहुत प्रॉडक्ट के जो वैरिएंट या मुख्य वैरिएंट मौजूद नहीं हैं उनके लिए ब्रेक. सामान्य ब्रेक शामिल करें:
- जिस भी
hidl_interface
मॉड्यूल मेंproduct_specific: true
है वह सिस्टम मॉड्यूल के लिए उपलब्ध है. इसे ठीक करने के लिए,product_specific: true
को बदलेंsystem_ext_specific: true
के साथ. - ऐसा हो सकता है कि प्रॉडक्ट के लिए ज़रूरी प्रॉडक्ट वैरिएंट, मॉड्यूल में उपलब्ध न हो
मॉड्यूल देखें. इसे ठीक करने के लिए, उस मॉड्यूल को इसके अनुसार
product
पार्टीशन में उपलब्ध कराएंproduct_available: true
सेटिंग कर रहा है या मॉड्यूल कोproduct
में ले जा सकता हैproduct_specific: true
को सेट करके सेगमेंट किया गया.
- जिस भी
बिल्ड की गड़बड़ियां ठीक करें और पक्का करें कि डिवाइस सही से बन जाए.
इमेज को फ़्लैश करें और डिवाइस के बूट और लॉग में रनटाइम की गड़बड़ियां देखें.
- अगर टेस्ट केस लॉग का
linker
टैग,CANNOT LINK EXECUTABLE
दिखाता है मैसेज दिखाई देता है, तो मेक फ़ाइल में डिपेंडेंसी नहीं है (और इस पर कैप्चर नहीं किया गया था) बिल्ड टाइम). - बिल्ड सिस्टम से इसकी जांच करने के लिए, ज़रूरी लाइब्रेरी को
shared_libs:
याrequired:
फ़ील्ड.
- अगर टेस्ट केस लॉग का
ऊपर दिए गए निर्देशों का इस्तेमाल करके, छूटी हुई डिपेंडेंसी हल करें.
चौथा चरण: 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