लिंकर नेमस्पेस

डाइनैमिक लिंकर, Treble VNDK डिज़ाइन में दो चुनौतियों का सामना करता है:

  • एसपी-एचएएल की शेयर की गई लाइब्रेरी और उनकी डिपेंडेंसी, फ़्रेमवर्क प्रोसेस में लोड की जाती हैं. इनमें वीएनडीके-एसपी लाइब्रेरी भी शामिल हैं. सिंबल के टकराव को रोकने के लिए, कुछ तरीके होने चाहिए.
  • dlopen() और android_dlopen_ext() कुछ ऐसी रनटाइम डिपेंडेंसी जोड़ सकते हैं जो बिल्ड प्रोसेस में लगने वाले समय पर नहीं दिखती हैं. साथ ही, स्टैटिक विश्लेषण का इस्तेमाल करके इनका पता लगाना मुश्किल हो सकता है.

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

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

उदाहरण के लिए, /system/lib[64]/libcutils.so और /system/lib[64]/vndk-sp-${VER}/libcutils.so दो शेयर की गई लाइब्रेरी हैं. इन दोनों लाइब्रेरी के अलग-अलग सिंबल हो सकते हैं. इन्हें अलग-अलग लिंकर नेमस्पेस में लोड किया जाता है, ताकि फ़्रेमवर्क मॉड्यूल /system/lib[64]/libcutils.so पर और SP-HAL शेयर की गई लाइब्रेरी /system/lib[64]/vndk-sp-${VER}/libcutils.so पर निर्भर कर सकें.

वहीं दूसरी ओर, /system/lib[64]/libc.so एक ऐसी सार्वजनिक लाइब्रेरी का उदाहरण है जिसे लिंक करने वाले नेमस्पेस ने एक्सपोर्ट किया है और लिंक करने वाले कई नेमस्पेस में इंपोर्ट किया गया है. /system/lib[64]/libc.so की डिपेंडेंसी, जैसे कि libnetd_client.so, उस नेमस्पेस में लोड होती हैं जिसमें /system/lib[64]/libc.so मौजूद है. अन्य नेमस्पेस के पास उन डिपेंडेंसी का ऐक्सेस नहीं होगा. यह मैकेनिज़्म, लागू करने से जुड़ी जानकारी को शामिल करता है. साथ ही, सार्वजनिक इंटरफ़ेस उपलब्ध कराता है.

यह कैसे काम करता है

डाइनैमिक लिंकर, DT_NEEDED एंट्री में बताई गई शेयर की गई लाइब्रेरी या dlopen() या android_dlopen_ext() के आर्ग्युमेंट में बताई गई शेयर की गई लाइब्रेरी को लोड करने के लिए ज़िम्मेदार होता है. दोनों ही मामलों में, डाइनैमिक लिंकर उस लिंकर नेमस्पेस को ढूंढता है जहां कॉलर मौजूद है. इसके बाद, वह डिपेंडेंसी को उसी लिंकर नेमस्पेस में लोड करने की कोशिश करता है. अगर डाइनैमिक लिंकर, शेयर की गई लाइब्रेरी को तय किए गए लिंकर नेमस्पेस में लोड नहीं कर पाता है, तो वह एक्सपोर्ट की गई शेयर की गई लाइब्रेरी के लिए, लिंक किए गए लिंकर नेमस्पेस से अनुरोध करता है.

कॉन्फ़िगरेशन फ़ाइल का फ़ॉर्मैट

कॉन्फ़िगरेशन फ़ाइल का फ़ॉर्मैट, INI फ़ाइल फ़ॉर्मैट पर आधारित होता है. कॉन्फ़िगरेशन फ़ाइल आम तौर पर ऐसी दिखती है:

dir.system = /system/bin
dir.system = /system/xbin
dir.vendor = /vendor/bin

[system]
additional.namespaces = sphal,vndk

namespace.default.isolated = true
namespace.default.search.paths = /system/${LIB}
namespace.default.permitted.paths = /system/${LIB}/hw
namespace.default.asan.search.paths = /data/asan/system/${LIB}:/system/${LIB}
namespace.default.asan.permitted.paths = /data/asan/system/${LIB}/hw:/system/${LIB}/hw

