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

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

बंद की गई सेवाएं/सुविधाएं

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

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

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

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

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

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

बंद होने से जुड़े अपवाद

वीएनडीके के बंद होने से, इन सुविधाओं में कोई बदलाव नहीं होगा:

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

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

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

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

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

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

वीएनडीके से जुड़ी शर्तें

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.

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

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

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

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

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

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

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

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

वीएनडीके वर्शनिंग

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

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

Vendor Test Suite (VTS)

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