VNDK डेफ़िनिशन टूल

VNDK डेफ़िनिशन टूल की मदद से, वेंडर अपने सोर्स ट्री को Android 8.0 वाले एनवायरमेंट पर माइग्रेट कर सकते हैं. यह टूल, सिस्टम और वेंडर इमेज में मौजूद बाइनरी फ़ाइलों को स्कैन करता है. इसके बाद, डिपेंडेंसी को हल करता है. मॉड्यूल डिपेंडेंसी ग्राफ़ के आधार पर, यह टूल VNDK कॉन्सेप्ट के उल्लंघनों का पता लगा सकता है. साथ ही, मॉड्यूल को एक से दूसरे पार्टीशन में ले जाने के लिए अहम जानकारी/सुझाव दे सकता है. अगर कोई सामान्य सिस्टम इमेज (जीएसआई) तय की गई है, तो VNDK डेफ़िनिशन टूल आपकी सिस्टम इमेज की तुलना जीएसआई से कर सकता है और एक्सटेंड की गई लाइब्रेरी तय कर सकता है.

इस सेक्शन में, VNDK डेफ़िनिशन टूल के लिए अक्सर इस्तेमाल होने वाले तीन निर्देशों के बारे में बताया गया है:

  • vndk. Android 8.0 और उसके बाद के वर्शन में, बिल्ड सिस्टम से जुड़ी समस्या को हल करने के लिए, VNDK_SP_LIBRARIES, VNDK_SP_EXT_LIBRARIES, और EXTRA_VENDOR_LIBRARIES का हिसाब लगाएं.
  • check-dep. नीति का उल्लंघन करने वाले मॉड्यूल की डिपेंडेंसी की जांच करें. ये डिपेंडेंसी, वेंडर मॉड्यूल से लेकर ज़रूरी शर्तें पूरी न करने वाली फ़्रेमवर्क शेयर की गई लाइब्रेरी तक की हो सकती हैं.
  • deps. शेयर की गई लाइब्रेरी और एक्सीक्यूटेबल के बीच की डिपेंडेंसी प्रिंट करें.

बेहतर निर्देश के इस्तेमाल के बारे में ज़्यादा जानकारी के लिए, VNDK डेफ़िनिशन टूल के डेटाबेस में मौजूद README.md फ़ाइल देखें.

vndk

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

विकल्प ब्यौरा
--system सिस्टम के partition में मौजूद फ़ाइलों वाली डायरेक्ट्री पर जाएं.
--vendor वेंडर के partition में मौजूद फ़ाइलों वाली डायरेक्ट्री पर ले जाएं.
--aosp-system ऐसी डायरेक्ट्री पर कर्सर ले जाएं जिसमें सामान्य सिस्टम इमेज (जीएसआई) में मौजूद फ़ाइलें हों.
--load-extra-deps ऐसी फ़ाइल पर ले जाएं जिसमें dlopen() जैसी लागू होने वाली डिपेंडेंसी के बारे में बताया गया हो.

उदाहरण के लिए, VNDK लाइब्रेरी सेट का हिसाब लगाने के लिए, यह vndk सब-कमांड चलाएं:

./vndk_definition_tool.py vndk \
    --system ${ANDROID_PRODUCT_OUT}/system \
    --vendor ${ANDROID_PRODUCT_OUT}/vendor \
    --aosp-system ${ANDROID_PRODUCT_OUT}/../generic_arm64_ab/system\
    --load-extra-deps dlopen.dep

आसान फ़ाइल फ़ॉर्मैट की मदद से, अतिरिक्त डिपेंडेंसी तय करें. हर लाइन किसी संबंध को दिखाती है. इसमें कोलन से पहले की फ़ाइल, कोलन के बाद की फ़ाइल पर निर्भर करती है. उदाहरण के लिए:

/system/lib/libart.so: /system/lib/libart-compiler.so

इस लाइन से VNDK डेफ़िनिशन टूल को पता चलता है कि libart.so, libart-compiler.so पर निर्भर है.

इंस्टॉलेशन डेस्टिनेशन