namespace.sphal.isolated = true
namespace.sphal.visible = true
namespace.sphal.search.paths = /odm/${LIB}:/vendor/${LIB}
namespace.sphal.permitted.paths = /odm/${LIB}:/vendor/${LIB}
namespace.sphal.asan.search.paths  = /data/asan/odm/${LIB}:/odm/${LIB}
namespace.sphal.asan.search.paths += /data/asan/vendor/${LIB}:/vendor/${LIB}
namespace.sphal.asan.permitted.paths  = /data/asan/odm/${LIB}:/odm/${LIB}
namespace.sphal.asan.permitted.paths += /data/asan/vendor/${LIB}:/vendor/${LIB}
namespace.sphal.links = default,vndk
namespace.sphal.link.default.shared_libs = libc.so:libm.so
namespace.sphal.link.vndk.shared_libs = libbase.so:libcutils.so

namespace.vndk.isolated = true
namespace.vndk.search.paths = /system/${LIB}/vndk-sp-29
namespace.vndk.permitted.paths = /system/${LIB}/vndk-sp-29
namespace.vndk.links = default
namespace.vndk.link.default.shared_libs = libc.so:libm.so

[vendor]
namespace.default.isolated = false
namespace.default.search.paths = /vendor/${LIB}:/system/${LIB}

कॉन्फ़िगरेशन फ़ाइल में यह जानकारी शामिल होती है:

  • डाइनैमिक लिंकर के लिए, शुरुआत में कई डायरेक्ट्री-सेक्शन मैपिंग प्रॉपर्टी, ताकि वह असरदार सेक्शन चुन सके.
  • लिंकर नेमस्पेस कॉन्फ़िगरेशन के कई सेक्शन:
    • हर सेक्शन में कई नेमस्पेस (ग्राफ़ वर्टेक्स) और नेमस्पेस (ग्राफ़ आर्क) के बीच कई फ़ॉलबैक लिंक होते हैं.
    • हर नेमस्पेस के लिए, आइसोलेशन, सर्च पाथ, अनुमति वाले पाथ, और दिखने की सेटिंग अलग-अलग होती हैं.

यहां दी गई टेबल में, हर प्रॉपर्टी के बारे में पूरी जानकारी दी गई है.

डायरेक्ट्री-सेक्शन मैपिंग प्रॉपर्टी

प्रॉपर्टी ब्यौरा उदाहरण

dir.name

यह उस डायरेक्ट्री का पाथ होता है जिस पर [name] सेक्शन लागू होता है.

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

dir.system = /system/bin
dir.system = /system/xbin
dir.vendor = /vendor/bin

इससे पता चलता है कि [system] सेक्शन में दिया गया कॉन्फ़िगरेशन, /system/bin या /system/xbin से लोड किए गए एक्ज़ीक्यूटेबल पर लागू होता है.

[vendor] सेक्शन में दिया गया कॉन्फ़िगरेशन, /vendor/bin से लोड किए गए एक्ज़ीक्यूटेबल पर लागू होता है.

रिलेशन प्रॉपर्टी

प्रॉपर्टी ब्यौरा उदाहरण
additional.namespaces

इस सेक्शन के लिए, कॉमा लगाकर अलग किए गए अन्य नेमस्पेस की सूची. इसमें default नेमस्पेस के अलावा अन्य नेमस्पेस शामिल होते हैं.

additional.namespaces = sphal,vndk

इससे पता चलता है कि [system] कॉन्फ़िगरेशन में तीन नेमस्पेस (default, sphal, और vndk) मौजूद हैं.
namespace.name.links

फ़ॉलबैक नेमस्पेस की कॉमा लगाकर अलग की गई लिस्ट.

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

namespace.sphal.links = default,vndk

अगर कोई शेयर की गई लाइब्रेरी या एक्ज़ीक्यूटेबल, ऐसी शेयर की गई लाइब्रेरी का अनुरोध करता है जिसे sphal नेमस्पेस में लोड नहीं किया जा सकता, तो डाइनैमिक लिंकर, शेयर की गई लाइब्रेरी को default नेमस्पेस से लोड करने की कोशिश करता है.

