VNDK बिल्ड सिस्टम सपोर्ट

एंड्रॉइड 8.1 और उच्चतर में, बिल्ड सिस्टम में अंतर्निहित VNDK समर्थन है। जब वीएनडीके समर्थन सक्षम होता है, तो बिल्ड सिस्टम मॉड्यूल के बीच निर्भरता की जांच करता है, विक्रेता मॉड्यूल के लिए एक विक्रेता-विशिष्ट संस्करण बनाता है, और स्वचालित रूप से उन मॉड्यूल को निर्दिष्ट निर्देशिकाओं में स्थापित करता है।

VNDK बिल्ड समर्थन उदाहरण

इस उदाहरण में, Android.bp मॉड्यूल परिभाषा libexample नामक लाइब्रेरी को परिभाषित करती है। vendor_available संपत्ति फ्रेमवर्क मॉड्यूल को इंगित करती है और विक्रेता मॉड्यूल libexample पर निर्भर हो सकते हैं:

libexample विक्रेता_उपलब्ध: सत्य और vndk.enabled: सत्य

चित्र 1. वीएनडीके समर्थन सक्षम

फ्रेमवर्क निष्पादन योग्य /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} से उपलब्ध है।

वीएनडीके एपेक्स

चित्र 2. वीएनडीके शीर्ष

मॉड्यूल परिभाषा

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 पर स्थापित की गई हैं।

false

false

false

कोई विक्रेता वैरिएंट नहीं. यह मॉड्यूल केवल 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