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

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

समर्थन नहीं होना या रुकना

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

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

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

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

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

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

सुविधा बंद होने के अपवाद

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

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

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

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

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

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

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

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

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

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

• 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 प्रॉपर्टी पर निर्भर करते हैं.