इसके बाद, अगर शेयर की गई लाइब्रेरी को default नेमस्पेस से भी लोड नहीं किया जा सकता, तो डाइनैमिक लिंकर, शेयर की गई लाइब्रेरी को vndk नेमस्पेस से लोड करने की कोशिश करता है.

आखिर में, अगर सभी कोशिशें बेकार हो जाती हैं, तो डाइनैमिक लिंकर एक गड़बड़ी दिखाता है.
namespace.name.link.other.shared_libs

यह शेयर की गई लाइब्रेरी की ऐसी सूची होती है जिसमें हर लाइब्रेरी के नाम के बाद कोलन लगा होता है. इन लाइब्रेरी को other नेमस्पेस में खोजा जा सकता है. ऐसा तब किया जाता है, जब ये लाइब्रेरी name नेमस्पेस में नहीं मिलती हैं.

इस प्रॉपर्टी का इस्तेमाल namespace.name.link.other.allow_all_shared_libs के साथ नहीं किया जा सकता.

namespace.sphal.link.default.shared_libs = libc.so:libm.so

इससे पता चलता है कि फ़ॉलबैक लिंक, अनुरोध किए गए लाइब्रेरी के नाम के तौर पर सिर्फ़ libc.so या libm.so को स्वीकार करता है. अगर अनुरोध की गई लाइब्रेरी का नाम libc.so या libm.so नहीं है, तो डाइनैमिक लिंकर, sphal से default नेमस्पेस तक के फ़ॉलबैक लिंक को अनदेखा कर देता है.
namespace.name.link.other.allow_all_shared_libs

यह एक बूलियन वैल्यू है. इससे पता चलता है कि जब शेयर की गई सभी लाइब्रेरी, other नेमस्पेस में नहीं मिलती हैं, तब उन्हें other नेमस्पेस में खोजा जा सकता है या नहीं.name

इस प्रॉपर्टी का इस्तेमाल namespace.name.link.other.shared_libs के साथ नहीं किया जा सकता.

namespace.vndk.link.sphal.allow_all_shared_libs = true

इससे पता चलता है कि लाइब्रेरी के सभी नाम, vndk से sphal नेमस्पेस में फ़ॉलबैक लिंक के ज़रिए जा सकते हैं.

नेमस्पेस की प्रॉपर्टी

प्रॉपर्टी ब्यौरा उदाहरण
namespace.name.isolated

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

अगर isolated true है, तो सिर्फ़ उन शेयर की गई लाइब्रेरी को लोड किया जा सकता है जो search.paths डायरेक्ट्री (सबडायरेक्ट्री को छोड़कर) में मौजूद हैं या permitted.paths डायरेक्ट्री (सबडायरेक्ट्री के साथ) में मौजूद हैं.

अगर isolated की वैल्यू false (डिफ़ॉल्ट) है, तो डाइनैमिक लिंकर, शेयर की गई लाइब्रेरी के पाथ की जांच नहीं करता.

namespace.sphal.isolated = true

इससे पता चलता है कि search.paths में या permitted.paths के तहत मौजूद शेयर की गई लाइब्रेरी को ही sphal नेमस्पेस में लोड किया जा सकता है.
namespace.name.search.paths

कोलन से अलग की गई डायरेक्ट्री की सूची, जिसमें शेयर की गई लाइब्रेरी खोजी जाती हैं.

अगर dlopen() या DT_NEEDED एंट्री के लिए फ़ंक्शन कॉल में पूरा पाथ नहीं दिया गया है, तो search.paths में दी गई डायरेक्ट्री को अनुरोध की गई लाइब्रेरी के नाम से पहले जोड़ा जाता है. सूची की शुरुआत में बताई गई डायरेक्ट्री को ज़्यादा प्राथमिकता दी जाती है.

जब isolated true पर सेट होता है, तब permitted.paths प्रॉपर्टी की वैल्यू कुछ भी हो, search.paths डायरेक्ट्री (सबडायरेक्ट्री को छोड़कर) में मौजूद शेयर की गई लाइब्रेरी लोड की जा सकती हैं.

