वेंडर नेटिव डेवलपमेंट किट (वीएनडीके) की खास जानकारी

वेंडर नेटिव डेवलपमेंट किट (वीएनडीके) लाइब्रेरी का एक सेट होता है, जिसे दूसरी लाइब्रेरी इस्तेमाल करती हैं या बाइनरी, वेंडर या प्रॉडक्ट विभाजन में, dlopen के लिए रनटाइम पर.

वीएनडीके का इस्तेमाल क्यों करना चाहिए?

एओएसपी सिर्फ़ फ़्रेमवर्क वाले अपडेट की अनुमति देता है, जिसमें सिस्टम पार्टीशन को नए वर्शन पर अपग्रेड किया जा सकता है फ़्रेमवर्क वर्शन में बदलाव किया जा सकता है. हालांकि, वेंडर के बंटवारे में कोई बदलाव नहीं होगा. अलग-अलग शहरों में होने के बावजूद बार, हर हिस्से में मौजूद बाइनरी एक-दूसरे के साथ काम करने लायक होनी चाहिए.

सिर्फ़ फ़्रेमवर्क के अपडेट में ये चुनौतियां शामिल हैं:

  • यह, फ़्रेमवर्क मॉड्यूल और वेंडर मॉड्यूल के बीच निर्भर करता है. Android 8.0 से पहले के वर्शन में, वेंडर और सिस्टम के पार्टीशन के मॉड्यूल लिंक हो सकते थे एक-दूसरे के साथ जुड़े रहें. हालांकि, वेंडर मॉड्यूल की डिपेंडेंसी ने बिना काम के लगाई फ़्रेमवर्क मॉड्यूल डेवलपमेंट से जुड़ी पाबंदियां भी हैं.
  • एओएसपी लाइब्रेरी के एक्सटेंशन. Android पर सिस्टम पार्टीशन बदलने पर, सभी Android डिवाइसों को सीटीएस पास करना ज़रूरी है पर सेट करें. हालांकि, जब वेंडर AOSP का दायरा बढ़ाते हैं, लाइब्रेरी की मदद से परफ़ॉर्मेंस को बेहतर बनाया जा सकता है या अपने HIDL के लिए अतिरिक्त फ़ंक्शन जोड़े जा सकते हैं इसे लागू करना, सिस्टम पार्टिशन को स्टैंडर्ड जीएसआई के साथ फ़्लैश करना वेंडर के HIDL को लागू करने में रुकावट आ सकती है. इन दिशा-निर्देशों के लिए ऐसी गड़बड़ियों से बचा जा सकता है. VNDK एक्सटेंशन.

इन चुनौतियों से निपटने के लिए, Android में ऐसी कई सुविधाएं शामिल हैं VNDK के तौर पर (इस सेक्शन में बताया गया है), HIDL, hwbinder, डिवाइस ट्री ओवरले, और नीति ओवरले है.

VNDK के लिए खास शर्तें

VNDK से जुड़े दस्तावेज़ों में, इन शब्दावली का इस्तेमाल किया जाता है:
  • मॉड्यूल का मतलब या तो शेयर की गई लाइब्रेरी या एक्ज़ीक्यूटेबल फ़ाइल से है. मॉड्यूल से बिल्ड-टाइम बेहतर होता है निर्भरता.
  • प्रोसेस ऑपरेटिंग सिस्टम के ऐसे टास्क हैं जो एक्ज़ीक्यूटेबल से आते हैं. प्रोसेस पूरी तरह से काम करती हैं निर्भरता.
  • फ़्रेमवर्क-क्वालिफ़ाइड शब्द, system विभाजन से जुड़े हैं:
    • फ़्रेमवर्क एक्ज़ीक्यूटेबल, /system/bin में एक्ज़ीक्यूटेबल का मतलब होता है या /system/xbin.
    • फ़्रेमवर्क शेयर की गई लाइब्रेरी का मतलब /system/lib[64].
    • फ़्रेमवर्क मॉड्यूल, शेयर की गई दोनों लाइब्रेरी के बारे में बताते हैं और फ़्रेमवर्क की एक्ज़ीक्यूटेबल.
    • फ़्रेमवर्क प्रोसेस, फ़्रेमवर्क से बनी प्रोसेस होती हैं एक्ज़ीक्यूटेबल, जैसे /system/bin/app_process.
  • वेंडर के लिए तय की गई शर्तें, vendor सेगमेंट से जुड़ी हैं:
    • वेंडर के एक्ज़ीक्यूटेबल का मतलब /vendor/bin में एक्ज़ीक्यूटेबल फ़ाइल से है
    • वेंडर की शेयर की गई लाइब्रेरी का मतलब, /vendor/lib[64].
    • वेंडर मॉड्यूल का मतलब, वेंडर के एक्ज़ीक्यूटेबल फ़ाइल और वेंडर की शेयर की गई लाइब्रेरी, दोनों से है.
    • वेंडर से जुड़ी प्रोसेस, वे प्रोसेस होती हैं जो वेंडर के ज़रिए तैयार की जाती हैं एक्ज़ीक्यूटेबल, जैसे कि /vendor/bin/android.hardware.camera.provider@2.4-service.

