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

संग्रह की मदद से व्यवस्थित रहें अपनी प्राथमिकताओं के आधार पर, कॉन्टेंट को सेव करें और कैटगरी में बांटें.

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

बंद होना

वेंडर एनडीके को Android 8.0 में, फ़्रेमवर्क और वेंडर कोड के बीच एपीआई उपलब्ध कराने के लिए लॉन्च किया गया था. VNDK का इस्तेमाल कई सालों से किया जा रहा है. हालांकि, इसमें कुछ समस्याएं हैं:

• स्टोरेज
• एक VNDK APEX, सभी VNDK लाइब्रेरी को पैकेज करता है. भले ही, उनका इस्तेमाल डिवाइस से किया जा रहा हो या नहीं.
• GSI में VNDK APEX के कई वर्शन होते हैं, ताकि वेंडर इमेज के कई वर्शन काम कर सकें.
• अपडेट करने की सुविधा
• प्लैटफ़ॉर्म के अपडेट से अलग, VNDK APEX को अपडेट करना मुश्किल है.
• वेंडर इमेज को अक्सर ओवर-द-एयर (ओटीए) अपडेट किया जाता है. इससे, सिस्टम इमेज में VNDK को पैकेज करने के फ़ायदे कम हो जाते हैं.

इन समस्याओं के आधार पर, हमने Android 15 से VNDK को बंद करने का फ़ैसला लिया है.

वीएनडीके के बंद होने के बारे में जानकारी

सभी VNDK लाइब्रेरी, VNDK APEX में पैकेज की जाती हैं और सिस्टम (-ext) इमेज में इंस्टॉल की जाती हैं. VNDK के बंद होने के बाद, वेंडर (या प्रॉडक्ट) इमेज में पुरानी VNDK लाइब्रेरी इंस्टॉल की जाती हैं. यह वैसे ही होता है जैसे वेंडर की उपलब्ध अन्य लाइब्रेरी इंस्टॉल की जाती हैं. VNDK के बंद होने के साथ-साथ, ये सुविधाएं भी हटा दी गई हैं:

• Android 15 के लिए VNDK APEX
• अगर वेंडर या प्रॉडक्ट के पार्टीशन, Android 15 के लिए बनाए गए हैं, तो टारगेट VNDK के वर्शन की जानकारी देने वाली सिस्टम प्रॉपर्टी हटा दी जाती हैं:
  • ro.vndk.version
  • ro.product.vndk.version
• वीएनडीके ऑप्टिमाइज़ेशन उपलब्ध नहीं होंगे, क्योंकि वीएनडीके मौजूद नहीं है:
  • TARGET_VNDK_USING_CORE_VARIANT for Android Go devices
  • use_vndk_as_stable वेंडर APEX के लिए
• वेंडर स्नैपशॉट, जो VNDK पर काफ़ी निर्भर करता है

बंद किए जाने से जुड़े अपवाद

VNDK के बंद होने के बाद भी, ये सुविधाएं काम करती रहेंगी:

• VNDK वर्शन 14 या इससे पहले के वर्शन वाले VNDK APEX, जो मौजूदा वेंडर इमेज के साथ काम करने के लिए ज़रूरी हैं.
• LL-NDK, VNDK का हिस्सा नहीं है.

वीएनडीके क्यों?

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

सिर्फ़ फ़्रेमवर्क के अपडेट में ये समस्याएं शामिल हैं:

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

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

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, वेंडर और एक ही प्रोसेस वाले एचएएल (एसपी-एचएएल) के लिए, फ़्रेमवर्क की शेयर की गई लाइब्रेरी को कैसे मैनेज करता है.

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

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

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

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

• LL-NDK लाइब्रेरी, फ़्रेमवर्क की शेयर की गई लाइब्रेरी हैं, जिनके बारे में यह जाना जाता है कि वे काम करती हैं. उनके डेवलपर, एपीआई/एबीआई को स्थिर रखने के लिए प्रतिबद्ध हैं.
  • 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 लाइब्रेरी (VNDK), फ़्रेमवर्क की शेयर की गई लाइब्रेरी होती हैं. इन्हें दो बार कॉपी किया जा सकता है. फ़्रेमवर्क मॉड्यूल और वेंडर मॉड्यूल, अपनी कॉपी से लिंक किए जा सकते हैं. फ़्रेमवर्क की शेयर की गई लाइब्रेरी, VNDK लाइब्रेरी के तौर पर सिर्फ़ तब शामिल की जा सकती है, जब वह इन शर्तों को पूरा करती हो:
  • यह फ़्रेमवर्क से आईपीसी नहीं भेजता/पाता.
  • यह ART वर्चुअल मशीन से जुड़ा नहीं है.
  • यह अस्थिर फ़ाइल फ़ॉर्मैट वाली फ़ाइलों/पार्टिशन को पढ़ता/लिखता नहीं है.
  • इसके पास ऐसा खास सॉफ़्टवेयर लाइसेंस नहीं है जिसके लिए कानूनी समीक्षाएं ज़रूरी हैं.
  • कोड के मालिक को वेंडर के इस्तेमाल से कोई आपत्ति नहीं है.
• सिर्फ़ फ़्रेमवर्क के लिए लाइब्रेरी (सिर्फ़ फ़्रेमवर्क के लिए), फ़्रेमवर्क के साथ शेयर की जाने वाली लाइब्रेरी होती हैं. ये लाइब्रेरी, ऊपर बताई गई कैटगरी में नहीं आती हैं. ये लाइब्रेरी:
  • इन्हें फ़्रेमवर्क के अंदर लागू करने की जानकारी माना जाता है.
  • वेंडर मॉड्यूल इसे ऐक्सेस नहीं कर सकते.
  • इनमें अस्थिर एबीआई/एपीआई होते हैं और एपीआई/एबीआई के साथ काम करने की कोई गारंटी नहीं होती.
  • कॉपी नहीं किए जाते.

एक ही प्रोसेस वाला एचएएल (एसपी-एचएएल)

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

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

यहां दी गई लाइब्रेरी, एसपी-एचएएल के तौर पर मंज़ूर हैं:

• 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 लाइब्रेरी, अपनी Android.bp फ़ाइलों में vndk: { support_system_process: true } के बारे में बताती हैं. अगर vndk: {private:true} के बारे में भी जानकारी दी गई है, तो इन लाइब्रेरी को VNDK-SP-Private कहा जाता है और ये SP-HAL के लिए नहीं दिखती हैं.

यहां सिर्फ़ फ़्रेमवर्क के लिए इस्तेमाल होने वाली लाइब्रेरी दी गई हैं, जिनमें आरएस से जुड़े अपवाद हैं (सिर्फ़-फ़्रेमवर्क-आरएस):

• libft2.so (Renderscript)
• libmediandk.so (Renderscript)

VNDK का वर्शन

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 वेंडर टेस्ट सुइट (VTS) के लिए ज़रूरी है कि ro.vndk.version प्रॉपर्टी में कोई वैल्यू मौजूद हो. नए लॉन्च किए गए डिवाइसों और अपग्रेड किए जा रहे डिवाइसों, दोनों के लिए ro.vndk.version की जानकारी देना ज़रूरी है. ज़रूरी शर्तें पूरी करने वाली VNDK लाइब्रेरी के डेटा सेट को लोड करने के लिए, कुछ VNDK टेस्ट केस (जैसे, VtsVndkFilesTest और VtsVndkDependencyTest) ro.vndk.version प्रॉपर्टी पर निर्भर करते हैं.