उदाहरण के लिए, अगर search.paths /system/${LIB} है और permitted.paths खाली है, तो /system/${LIB}/libc.so को लोड किया जा सकता है, लेकिन /system/${LIB}/vndk/libutils.so को लोड नहीं किया जा सकता.

namespace.default.search.paths = /system/${LIB}

इससे पता चलता है कि डाइनैमिक लिंकर, शेयर की गई लाइब्रेरी के लिए /system/${LIB} खोजता है.
namespace.name.asan.search.paths

यह कोलन से अलग की गई डायरेक्ट्री की एक सूची है. इसका इस्तेमाल, AddressSanitizer (ASan) चालू होने पर, शेयर की गई लाइब्रेरी को खोजने के लिए किया जाता है.

ASan के चालू होने पर, namespace.name.search.paths को अनदेखा कर दिया जाता है.

namespace.default.asan.search.paths = /data/asan/system/${LIB}:/system/${LIB}

इससे पता चलता है कि ASan चालू होने पर, डाइनैमिक लिंकर पहले /data/asan/system/${LIB} और फिर /system/${LIB} खोजता है.
namespace.name.permitted.paths

यह कोलन से अलग की गई डायरेक्ट्री (इसमें सबडायरेक्ट्री भी शामिल हैं) की सूची होती है. इसमें उन डायरेक्ट्री के बारे में बताया जाता है जहां डाइनैमिक लिंकर, शेयर की गई लाइब्रेरी को लोड कर सकता है. ऐसा तब होता है, जब isolated true हो और search.paths के अलावा कोई अन्य डायरेक्ट्री उपलब्ध हो.

permitted.paths की सबडायरेक्ट्री में मौजूद शेयर की गई लाइब्रेरी भी लोड की जा सकती हैं. उदाहरण के लिए, अगर permitted.paths /system/${LIB} है, तो /system/${LIB}/libc.so और /system/${LIB}/vndk/libutils.so, दोनों को लोड किया जा सकता है.

अगर isolated की वैल्यू false है, तो permitted.paths को अनदेखा कर दिया जाता है और एक चेतावनी जारी की जाती है.

namespace.default.permitted.paths = /system/${LIB}/hw

इससे पता चलता है कि /system/${LIB}/hw में मौजूद शेयर की गई लाइब्रेरी को आइसोलेट किए गए default नेमस्पेस में लोड किया जा सकता है.

उदाहरण के लिए, permitted.paths के बिना, libaudiohal.so, /system/${LIB}/hw/audio.a2dp.default.so को default नेमस्पेस में लोड नहीं कर सकता.
namespace.name.asan.permitted.paths

कोलन से अलग की गई डायरेक्ट्री की सूची. इसमें वे डायरेक्ट्री शामिल होती हैं जहां ASan चालू होने पर, डाइनैमिक लिंकर शेयर की गई लाइब्रेरी लोड कर सकता है.

ASan के चालू होने पर, namespace.name.permitted.paths को अनदेखा कर दिया जाता है.

namespace.default.asan.permitted.paths = /data/asan/system/${LIB}/hw:/system/${LIB}/hw

इससे पता चलता है कि ASan चालू होने पर, /data/asan/system/${LIB}/hw या /system/${LIB}/hw में मौजूद शेयर की गई लाइब्रेरी को अलग किए गए default नेमस्पेस में लोड किया जा सकता है.
namespace.name.visible

यह बूलियन वैल्यू बताती है कि क्या प्रोग्राम (libc के अलावा) android_get_exported_namespace() के साथ लिंकर नेमस्पेस हैंडल पा सकता है और android_dlopen_ext() को हैंडल पास करके, लिंकर नेमस्पेस में शेयर की गई लाइब्रेरी खोल सकता है.

अगर visible, true है, तो android_get_exported_namespace() हमेशा हैंडल दिखाता है. हालांकि, ऐसा सिर्फ़ तब होता है, जब नेमस्पेस मौजूद हो.

