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

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

बंद होना

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

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

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

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

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

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

सेम-प्रोसेस एचएएल (एसपी-एचएएल)

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

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

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

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

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

वीएनडीके की शेयर की गई लाइब्रेरी के वर्शन:

• ro.vndk.version सिस्टम प्रॉपर्टी, /vendor/default.prop में अपने-आप जुड़ जाती है.
• VNDK और VNDK-SP की शेयर की गई लाइब्रेरी, 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).

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

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