VNDK डेफ़िनिशन टूल, लाइब्रेरी और उनसे जुड़ी इंस्टॉल डायरेक्ट्री की सूची बनाता है. ये सूचियां इन कैटगरी के लिए बनाई जाती हैं:

कैटगरी डायरेक्ट्री
vndk_sp /system/lib[64]/vndk-sp-${VER} पर इंस्टॉल करना ज़रूरी है
vndk_sp_ext /vendor/lib[64]/vndk-sp पर इंस्टॉल करना ज़रूरी है
extra_vendor_libs /vendor/lib[64] पर इंस्टॉल करना ज़रूरी है

बिल्ड सिस्टम टेंप्लेट

VNDK डेफ़िनिशन टूल से आउटपुट इकट्ठा करने के बाद, वेंडर एक Android.mk बना सकता है और VNDK_SP_LIBRARIES, VNDK_SP_EXT_LIBRARIES, और EXTRA_VENDOR_LIBRARIES को भर सकता है. इससे, लाइब्रेरी को तय किए गए इंस्टॉलेशन डेस्टिनेशन में कॉपी करने की प्रोसेस को ऑटोमेट किया जा सकता है.

ifneq ($(filter $(YOUR_DEVICE_NAME),$(TARGET_DEVICE)),)
VNDK_SP_LIBRARIES := ##_VNDK_SP_##
VNDK_SP_EXT_LIBRARIES := ##_VNDK_SP_EXT_##
EXTRA_VENDOR_LIBRARIES := ##_EXTRA_VENDOR_LIBS_##

#-------------------------------------------------------------------------------
# VNDK Modules
#-------------------------------------------------------------------------------
LOCAL_PATH := $(call my-dir)

define define-vndk-lib
include $$(CLEAR_VARS)
LOCAL_MODULE := $1.$2
LOCAL_MODULE_CLASS := SHARED_LIBRARIES
LOCAL_PREBUILT_MODULE_FILE := $$(TARGET_OUT_INTERMEDIATE_LIBRARIES)/$1.so
LOCAL_STRIP_MODULE := false
LOCAL_MULTILIB := first
LOCAL_MODULE_TAGS := optional
LOCAL_INSTALLED_MODULE_STEM := $1.so
LOCAL_MODULE_SUFFIX := .so
LOCAL_MODULE_RELATIVE_PATH := $3
LOCAL_VENDOR_MODULE := $4
include $$(BUILD_PREBUILT)

ifneq ($$(TARGET_2ND_ARCH),)
ifneq ($$(TARGET_TRANSLATE_2ND_ARCH),true)
include $$(CLEAR_VARS)
LOCAL_MODULE := $1.$2
LOCAL_MODULE_CLASS := SHARED_LIBRARIES
LOCAL_PREBUILT_MODULE_FILE := $$($$(TARGET_2ND_ARCH_VAR_PREFIX)TARGET_OUT_INTERMEDIATE_LIBRARIES)/$1.so
LOCAL_STRIP_MODULE := false
LOCAL_MULTILIB := 32
LOCAL_MODULE_TAGS := optional
LOCAL_INSTALLED_MODULE_STEM := $1.so
LOCAL_MODULE_SUFFIX := .so
LOCAL_MODULE_RELATIVE_PATH := $3
LOCAL_VENDOR_MODULE := $4
include $$(BUILD_PREBUILT)
endif  # TARGET_TRANSLATE_2ND_ARCH is not true
endif  # TARGET_2ND_ARCH is not empty
endef

$(foreach lib,$(VNDK_SP_LIBRARIES),\
    $(eval $(call define-vndk-lib,$(lib),vndk-sp-gen,vndk-sp,)))
$(foreach lib,$(VNDK_SP_EXT_LIBRARIES),\
    $(eval $(call define-vndk-lib,$(lib),vndk-sp-ext-gen,vndk-sp,true)))
$(foreach lib,$(EXTRA_VENDOR_LIBRARIES),\
    $(eval $(call define-vndk-lib,$(lib),vndk-ext-gen,,true)))