अगर visible की वैल्यू false (डिफ़ॉल्ट) है, तो नेमस्पेस मौजूद होने पर भी android_get_exported_namespace() हमेशा NULL दिखाता है. शेयर की गई लाइब्रेरी को इस नेमस्पेस में सिर्फ़ तब लोड किया जा सकता है, जब (1) उन्हें किसी ऐसे लिंकर नेमस्पेस से अनुरोध किया गया हो जिसमें इस नेमस्पेस का फ़ॉलबैक लिंक हो या (2) उन्हें इस नेमस्पेस में मौजूद अन्य शेयर की गई लाइब्रेरी या एक्ज़ीक्यूटेबल से अनुरोध किया गया हो.

namespace.sphal.visible = true

इससे पता चलता है कि android_get_exported_namespace("sphal"), मान्य लिंकर नेमस्पेस हैंडल दिखा सकता है.

लिंकर नेमस्पेस बनाना

Android 11 में, लिंकर कॉन्फ़िगरेशन को रनटाइम पर /linkerconfig में बनाया जाता है. इसके लिए, /linkerconfig में सादे टेक्स्ट वाली फ़ाइलों का इस्तेमाल नहीं किया जाता.${android-src}/system/core/rootdir/etc कॉन्फ़िगरेशन, बूट होने के समय जनरेट होता है. यह रनटाइम एनवायरमेंट पर आधारित होता है. इसमें ये आइटम शामिल होते हैं:

  • अगर डिवाइस पर वीएनडीके काम करता है
  • वेंडर पार्टीशन का टारगेट किया गया वीएनडीके वर्शन
  • प्रॉडक्ट पार्टिशन का वीएनडीके वर्शन
  • इंस्टॉल किए गए APEX मॉड्यूल

लिंकर कॉन्फ़िगरेशन, लिंकर नेमस्पेस के बीच की डिपेंडेंसी को हल करके बनाया जाता है. उदाहरण के लिए, अगर APEX मॉड्यूल में कोई अपडेट होता है, जिसमें डिपेंडेंसी अपडेट शामिल हैं, तो लिंकर कॉन्फ़िगरेशन जनरेट होता है. इसमें ये बदलाव दिखते हैं. लिंकर कॉन्फ़िगरेशन बनाने के बारे में ज़्यादा जानकारी के लिए, ${android-src}/system/linkerconfig पर जाएं.

लिंकर के नेमस्पेस को अलग रखना

कॉन्फ़िगरेशन तीन तरह के होते हैं. BoardConfig.mk में PRODUCT_TREBLE_LINKER_NAMESPACES और BOARD_VNDK_VERSION की वैल्यू के आधार पर, बूट होने के समय कॉन्फ़िगरेशन जनरेट होता है.

PRODUCT_TREBLE_
LINKER_NAMESPACES		 BOARD_VNDK_
VERSION		 चुना गया कॉन्फ़िगरेशन वीटीएस से जुड़ी ज़रूरी शर्तें
true current VNDK Android 9 या इसके बाद के वर्शन के साथ लॉन्च किए गए डिवाइसों के लिए ज़रूरी है
खाली VNDK Lite Android 8.x वर्शन के साथ लॉन्च किए गए डिवाइसों के लिए ज़रूरी है
false खाली Legacy Treble की सुविधा वाले डिवाइसों के अलावा अन्य डिवाइसों के लिए

वीएनडीके लाइट कॉन्फ़िगरेशन, एसपी-एचएएल और वीएनडीके-एसपी शेयर की गई लाइब्रेरी को अलग करता है. Android 8.0 में, जब PRODUCT_TREBLE_LINKER_NAMESPACES true हो, तब यह डाइनैमिक लिंकर के लिए कॉन्फ़िगरेशन फ़ाइल होनी चाहिए.

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

Android 8.1 या इसके बाद के वर्शन में, VNDK कॉन्फ़िगरेशन डिफ़ॉल्ट कॉन्फ़िगरेशन होता है. हमारा सुझाव है कि BOARD_VNDK_VERSION को current पर सेट करके, पूरी तरह से डाइनैमिक लिंकर आइसोलेशन चालू करें.