VNDK के कॉन्सेप्ट

एक आदर्श Android 8.0 और उसके बाद वाले वर्शन में, फ़्रेमवर्क प्रोसेस लोड नहीं होती हैं वेंडर के साथ शेयर की गई लाइब्रेरी, वेंडर की सभी प्रोसेस, सिर्फ़ वेंडर की शेयर की गई लाइब्रेरी को लोड करती हैं (और शेयर की गई लाइब्रेरी का एक हिस्सा है) और इनके बीच कम्यूनिकेशन फ़्रेमवर्क की प्रोसेस और वेंडर प्रोसेस, HIDL और हार्डवेयर से कंट्रोल होती हैं बाइंडर.

ऐसी दुनिया में यह संभावना शामिल होती है कि स्थायी, सार्वजनिक एपीआई शेयर की गई लाइब्रेरी, शायद वेंडर मॉड्यूल डेवलपर के लिए काफ़ी न हों (हालांकि, Android रिलीज़ के बीच एपीआई बदल सकते हैं), इसलिए यह ज़रूरी है कि शेयर की गई लाइब्रेरी का फ़्रेमवर्क, वेंडर प्रोसेस के लिए ऐक्सेस किया जा सकता है. इसके अलावा, जैसे कि परफ़ॉर्मेंस से जुड़ी ज़रूरतों की वजह से समस्याएं आ सकती हैं. कुछ मामलों में, ये शर्तें बहुत ज़रूरी होती हैं एचएएल को अलग तरह से माना जाना चाहिए.

नीचे दिए गए सेक्शन में बताया गया है कि VNDK, वेंडर और सेम-प्रोसेस एचएएल (SP-HAL) होते हैं.

वेंडर के लिए शेयर की गई लाइब्रेरी का फ़्रेमवर्क

इस सेक्शन में ऐसी शेयर की गई लाइब्रेरी को बांटने का तरीका बताया गया है जिन्हें और वेंडर प्रोसेस को ऐक्सेस कर सकता है. वेंडर की मदद करने के दो तरीके हैं कई Android रिलीज़ के मॉड्यूल:

  1. शेयर की गई लाइब्रेरी के फ़्रेमवर्क के एबीआई/एपीआई को स्थिर करें. नए फ़्रेमवर्क मॉड्यूल और पुराने वेंडर मॉड्यूल, एक ही शेयर की गई लाइब्रेरी का इस्तेमाल इन कामों के लिए कर सकते हैं मेमोरी फ़ुटप्रिंट और स्टोरेज के साइज़ को कम कर सकता है. एक अनोखी शेयर लाइब्रेरी से आप इन्हें भी जाने से बच सकते हैं डबल-लोडिंग से जुड़ी कई समस्याएं हैं. हालांकि, डेवलपमेंट की लागत को स्थिर बनाए रखने में एबीआई/एपीआई ज़्यादा हैं और इन्हें एक्सपोर्ट किए गए सभी एबीआई/एपीआई को स्थिर करना मुमकिन नहीं है शेयर की गई लाइब्रेरी पर मौजूद है.
  2. शेयर की गई पुरानी फ़्रेमवर्क कॉपी करें. मज़बूत टेक्नोलॉजी के साथ आता है साइड चैनलों पर लगी पाबंदी. इसे एक-दूसरे से बातचीत करने के सभी तरीकों के तौर पर बताया गया है फ़्रेमवर्क मॉड्यूल और वेंडर मॉड्यूल में उपलब्ध है. इसमें इनके अलावा, और भी चीज़ें शामिल हो सकती हैं बाइंडर, सॉकेट, पाइप, शेयर की गई मेमोरी, शेयर की गई फ़ाइल, और सिस्टम प्रॉपर्टी. यह लीजिए जब तक कि कम्यूनिकेशन प्रोटोकॉल स्थिर और स्थिर न हो (उदाहरण के लिए, hwbinder से HIDL). शेयर की गई लाइब्रेरी को दो बार लोड करने से, इस समस्या का सामना करना पड़ सकता है समस्या भी; उदाहरण के लिए, अगर नई लाइब्रेरी से बनाया गया कोई ऑब्जेक्ट पास किया जाता है फ़ंक्शन में कोई गड़बड़ी हो सकती है, क्योंकि इन लाइब्रेरी के ऑब्जेक्ट को अलग तरीके से समझ सकता है.

