एंड्रॉइड 8.1 और उच्चतर में, बिल्ड सिस्टम में अंतर्निहित VNDK समर्थन है। जब वीएनडीके समर्थन सक्षम होता है, तो बिल्ड सिस्टम मॉड्यूल के बीच निर्भरता की जांच करता है, विक्रेता मॉड्यूल के लिए एक विक्रेता-विशिष्ट संस्करण बनाता है, और स्वचालित रूप से उन मॉड्यूल को निर्दिष्ट निर्देशिकाओं में स्थापित करता है।
VNDK बिल्ड समर्थन उदाहरण
इस उदाहरण में, Android.bp
मॉड्यूल परिभाषा libexample
नामक लाइब्रेरी को परिभाषित करती है। vendor_available
संपत्ति फ्रेमवर्क मॉड्यूल को इंगित करती है और विक्रेता मॉड्यूल libexample
पर निर्भर हो सकते हैं:
फ्रेमवर्क निष्पादन योग्य /system/bin/foo
और विक्रेता निष्पादन योग्य /vendor/bin/bar
दोनों libexample
पर निर्भर करते हैं और उनके shared_libs
गुणों में libexample
होता है।
यदि libexample
का उपयोग फ्रेमवर्क मॉड्यूल और विक्रेता मॉड्यूल दोनों द्वारा किया जाता है, तो libexample
के दो प्रकार बनाए जाते हैं। मुख्य संस्करण ( libexample
के नाम पर) का उपयोग फ्रेमवर्क मॉड्यूल द्वारा किया जाता है और विक्रेता संस्करण ( libexample.vendor
के नाम पर) का उपयोग विक्रेता मॉड्यूल द्वारा किया जाता है। दो वेरिएंट अलग-अलग निर्देशिकाओं में स्थापित हैं:
- मुख्य संस्करण
/system/lib[64]/libexample.so
में स्थापित है। - विक्रेता संस्करण VNDK APEX में स्थापित है क्योंकि
vndk.enabled
true
है।
अधिक विवरण के लिए, मॉड्यूल परिभाषा देखें।
बिल्ड समर्थन कॉन्फ़िगर करना
किसी उत्पाद डिवाइस के लिए पूर्ण बिल्ड सिस्टम समर्थन सक्षम करने के लिए, BoardConfig.mk
में BOARD_VNDK_VERSION
जोड़ें:
BOARD_VNDK_VERSION := current
इस सेटिंग का वैश्विक प्रभाव होता है: जब BoardConfig.mk
में परिभाषित किया जाता है, तो सभी मॉड्यूल की जाँच की जाती है। चूंकि आपत्तिजनक मॉड्यूल को काली सूची में डालने या श्वेत सूची में डालने की कोई व्यवस्था नहीं है, इसलिए आपको BOARD_VNDK_VERSION
जोड़ने से पहले सभी अनावश्यक निर्भरताएं साफ़ कर देनी चाहिए। आप अपने पर्यावरण चर में BOARD_VNDK_VERSION
सेट करके मॉड्यूल का परीक्षण और संकलन कर सकते हैं:
$ BOARD_VNDK_VERSION=current m module_name.vendor
जब BOARD_VNDK_VERSION
सक्षम होता है, तो कई डिफ़ॉल्ट वैश्विक हेडर खोज पथ हटा दिए जाते हैं। इसमे शामिल है:
-
frameworks/av/include
-
frameworks/native/include
-
frameworks/native/opengl/include
-
hardware/libhardware/include
-
hardware/libhardware_legacy/include
-
hardware/ril/include
-
libnativehelper/include
-
libnativehelper/include_deprecated
-
system/core/include
-
system/media/audio/include
यदि कोई मॉड्यूल इन निर्देशिकाओं के हेडर पर निर्भर करता है, तो आपको header_libs
, static_libs
और/या shared_libs
के साथ निर्भरताएं (स्पष्ट रूप से) निर्दिष्ट करनी होंगी।
वीएनडीके एपेक्स
एंड्रॉइड 10 और उससे पहले के संस्करण में, vndk.enabled
वाले मॉड्यूल /system/lib[64]/vndk[-sp]-${VER}
में इंस्टॉल किए गए थे। एंड्रॉइड 11 और उच्चतर में, VNDK लाइब्रेरीज़ को APEX प्रारूप में पैक किया गया है और VNDK APEX का नाम com.android.vndk.v${VER}
है। डिवाइस कॉन्फ़िगरेशन के आधार पर, VNDK APEX चपटा या बिना चपटा है और विहित पथ /apex/com.android.vndk.v${VER}
से उपलब्ध है।
मॉड्यूल परिभाषा
BOARD_VNDK_VERSION
के साथ Android बनाने के लिए, आपको मॉड्यूल परिभाषा को Android.mk
या Android.bp
में संशोधित करना होगा। यह खंड विभिन्न प्रकार की मॉड्यूल परिभाषाओं, कई वीएनडीके-संबंधित मॉड्यूल गुणों और बिल्ड सिस्टम में लागू निर्भरता जांच का वर्णन करता है।
विक्रेता मॉड्यूल
विक्रेता मॉड्यूल विक्रेता-विशिष्ट निष्पादन योग्य या साझा लाइब्रेरी हैं जिन्हें विक्रेता विभाजन में स्थापित किया जाना चाहिए। Android.bp
फ़ाइलों में, विक्रेता मॉड्यूल को विक्रेता या मालिकाना संपत्ति को true
पर सेट करना होगा। Android.mk
फ़ाइलों में, विक्रेता मॉड्यूल को LOCAL_VENDOR_MODULE
या LOCAL_PROPRIETARY_MODULE
को true
पर सेट करना होगा।
यदि BOARD_VNDK_VERSION
परिभाषित किया गया है, तो बिल्ड सिस्टम विक्रेता मॉड्यूल और फ्रेमवर्क मॉड्यूल के बीच निर्भरता की अनुमति नहीं देता है और त्रुटियों का उत्सर्जन करता है:
-
vendor:true
के बिना एक मॉड्यूल,vendor:true
, या वाले मॉड्यूल पर निर्भर करता है -
vendor:true
वाला एक मॉड्यूल एक गैर-llndk_library
मॉड्यूल पर निर्भर करता है जिसमें न तोvendor:true
है और न हीvendor_available:true
।
निर्भरता जांच Android.bp
में header_libs
, static_libs
और shared_libs
पर और Android.mk
में LOCAL_HEADER_LIBRARIES
, LOCAL_STATIC_LIBRARIES
और LOCAL_SHARED_LIBRARIES
पर लागू होती है।
एलएल-एनडीके
एलएल-एनडीके साझा लाइब्रेरी स्थिर एबीआई के साथ साझा लाइब्रेरी हैं। फ्रेमवर्क और विक्रेता मॉड्यूल दोनों समान और नवीनतम कार्यान्वयन साझा करते हैं। प्रत्येक एलएल-एनडीके साझा लाइब्रेरी के लिए, cc_library
में एक प्रतीक फ़ाइल के साथ एक llndk
संपत्ति होती है:
cc_library { name: "libvndksupport", llndk: { symbol_file: "libvndksupport.map.txt", }, }
प्रतीक फ़ाइल विक्रेता मॉड्यूल को दिखाई देने वाले प्रतीकों का वर्णन करती है। उदाहरण के लिए:
LIBVNDKSUPPORT { global: android_load_sphal_library; # llndk android_unload_sphal_library; # llndk local: *; };
प्रतीक फ़ाइल के आधार पर, बिल्ड सिस्टम विक्रेता मॉड्यूल के लिए एक स्टब साझा लाइब्रेरी उत्पन्न करता है, जो BOARD_VNDK_VERSION
सक्षम होने पर इन लाइब्रेरी से लिंक होता है। एक प्रतीक को स्टब साझा लाइब्रेरी में तभी शामिल किया जाता है जब वह:
-
_PRIVATE
या_PLATFORM
वाले अनुभाग के अंत में परिभाषित नहीं है, - इसमें
#platform-only
टैग नहीं है, और -
#introduce*
टैग नहीं है या टैग लक्ष्य से मेल खाता है।
वीएनडीके
Android.bp
फ़ाइलों में, cc_library
, cc_library_static
, cc_library_shared
, और cc_library_headers
मॉड्यूल परिभाषाएँ तीन VNDK-संबंधित गुणों का समर्थन करती हैं: vendor_available
, vndk.enabled
, और vndk.support_system_process
।
यदि vendor_available
या vndk.enabled
true
है, तो दो वेरिएंट ( कोर और विक्रेता ) बनाए जा सकते हैं। कोर वेरिएंट को फ्रेमवर्क मॉड्यूल के रूप में माना जाना चाहिए और विक्रेता वेरिएंट को विक्रेता मॉड्यूल के रूप में माना जाना चाहिए। यदि कुछ फ्रेमवर्क मॉड्यूल इस मॉड्यूल पर निर्भर करते हैं, तो कोर वेरिएंट बनाया जाता है। यदि कुछ विक्रेता मॉड्यूल इस मॉड्यूल पर निर्भर करते हैं, तो विक्रेता संस्करण बनाया जाता है। बिल्ड सिस्टम निम्नलिखित निर्भरता जाँच लागू करता है:
- मुख्य वैरिएंट हमेशा केवल फ़्रेमवर्क वाला होता है और विक्रेता मॉड्यूल के लिए पहुंच योग्य नहीं होता है।
- विक्रेता संस्करण हमेशा फ्रेमवर्क मॉड्यूल के लिए पहुंच योग्य नहीं होता है।
- विक्रेता संस्करण की सभी निर्भरताएँ, जो
header_libs
,static_libs
, और/याshared_libs
में निर्दिष्ट हैं, या तो एकllndk_library
याvendor_available
याvndk.enabled
वाला एक मॉड्यूल होनी चाहिए। - यदि
vendor_available
true
है, तो विक्रेता संस्करण सभी विक्रेता मॉड्यूल के लिए पहुंच योग्य है। - यदि
vendor_available
false
है, तो विक्रेता संस्करण केवल अन्य वीएनडीके या वीएनडीके-एसपी मॉड्यूल के लिए पहुंच योग्य है (यानी,vendor:true
वाले मॉड्यूलvendor_available:false
मॉड्यूल को लिंक नहीं कर सकते हैं)।
cc_library
या cc_library_shared
के लिए डिफ़ॉल्ट इंस्टॉलेशन पथ निम्नलिखित नियमों द्वारा निर्धारित किया जाता है:
- मुख्य संस्करण
/system/lib[64]
पर स्थापित है। - विक्रेता संस्करण स्थापना पथ भिन्न हो सकता है:
- यदि
vndk.enabled
false
है, तो विक्रेता संस्करण/vendor/lib[64]
में स्थापित हो जाता है। - यदि
vndk.enabled
true
है, तो विक्रेता संस्करण VNDK APEX (com.android.vndk.v${VER}
) में स्थापित हो जाता है।
- यदि
नीचे दी गई तालिका सारांशित करती है कि बिल्ड सिस्टम विक्रेता वेरिएंट को कैसे संभालता है:
विक्रेता_उपलब्ध | vndk सक्रिय | vndk support_same_process | विक्रेता भिन्न विवरण |
---|---|---|---|
true | false | false | विक्रेता वेरिएंट केवल VND हैं। साझा लाइब्रेरीज़ को /vendor/lib[64] में स्थापित किया गया है। |
true | अमान्य (बिल्ड त्रुटि) | ||
true | false | विक्रेता वेरिएंट VNDK हैं। साझा लाइब्रेरी VNDK APEX पर स्थापित की गई हैं। | |
true | विक्रेता वेरिएंट VNDK-SP हैं। साझा लाइब्रेरी VNDK APEX पर स्थापित की गई हैं। | ||
| | | कोई विक्रेता वैरिएंट नहीं. यह मॉड्यूल केवल FWK है। |
true | अमान्य (बिल्ड त्रुटि) | ||
true | false | विक्रेता वेरिएंट VNDK-Private हैं। साझा लाइब्रेरी VNDK APEX पर स्थापित की गई हैं। इन्हें सीधे विक्रेता मॉड्यूल द्वारा उपयोग नहीं किया जाना चाहिए। | |
true | विक्रेता वेरिएंट VNDK-SP-Private हैं। साझा लाइब्रेरी VNDK APEX पर स्थापित की गई हैं। इन्हें सीधे विक्रेता मॉड्यूल द्वारा उपयोग नहीं किया जाना चाहिए। |
वीएनडीके एक्सटेंशन
VNDK एक्सटेंशन अतिरिक्त API के साथ VNDK साझा लाइब्रेरी हैं। एक्सटेंशन /vendor/lib[64]/vndk[-sp]
(संस्करण प्रत्यय के बिना) पर स्थापित किए जाते हैं और रनटाइम पर मूल VNDK साझा लाइब्रेरी को ओवरराइड करते हैं।
VNDK एक्सटेंशन को परिभाषित करना
Android 9 और उच्चतर में, Android.bp
मूल रूप से VNDK एक्सटेंशन का समर्थन करता है। VNDK एक्सटेंशन बनाने के लिए, एक vendor:true
और एक extends
संपत्ति:
cc_library { name: "libvndk", vendor_available: true, vndk: { enabled: true, }, } cc_library { name: "libvndk_ext", vendor: true, vndk: { enabled: true, extends: "libvndk", }, }
vendor:true
, vndk.enabled:true
, और extends
गुणों वाला एक मॉड्यूल VNDK एक्सटेंशन को परिभाषित करता है:
-
extends
संपत्ति को एक आधार VNDK साझा लाइब्रेरी नाम (या VNDK-SP साझा लाइब्रेरी नाम) निर्दिष्ट करना होगा। - वीएनडीके एक्सटेंशन (या वीएनडीके-एसपी एक्सटेंशन) का नाम उन आधार मॉड्यूल नामों के नाम पर रखा गया है जिनसे वे विस्तारित होते हैं। उदाहरण के लिए,
libvndk_ext
का आउटपुट बाइनरीlibvndk.so
libvndk_ext.so
। - VNDK एक्सटेंशन
/vendor/lib[64]/vndk
में इंस्टॉल किए गए हैं। - VNDK-SP एक्सटेंशन
/vendor/lib[64]/vndk-sp
में इंस्टॉल किए गए हैं। - आधार साझा लाइब्रेरी में
vndk.enabled:true
औरvendor_available:true
दोनों होने चाहिए।
VNDK-SP एक्सटेंशन को VNDK-SP साझा लाइब्रेरी से विस्तारित होना चाहिए ( vndk.support_system_process
बराबर होना चाहिए):
cc_library { name: "libvndk_sp", vendor_available: true, vndk: { enabled: true, support_system_process: true, }, } cc_library { name: "libvndk_sp_ext", vendor: true, vndk: { enabled: true, extends: "libvndk_sp", support_system_process: true, }, }
VNDK एक्सटेंशन (या VNDK-SP एक्सटेंशन) अन्य विक्रेता साझा लाइब्रेरी पर निर्भर हो सकते हैं:
cc_library { name: "libvndk", vendor_available: true, vndk: { enabled: true, }, } cc_library { name: "libvndk_ext", vendor: true, vndk: { enabled: true, extends: "libvndk", }, shared_libs: [ "libvendor", ], } cc_library { name: "libvendor", vendor: true, }
VNDK एक्सटेंशन का उपयोग करना
यदि कोई विक्रेता मॉड्यूल VNDK एक्सटेंशन द्वारा परिभाषित अतिरिक्त API पर निर्भर करता है, तो मॉड्यूल को अपनी shared_libs
प्रॉपर्टी में VNDK एक्सटेंशन का नाम निर्दिष्ट करना होगा:
// A vendor shared library example cc_library { name: "libvendor", vendor: true, shared_libs: [ "libvndk_ext", ], } // A vendor executable example cc_binary { name: "vendor-example", vendor: true, shared_libs: [ "libvndk_ext", ], }
यदि कोई विक्रेता मॉड्यूल VNDK एक्सटेंशन पर निर्भर करता है, तो वे VNDK एक्सटेंशन /vendor/lib[64]/vndk[-sp]
पर स्वचालित रूप से इंस्टॉल हो जाते हैं। यदि कोई मॉड्यूल अब VNDK एक्सटेंशन पर निर्भर नहीं है, तो साझा लाइब्रेरी को हटाने के लिए CleanSpec.mk
में एक साफ़ चरण जोड़ें। उदाहरण के लिए:
$(call add-clean-step, rm -rf $(TARGET_OUT_VENDOR)/lib/libvndk.so)
सशर्त संकलन
यह अनुभाग वर्णन करता है कि निम्नलिखित तीन वीएनडीके साझा पुस्तकालयों के बीच सूक्ष्म अंतर (उदाहरण के लिए किसी एक वेरिएंट में एक सुविधा जोड़ना या हटाना) से कैसे निपटें:
- मुख्य संस्करण (जैसे
/system/lib[64]/libexample.so
) - विक्रेता संस्करण (जैसे
/apex/com.android.vndk.v${VER}/lib[64]/libexample.so
) - VNDK एक्सटेंशन (जैसे
/vendor/lib[64]/vndk[-sp]/libexample.so
)
सशर्त संकलक झंडे
एंड्रॉइड बिल्ड सिस्टम डिफ़ॉल्ट रूप से विक्रेता वेरिएंट और VNDK एक्सटेंशन के लिए __ANDROID_VNDK__
को परिभाषित करता है। आप C प्रीप्रोसेसर गार्ड के साथ कोड की सुरक्षा कर सकते हैं:
void all() { } #if !defined(__ANDROID_VNDK__) void framework_only() { } #endif #if defined(__ANDROID_VNDK__) void vndk_only() { } #endif
__ANDROID_VNDK__
के अलावा, Android.bp
में अलग-अलग cflags
या cppflags
निर्दिष्ट किए जा सकते हैं। target.vendor
में निर्दिष्ट cflags
या cppflags
विक्रेता संस्करण के लिए विशिष्ट है।
उदाहरण के लिए, निम्नलिखित Android.bp
libexample
और libexample_ext
परिभाषित करता है:
cc_library { name: "libexample", srcs: ["src/example.c"], vendor_available: true, vndk: { enabled: true, }, target: { vendor: { cflags: ["-DLIBEXAMPLE_ENABLE_VNDK=1"], }, }, } cc_library { name: "libexample_ext", srcs: ["src/example.c"], vendor: true, vndk: { enabled: true, extends: "libexample", }, cflags: [ "-DLIBEXAMPLE_ENABLE_VNDK=1", "-DLIBEXAMPLE_ENABLE_VNDK_EXT=1", ], }
और यह src/example.c
की कोड सूची है:
void all() { } #if !defined(LIBEXAMPLE_ENABLE_VNDK) void framework_only() { } #endif #if defined(LIBEXAMPLE_ENABLE_VNDK) void vndk() { } #endif #if defined(LIBEXAMPLE_ENABLE_VNDK_EXT) void vndk_ext() { } #endif
इन दो फ़ाइलों के अनुसार, बिल्ड सिस्टम निम्नलिखित निर्यातित प्रतीकों के साथ साझा लाइब्रेरी उत्पन्न करता है:
स्थापना पथ | निर्यात किए गए प्रतीक |
---|---|
/system/lib[64]/libexample.so | all , framework_only |
/apex/com.android.vndk.v${VER}/lib[64]/libexample.so | all , vndk |
/vendor/lib[64]/vndk/libexample.so | all , vndk , vndk_ext |
निर्यातित प्रतीकों पर आवश्यकताएँ
वीएनडीके एबीआई चेकर वीएनडीके विक्रेता वेरिएंट और वीएनडीके एक्सटेंशन के एबीआई की तुलना prebuilts/abi-dumps/vndk
के तहत संदर्भ एबीआई डंप से करता है।
- VNDK विक्रेता वेरिएंट द्वारा निर्यात किए गए प्रतीक (उदाहरण के लिए
/apex/com.android.vndk.v${VER}/lib[64]/libexample.so
) ABI डंप में परिभाषित प्रतीकों के समान (सुपरसेट नहीं) होने चाहिए। - VNDK एक्सटेंशन द्वारा निर्यात किए गए प्रतीक (जैसे
/vendor/lib[64]/vndk/libexample.so
) ABI डंप में परिभाषित प्रतीकों के सुपरसेट होने चाहिए।
यदि VNDK विक्रेता वेरिएंट या VNDK एक्सटेंशन उपरोक्त आवश्यकताओं का पालन करने में विफल रहते हैं, तो VNDK ABI चेकर बिल्ड त्रुटियाँ उत्पन्न करता है और बिल्ड को रोक देता है।
विक्रेता वेरिएंट से स्रोत फ़ाइलों या साझा लाइब्रेरी को बाहर करना
विक्रेता संस्करण से स्रोत फ़ाइलों को बाहर करने के लिए, उन्हें exclude_srcs
संपत्ति में जोड़ें। इसी प्रकार, यह सुनिश्चित करने के लिए कि साझा लाइब्रेरीज़ विक्रेता संस्करण से जुड़ी नहीं हैं, उन लाइब्रेरीज़ को exclude_shared_libs
प्रॉपर्टी में जोड़ें। उदाहरण के लिए:
cc_library { name: "libexample_cond_exclude", srcs: ["fwk.c", "both.c"], shared_libs: ["libfwk_only", "libboth"], vendor_available: true, target: { vendor: { exclude_srcs: ["fwk.c"], exclude_shared_libs: ["libfwk_only"], }, }, }
इस उदाहरण में, libexample_cond_exclude
के मुख्य संस्करण में fwk.c
और both.c
का कोड शामिल है और यह साझा लाइब्रेरी libfwk_only
और libboth
पर निर्भर करता है। libexample_cond_exclude
के विक्रेता संस्करण में केवल both.c
का कोड शामिल है क्योंकि fwk.c
exclude_srcs
संपत्ति द्वारा बाहर रखा गया है। इसी तरह, यह केवल साझा लाइब्रेरी libboth
पर निर्भर करता है क्योंकि libfwk_only
exclude_shared_libs
प्रॉपर्टी द्वारा बाहर रखा गया है।
VNDK एक्सटेंशन से हेडर निर्यात करें
VNDK एक्सटेंशन VNDK साझा लाइब्रेरी में नई कक्षाएं या नए फ़ंक्शन जोड़ सकता है। उन घोषणाओं को स्वतंत्र हेडर में रखने और मौजूदा हेडर को बदलने से बचने का सुझाव दिया गया है।
उदाहरण के लिए, VNDK एक्सटेंशन libexample_ext
के लिए एक नई हेडर फ़ाइल include-ext/example/ext/feature_name.h
बनाई गई है:
- Android.बीपी
- include-ext/example/ext/feature_name.h
- include/example/example.h
- src/example.c
- src/ext/feature_name.c
निम्नलिखित Android.bp
में, libexample
निर्यात में केवल include
, जबकि libexample_ext
निर्यात में include
और include-ext
दोनों शामिल हैं। यह सुनिश्चित करता है कि libexample
के उपयोगकर्ताओं द्वारा feature_name.h
गलत तरीके से शामिल नहीं किया जाएगा:
cc_library { name: "libexample", srcs: ["src/example.c"], export_include_dirs: ["include"], vendor_available: true, vndk: { enabled: true, }, } cc_library { name: "libexample_ext", srcs: [ "src/example.c", "src/ext/feature_name.c", ], export_include_dirs: [ "include", "include-ext", ], vendor: true, vndk: { enabled: true, extends: "libexample", }, }
यदि एक्सटेंशन को स्वतंत्र हेडर फ़ाइलों में अलग करना संभव नहीं है, तो #ifdef
गार्ड जोड़ने का एक विकल्प है। हालाँकि, सुनिश्चित करें कि सभी VNDK एक्सटेंशन उपयोगकर्ता परिभाषित झंडे जोड़ें। आप cflags
में परिभाषित झंडे जोड़ने और साझा पुस्तकालयों को shared_libs
के साथ लिंक करने के लिए cc_defaults
परिभाषित कर सकते हैं।
उदाहरण के लिए, VNDK एक्सटेंशन libexample2_ext
में एक नया सदस्य फ़ंक्शन Example2::get_b()
जोड़ने के लिए, आपको मौजूदा हेडर फ़ाइल को संशोधित करना होगा और एक #ifdef
गार्ड जोड़ना होगा:
#ifndef LIBEXAMPLE2_EXAMPLE_H_ #define LIBEXAMPLE2_EXAMPLE_H_ class Example2 { public: Example2(); void get_a(); #ifdef LIBEXAMPLE2_ENABLE_VNDK_EXT void get_b(); #endif private: void *impl_; }; #endif // LIBEXAMPLE2_EXAMPLE_H_
libexample2_ext
के उपयोगकर्ताओं के लिए libexample2_ext_defaults
नामक cc_defaults
परिभाषित किया गया है:
cc_library { name: "libexample2", srcs: ["src/example2.cpp"], export_include_dirs: ["include"], vendor_available: true, vndk: { enabled: true, }, } cc_library { name: "libexample2_ext", srcs: ["src/example2.cpp"], export_include_dirs: ["include"], vendor: true, vndk: { enabled: true, extends: "libexample2", }, cflags: [ "-DLIBEXAMPLE2_ENABLE_VNDK_EXT=1", ], } cc_defaults { name: "libexample2_ext_defaults", shared_libs: [ "libexample2_ext", ], cflags: [ "-DLIBEXAMPLE2_ENABLE_VNDK_EXT=1", ], }
libexample2_ext
के उपयोगकर्ता अपनी defaults
संपत्ति में libexample2_ext_defaults
शामिल कर सकते हैं:
cc_binary { name: "example2_user_executable", defaults: ["libexample2_ext_defaults"], vendor: true, }
उत्पाद पैकेज
एंड्रॉइड बिल्ड सिस्टम में, वेरिएबल PRODUCT_PACKAGES
निष्पादन योग्य, साझा लाइब्रेरी या पैकेज निर्दिष्ट करता है जिन्हें डिवाइस में इंस्टॉल किया जाना चाहिए। निर्दिष्ट मॉड्यूल की सकर्मक निर्भरताएँ डिवाइस में भी अंतर्निहित रूप से स्थापित होती हैं।
यदि BOARD_VNDK_VERSION
सक्षम है, तो vendor_available
या vndk.enabled
वाले मॉड्यूल को विशेष उपचार मिलता है। यदि कोई फ्रेमवर्क मॉड्यूल vendor_available
या vndk.enabled
वाले मॉड्यूल पर निर्भर करता है, तो कोर वेरिएंट को ट्रांजिटिव इंस्टॉलेशन सेट में शामिल किया जाता है। यदि कोई विक्रेता मॉड्यूल vendor_available
वाले मॉड्यूल पर निर्भर करता है, तो विक्रेता संस्करण को ट्रांजिटिव इंस्टॉलेशन सेट में शामिल किया जाता है। हालाँकि, vndk.enabled
वाले मॉड्यूल के विक्रेता वेरिएंट स्थापित किए जाते हैं, भले ही वे विक्रेता मॉड्यूल द्वारा उपयोग किए जाते हैं या नहीं।
जब निर्भरताएं बिल्ड सिस्टम के लिए अदृश्य होती हैं (उदाहरण के लिए साझा लाइब्रेरी जिन्हें रनटाइम में dlopen()
के साथ खोला जा सकता है), तो आपको उन मॉड्यूल को स्पष्ट रूप से स्थापित करने के लिए PRODUCT_PACKAGES
में मॉड्यूल नाम निर्दिष्ट करना चाहिए।
यदि किसी मॉड्यूल में vendor_available
या vndk.enabled
है, तो मॉड्यूल का नाम उसके मूल संस्करण के लिए है। PRODUCT_PACKAGES
में विक्रेता संस्करण को स्पष्ट रूप से निर्दिष्ट करने के लिए, मॉड्यूल नाम में एक .vendor
प्रत्यय जोड़ें। उदाहरण के लिए:
cc_library { name: "libexample", srcs: ["example.c"], vendor_available: true, }
इस उदाहरण में, libexample
अर्थ /system/lib[64]/libexample.so
है और libexample.vendor
अर्थ /vendor/lib[64]/libexample.so
है। /vendor/lib[64]/libexample.so
स्थापित करने के लिए, PRODUCT_PACKAGES
में libexample.vendor
जोड़ें:
PRODUCT_PACKAGES += libexample.vendor