वीएनडीके कॉन्फ़िगरेशन

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

  • फ़्रेमवर्क प्रोसेस

    • default, vndk, sphal, और rs नेमस्पेस बनाए जाते हैं.
    • सभी नेमस्पेस अलग-अलग होते हैं.
    • सिस्टम की शेयर की गई लाइब्रेरी, default नेमस्पेस में लोड की जाती हैं.
    • SP-HAL को sphal नेमस्पेस में लोड किया जाता है.
    • VNDK-SP की शेयर की गई लाइब्रेरी, vndk नेमस्पेस में लोड की जाती हैं.

  • वेंडर की प्रोसेस

    • default, vndk, और system नेमस्पेस बनाए जाते हैं.
    • default नेमस्पेस अलग किया गया है.
    • वेंडर की शेयर की गई लाइब्रेरी, default नेमस्पेस में लोड की जाती हैं.
    • वीएनडीके और वीएनडीके-एसपी की शेयर की गई लाइब्रेरी, vndk नेमस्पेस में लोड की जाती हैं.
    • LL-NDK और इसकी डिपेंडेंसी को system नेमस्पेस में लोड किया जाता है.

लिंकर नेमस्पेस के बीच का संबंध यहां दिखाया गया है.

वीएनडीके कॉन्फ़िगरेशन में बताया गया लिंकर नेमस्पेस ग्राफ़

पहली इमेज. लिंकर नेमस्पेस आइसोलेशन (वीएनडीके कॉन्फ़िगरेशन).

ऊपर दी गई इमेज में, LL-NDK और VNDK-SP का मतलब यहां दी गई शेयर की गई लाइब्रेरी से है:

  • 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
    • android.hardware.graphics.common@1.0.so
    • android.hardware.graphics.mapper@2.0.so
    • android.hardware.renderscript@1.0.so
    • android.hidl.memory@1.0.so
    • libRSCpuRef.so
    • libRSDriver.so
    • libRS_internal.so
    • libbase.so
    • libbcinfo.so
    • libc++.so
    • libcutils.so
    • libhardware.so
    • libhidlbase.so
    • libhidlmemory.so
    • libhidltransport.so
    • libhwbinder.so
    • libion.so
    • libutils.so
    • libz.so

डिवाइस पर /linkerconfig/ld.config.txt में जाकर, इस बारे में ज़्यादा जानकारी देखी जा सकती है.

वीएनडीके लाइट कॉन्फ़िगरेशन

Android 8.0 से, डाइनैमिक लिंकर को SP-HAL और VNDK-SP शेयर की गई लाइब्रेरी को अलग करने के लिए कॉन्फ़िगर किया गया है, ताकि उनके सिंबल, फ़्रेमवर्क की शेयर की गई अन्य लाइब्रेरी से न टकराएं. लिंकर नेमस्पेस के बीच का संबंध यहां दिखाया गया है.

VNDK Lite कॉन्फ़िगरेशन में बताया गया लिंकर नेमस्पेस ग्राफ़
दूसरी इमेज. लिंकर नेमस्पेस आइसोलेशन (वीएनडीके लाइट कॉन्फ़िगरेशन)

एलएल-एनडीके और वीएनडीके-एसपी का मतलब शेयर की गई ये लाइब्रेरी हैं:

  • LL-NDK
    • libEGL.so
    • libGLESv1_CM.so
    • libGLESv2.so
    • libc.so
    • libdl.so
    • liblog.so
    • libm.so
    • libnativewindow.so
    • libstdc++.so (कॉन्फ़िगरेशन में नहीं है)
    • libsync.so
    • libvndksupport.so
    • libz.so (कॉन्फ़िगरेशन में VNDK-SP पर ले जाया गया)
  • VNDK-SP
    • android.hardware.graphics.common@1.0.so
    • android.hardware.graphics.mapper@2.0.so
    • android.hardware.renderscript@1.0.so
    • android.hidl.memory@1.0.so
    • libbase.so
    • libc++.so
    • libcutils.so
    • libhardware.so
    • libhidlbase.so
    • libhidlmemory.so
    • libhidltransport.so
    • libhwbinder.so
    • libion.so
    • libutils.so

यहां दी गई टेबल में, फ़्रेमवर्क प्रोसेस के लिए नेमस्पेस कॉन्फ़िगरेशन की सूची दी गई है. यह सूची, VNDK Lite कॉन्फ़िगरेशन के [system] सेक्शन से ली गई है.