अलग-अलग तरीके इस्तेमाल किए जाते हैं. लाइब्रेरी. इस वजह से, शेयर की गई लाइब्रेरी को तीन कैटगरी में बांटा गया है उप-श्रेणियां:

  • एलएल-एनडीके लाइब्रेरी, फ़्रेमवर्क शेयर की गई लाइब्रेरी होती हैं जो स्थिर माने जाते हैं. उनके डेवलपर, इन सेवाओं का इस्तेमाल जारी रखने के लिए प्रतिबद्ध हैं एपीआई/एबीआई की स्थिरता में बदलाव करने की सुविधा.
    • LL-NDK में ये लाइब्रेरी शामिल हैं: libEGL.so, libGLESv1_CM.so, libGLESv2.so, libGLESv3.so, libandroid_net.so, libc.so, libdl.so, liblog.so, libm.so, libnativewindow.so, libneuralnetworks.so, libsync.so, libvndksupport.so और libvulkan.so,
  • ज़रूरी शर्तें पूरी करने वाली वीएनडीके लाइब्रेरी (वीएनडीके), फ़्रेमवर्क शेयर की गई होती हैं ऐसी लाइब्रेरी जिन्हें दो बार कॉपी करना सुरक्षित होता है. फ़्रेमवर्क मॉड्यूल और वेंडर मॉड्यूल को अपनी कॉपी के साथ लिंक किया जा सकता है. शेयर किया गया फ़्रेमवर्क लाइब्रेरी एक मान्य VNDK लाइब्रेरी बन सकती है, जब वह इन शर्तों को पूरा करती हो शर्तें:
    • यह फ़्रेमवर्क को आईपीसी न तो भेजता है और न ही लेता है.
    • यह एआरटी वर्चुअल मशीन से नहीं जुड़ी है.
    • यह अस्थिर फ़ाइल फ़ॉर्मैट वाली फ़ाइलों/पार्टिशन को पढ़/लिखता नहीं है.
    • इसके पास कोई खास सॉफ़्टवेयर लाइसेंस नहीं है, जिसके लिए कानूनी समीक्षा की ज़रूरत होती है.
    • वेंडर के इस्तेमाल पर, कोड के मालिक को कोई आपत्ति नहीं है.
  • सिर्फ़ फ़्रेमवर्क वाली लाइब्रेरी (सिर्फ़ एफ़डब्ल्यूके के लिए), फ्रे़मवर्क शेयर किए जाते हैं ऐसी लाइब्रेरी जो ऊपर बताई गई कैटगरी से जुड़ी नहीं हैं. ये लाइब्रेरी:
    • उन्हें फ़्रेमवर्क की इंटरनल जानकारी माना जाता है.
    • वेंडर मॉड्यूल से इसे ऐक्सेस नहीं किया जा सकता.
    • उनके एबीआई/एपीआई ठीक से काम नहीं करते हैं और इनके साथ काम करने की कोई गारंटी नहीं है.
    • कॉपी नहीं किए गए हैं.

समान-प्रोसेस HAL (SP-HAL)