#-------------------------------------------------------------------------------
# Phony Package
#-------------------------------------------------------------------------------

include $(CLEAR_VARS)
LOCAL_MODULE := $(YOUR_DEVICE_NAME)-vndk
LOCAL_MODULE_TAGS := optional
LOCAL_REQUIRED_MODULES := \
    $(addsuffix .vndk-sp-gen,$(VNDK_SP_LIBRARIES)) \
    $(addsuffix .vndk-sp-ext-gen,$(VNDK_SP_EXT_LIBRARIES)) \
    $(addsuffix .vndk-ext-gen,$(EXTRA_VENDOR_LIBRARIES))
include $(BUILD_PHONY_PACKAGE)

endif  # ifneq ($(filter $(YOUR_DEVICE_NAME),$(TARGET_DEVICE)),)

check-dep

check-dep सब-कमांड, वेंडर मॉड्यूल को स्कैन करता है और उनकी डिपेंडेंसी की जांच करता है. अगर यह उल्लंघनों का पता लगाता है, तो यह उन लाइब्रेरी और सिंबल के इस्तेमाल को प्रिंट करता है जिनसे उल्लंघन हुआ है:

./vndk_definition_tool.py check-dep \
    --system ${ANDROID_PRODUCT_OUT}/system \
    --vendor ${ANDROID_PRODUCT_OUT}/vendor \
    --tag-file eligible-list.csv \
    --module-info ${ANDROID_PRODUCT_OUT}/module-info.json \
    1> check_dep.txt \
    2> check_dep_err.txt

उदाहरण के लिए, यहां दिए गए सैंपल आउटपुट में, libRS_internal.so से libmediandk.so तक की गलत डिपेंडेंसी दिख रही है:

/system/lib/libRS_internal.so
        MODULE_PATH: frameworks/rs
        /system/lib/libmediandk.so
                AImageReader_acquireNextImage
                AImageReader_delete
                AImageReader_getWindow
                AImageReader_new
                AImageReader_setImageListener

check-dep सब-कमांड के विकल्पों में ये शामिल हैं:

विकल्प ब्यौरा
--tag-file यह ज़रूरी है कि यह लाइब्रेरी टैग की ऐसी फ़ाइल का रेफ़रंस दे जो ज़रूरी शर्तें पूरी करती हो. इस फ़ाइल के बारे में यहां बताया गया है. यह Google की दी गई स्प्रेडशीट होती है, जिसमें फ़्रेमवर्क की शेयर की गई लाइब्रेरी की कैटगरी के बारे में बताया जाता है.
--module-info Android बिल्ड सिस्टम से जनरेट किए गए module-info.json पर ले जाता है. इससे VNDK डेफ़िनिशन टूल को सोर्स कोड के साथ बाइनरी मॉड्यूल जोड़ने में मदद मिलती है.

ज़रूरी शर्तें पूरी करने वाली लाइब्रेरी टैग फ़ाइल

Google, ज़रूरी शर्तें पूरी करने वाली VNDK स्प्रेडशीट (उदाहरण के लिए, eligible-list.csv) उपलब्ध कराता है.इसमें, फ़्रेमवर्क की शेयर की गई लाइब्रेरी को टैग किया जाता है. इन लाइब्रेरी का इस्तेमाल, वेंडर मॉड्यूल कर सकते हैं:

टैग करें ब्यौरा
LL-NDK शेयर की गई लाइब्रेरी, जिनमें स्टेबल एबीआई/एपीआई हों और जिनका इस्तेमाल, फ़्रेमवर्क और वेंडर मॉड्यूल, दोनों के लिए किया जा सकता हो.
LL-NDK-Private LL-NDK लाइब्रेरी की निजी डिपेंडेंसी. वेंडर मॉड्यूल को इन लाइब्रेरी को सीधे तौर पर ऐक्सेस नहीं करना चाहिए.
VNDK-SP SP-HAL फ़्रेमवर्क की शेयर की गई लाइब्रेरी की डिपेंडेंसी.
VNDK-SP-Private VNDK-SP की ऐसी डिपेंडेंसी जो सीधे तौर पर सभी वेंडर के सभी मॉड्यूल के लिए ऐक्सेस नहीं की जा सकतीं.
VNDK वेंडर मॉड्यूल के लिए उपलब्ध फ़्रेमवर्क की शेयर की गई लाइब्रेरी (SP-HAL और SP-HAL-Dep को छोड़कर).
VNDK-Private VNDK की ऐसी डिपेंडेंसी जो सभी वेंडर के सभी मॉड्यूल के लिए सीधे तौर पर ऐक्सेस नहीं की जा सकतीं.
FWK-ONLY सिर्फ़ फ़्रेमवर्क के लिए शेयर की गई लाइब्रेरी, जिन्हें वेंडर के मॉड्यूल को ऐक्सेस नहीं करना चाहिए.
FWK-ONLY-RS सिर्फ़ फ़्रेमवर्क के लिए शेयर की गई लाइब्रेरी, जिन्हें वेंडर के मॉड्यूल ऐक्सेस नहीं कर सकते (आरएस के इस्तेमाल को छोड़कर).

इस टेबल में, वेंडर की शेयर की गई लाइब्रेरी के लिए इस्तेमाल किए जाने वाले टैग के बारे में बताया गया है:

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

टैग के बीच के संबंध:

टैग के बीच के संबंध.

पहली इमेज. टैग के बीच के संबंध.

deps

लाइब्रेरी डिपेंडेंसी को डीबग करने के लिए, deps सब-कमांड, मॉड्यूल डिपेंडेंसी को प्रिंट करता है:

./vndk_definition_tool.py deps \
    --system ${ANDROID_PRODUCT_OUT}/system \
    --vendor ${ANDROID_PRODUCT_OUT}/vendor

आउटपुट में कई लाइनें होती हैं. टैब वर्ण के बिना की गई लाइन से नया सेक्शन शुरू होता है. टैब वर्ण वाली लाइन, पिछले सेक्शन पर निर्भर करती है. उदाहरण के लिए:

/system/lib/ld-android.so
/system/lib/libc.so
        /system/lib/libdl.so

इस आउटपुट से पता चलता है कि ld-android.so पर कोई डिपेंडेंसी नहीं है और libc.so, libdl.so पर निर्भर है.

--revert विकल्प चुनने पर, deps सब-कमांड लाइब्रेरी के इस्तेमाल (उलट-पुलट की गई डिपेंडेंसी) को प्रिंट करता है:

./vndk_definition_tool.py deps \
    --revert \
    --system ${ANDROID_PRODUCT_OUT}/system \
    --vendor ${ANDROID_PRODUCT_OUT}/vendor

उदाहरण के लिए:

/system/lib/ld-android.so
        /system/lib/libdl.so
        

इस आउटपुट से पता चलता है कि ld-android.so का इस्तेमाल libdl.so करता है. दूसरे शब्दों में, libdl.so पर ld-android.so का असर पड़ता है. इसके अलावा, इस आउटपुट से पता चलता है कि libdl.so, ld-android.so का एकमात्र उपयोगकर्ता है.

--symbol विकल्प चुनने पर, deps सब-कमांड इस्तेमाल किए जा रहे सिंबल को प्रिंट करता है:

./vndk_definition_tool.py deps \
    --symbol \
    --system ${ANDROID_PRODUCT_OUT}/system \
    --vendor ${ANDROID_PRODUCT_OUT}/vendor
    

उदाहरण के लिए:

/system/lib/libc.so
        /system/lib/libdl.so
                android_get_application_target_sdk_version
                dl_unwind_find_exidx
                dlclose
                dlerror
                dlopen
                dlsym

इस आउटपुट से पता चलता है कि libc.so, libdl.so से एक्सपोर्ट किए गए छह फ़ंक्शन पर निर्भर करता है. अगर --symbol और --revert, दोनों विकल्पों की जानकारी दी गई है, तो उपयोगकर्ता के इस्तेमाल किए गए सिंबल को प्रिंट किया जाता है.