नेमस्पेस प्रॉपर्टी मान
default search.paths /system/${LIB}
/odm/${LIB}
/vendor/${LIB}
/product/${LIB}
isolated false
sphal search.paths /odm/${LIB}
/vendor/${LIB}
permitted.paths /odm/${LIB}
/vendor/${LIB}
isolated true
visible true
links default,vndk,rs
link.default.shared_libs LL-NDK
link.vndk.shared_libs VNDK-SP
link.rs.shared_libs libRS_internal.so
vndk (VNDK-SP के लिए) search.paths /odm/${LIB}/vndk-sp
/vendor/${LIB}/vndk-sp
/system/${LIB}/vndk-sp-${VER}
permitted.paths /odm/${LIB}/hw
/odm/${LIB}/egl
/vendor/${LIB}/hw
/vendor/${LIB}/egl
/system/${LIB}/vndk-sp-${VER}/hw
isolated true
visible true
links default
link.default.shared_libs LL-NDK
rs (RenderScript के लिए) search.paths /odm/${LIB}/vndk-sp
/vendor/${LIB}/vndk-sp
/system/${LIB}/vndk-sp-${VER}
/odm/${LIB}
/vendor/${LIB}
permitted.paths /odm/${LIB}
/vendor/${LIB}
/data (कंपाइल किए गए आरएस कर्नल के लिए)
isolated true
visible true
links default,vndk
link.default.shared_libs LL-NDK
libmediandk.so
libft2.so
link.vndk.shared_libs VNDK-SP

नीचे दी गई टेबल में, वेंडर प्रोसेस के लिए नेमस्पेस कॉन्फ़िगरेशन दिखाया गया है. इसे VNDK Lite कॉन्फ़िगरेशन के [vendor] सेक्शन से लिया गया है.

नेमस्पेस प्रॉपर्टी मान
default search.paths /odm/${LIB}
/odm/${LIB}/vndk
/odm/${LIB}/vndk-sp
/vendor/${LIB}
/vendor/${LIB}/vndk
/vendor/${LIB}/vndk-sp
/system/${LIB}/vndk-${VER}
/system/${LIB}/vndk-sp-${VER}
/system/${LIB} (अब काम नहीं करता)
/product/${LIB} (अब काम नहीं करता)
isolated false

ज़्यादा जानकारी के लिए, डिवाइस पर /linkerconfig/ld.config.txt पर जाएं.

दस्तावेज़ का इतिहास

Android 11 में हुए बदलाव

  • Android 11 में, स्टैटिक ld.config.*.txt फ़ाइलों को कोडबेस से हटा दिया जाता है. इसके बजाय, LinkerConfig उन्हें रनटाइम में जनरेट करता है.

Android 9 में हुए बदलाव

  • Android 9 में, वेंडर प्रोसेस में vndk लिंकर नेमस्पेस जोड़ा गया है. साथ ही, वीएनडीके शेयर की गई लाइब्रेरी को डिफ़ॉल्ट लिंकर नेमस्पेस से अलग किया गया है.
  • PRODUCT_FULL_TREBLE को ज़्यादा सटीक PRODUCT_TREBLE_LINKER_NAMESPACES से बदलें.
  • Android 9 में, डाइनैमिक लिंकर कॉन्फ़िगरेशन की इन फ़ाइलों के नाम बदल दिए गए हैं.
    Android 8.x Android 9 ब्यौरा
    ld.config.txt.in ld.config.txt रनटाइम लिंकर नेमस्पेस आइसोलेशन की सुविधा वाले डिवाइसों के लिए
    ld.config.txt ld.config.vndk_lite.txt VNDK-SP लिंकर नेमस्पेस आइसोलेशन वाले डिवाइसों के लिए
    ld.config.legacy.txt ld.config.legacy.txt Android 7.x या इससे पहले के वर्शन पर काम करने वाले लेगसी डिवाइसों के लिए
  • android.hardware.graphics.allocator@2.0.so हटाएं.
  • product और odm पार्टिशन जोड़े गए हैं.