सेम-प्रोसेस एचएएल (SP-HAL), पहले से तय किए गए एचएएल का सेट होता है वेंडर शेयर लाइब्रेरी के तौर पर लागू किया जाता है और फ़्रेमवर्क में लोड किया जाता है प्रक्रियाएं. SP-HAL को लिंकर नेमस्पेस से अलग किया जाता है (कंट्रोल करता है कि लाइब्रेरी और सिंबल जिन्हें शेयर की गई लाइब्रेरी में देखा जा सकता है). SP-HAL को यह अवश्य करना चाहिए सिर्फ़ LL-NDK और VNDK-SP पर निर्भर करते हैं.

VNDK-SP, ज़रूरी शर्तें पूरी करने वाली VNDK लाइब्रेरी का पहले से तय किया गया सबसेट है. वीएनडीके-एसपी लाइब्रेरी उनकी ध्यान से समीक्षा की जाती है, ताकि यह पक्का किया जा सके कि VNDK-SP लाइब्रेरी, फ़्रेमवर्क में डबल-लोड हो रही हैं प्रक्रियाओं से कोई समस्या नहीं होती. SP-HAL और VNDK-SP, दोनों को Google.

इन लाइब्रेरी को SP-HAL की मंज़ूरी मिली है:

  • libGLESv1_CM_${driver}.so
  • libGLESv2_${driver}.so
  • libGLESv3_${driver}.so
  • libEGL_${driver}.so
  • vulkan.${driver}.so
  • android.hardware.renderscript@1.0-impl.so
  • android.hardware.graphics.mapper@2.0-impl.so

VNDK-SP लाइब्रेरी, vndk: { support_system_process: true } के बारे में बताती हैं अपनी Android.bp फ़ाइलों में लगा सकते हैं. अगर vndk: {private:true} भी हो बताया गया है, तो इन लाइब्रेरी को VNDK-SP-Private कहा जाता है और ये SP-HALS को नहीं दिखता.

यहां आरएसएस अपवादों के साथ सिर्फ़ फ़्रेमवर्क वाली लाइब्रेरी शामिल की गई हैं (सिर्फ़ एफ़डब्ल्यूके):

  • libft2.so (रेंडरस्क्रिप्ट)
  • libmediandk.so (रेंडरस्क्रिप्ट)

वीएनडीके वर्शन

VNDK की शेयर की गई लाइब्रेरी का वर्शन होता है:

  • ro.vndk.version सिस्टम प्रॉपर्टी अपने-आप इसमें जुड़ जाती है /vendor/default.prop.
  • VNDK और VNDK-SP की शेयर की गई लाइब्रेरी, VNDK एपेक्स के तौर पर इंस्टॉल होती हैं com.android.vndk.v${ro.vndk.version} और इस पर माउंट किया गया /apex/com.android.vndk.v${ro.vndk.version}.

ro.vndk.version की वैल्यू, एल्गोरिदम तय करता है नीचे दिया गया है:

  • अगर BOARD_VNDK_VERSION, इसके बराबर नहीं है current, BOARD_VNDK_VERSION का इस्तेमाल करें.
  • अगर BOARD_VNDK_VERSION इसके बराबर है current:
    • अगर PLATFORM_VERSION_CODENAME REL है, तो इसका इस्तेमाल करें PLATFORM_SDK_VERSION (उदाहरण के लिए, 28).
    • अगर ऐसा नहीं है, तो PLATFORM_VERSION_CODENAME का इस्तेमाल करें (उदाहरण के लिए, P).

वेंडर टेस्ट सुइट (वीटीएस)

Android वेंडर टेस्ट सुइट (वीटीएस) के लिए ro.vndk.version प्रॉपर्टी खाली नहीं है. हाल ही में लॉन्च किए गए दोनों डिवाइस और अपग्रेड किए जाने वाले डिवाइसों में ro.vndk.version तय होनी चाहिए. कुछ वीएनडीके टेस्ट केस (उदाहरण के लिए, VtsVndkFilesTest और VtsVndkDependencyTest) ro.vndk.version पर निर्भर रहती हैं प्रॉपर्टी का इस्तेमाल किया जा सकता है, ताकि मेल खाने वाली VNDK लाइब्रेरी के डेटा सेट को लोड किया जा सके.