मेनिफ़ेस्ट

VINTF ऑब्जेक्ट, डिवाइस मेनिफ़ेस्ट और फ़्रेमवर्क मेनिफ़ेस्ट फ़ाइलों (एक्सएमएल) से डेटा इकट्ठा करता है. दोनों मेनिफ़ेस्ट एक ही फ़ॉर्मैट में होते हैं. हालांकि, दोनों पर सभी एलिमेंट लागू नहीं होते. स्कीमा के बारे में ज़्यादा जानने के लिए, मेनिफ़ेस्ट फ़ाइल स्कीमा देखें.

डिवाइस मेनिफ़ेस्ट

डिवाइस मेनिफ़ेस्ट (डिवाइस से दिया गया) में वेंडर मेनिफ़ेस्ट और ओडीएम मेनिफ़ेस्ट शामिल होते हैं.

• वेंडर मेनिफ़ेस्ट में, SoC के लिए सामान्य तौर पर इस्तेमाल होने वाले एचएएल, SELinux नीति के वर्शन वगैरह की जानकारी होती है. हमारा सुझाव है कि इसे Android सोर्स ट्री में device/VENDOR/DEVICE/manifest.xml पर डाला जाए. हालांकि, एक से ज़्यादा फ़्रैगमेंट फ़ाइलों का इस्तेमाल किया जा सकता है. ज़्यादा जानकारी के लिए, मेनिफ़ेस्ट फ़्रैगमेंट और फ़्रैगमेंट से डीएम जनरेट करना देखें.
• ओडीएम मेनिफ़ेस्ट में, ओडीएम पार्टीशन में मौजूद प्रॉडक्ट के हिसाब से एचएएल की सूची होती है. VINTF ऑब्जेक्ट, ODM मेनिफ़ेस्ट को इस क्रम में लोड करता है:
  1. अगर SKU तय किया गया है (जहां SKU, प्रॉपर्टी ro.boot.product.hardware.sku की वैल्यू है), तो /odm/etc/vintf/manifest_SKU.xml
  2. /odm/etc/vintf/manifest.xml
  3. अगर SKU की वैल्यू दी गई है, तो /odm/etc/manifest_SKU.xml
  4. /odm/etc/manifest.xml
• वेंडर मेनिफ़ेस्ट में, वेंडर पार्टीशन में मौजूद प्रॉडक्ट के हिसाब से एचएएल की सूची होती है. VINTF ऑब्जेक्ट, वेंडर मेनिफ़ेस्ट को इस क्रम में लोड करता है:
  1. अगर SKU तय किया गया है (जहां SKU, प्रॉपर्टी ro.boot.product.vendor.sku की वैल्यू है), तो /vendor/etc/vintf/manifest_SKU.xml
  2. /vendor/etc/vintf/manifest.xml
• VINTF ऑब्जेक्ट, डिवाइस मेनिफ़ेस्ट को इस क्रम में लोड करता है:
  1. अगर वेंडर मेनिफ़ेस्ट मौजूद है, तो इन चीज़ों को जोड़ें:
     1. वेंडर मेनिफ़ेस्ट
     2. वेंडर मेनिफ़ेस्ट के वैकल्पिक फ़्रैगमेंट
     3. वैकल्पिक ओडीएम मेनिफ़ेस्ट
     4. वैकल्पिक ODM मेनिफ़ेस्ट फ़्रैगमेंट
  2. अगर ODM मेनिफ़ेस्ट मौजूद है, तो ODM मेनिफ़ेस्ट को वैकल्पिक ODM मेनिफ़ेस्ट फ़्रैगमेंट के साथ जोड़ें.
  3. /vendor/manifest.xml (लेगसी, कोई फ़्रैगमेंट नहीं)
  4. आखिर में, किसी भी वेंडर के APEX से मेनिफ़ेस्ट फ़्रैगमेंट को आपस में जोड़ें. मेनिफ़ेस्ट फ़्रैगमेंट, हर APEX (उदाहरण के लिए, /apex/<apex name>/etc/vintf) की etc/vintf डायरेक्ट्री से लोड किए जाते हैं.

  ध्यान दें कि:

  • लेगसी डिवाइसों पर, लेगसी वेंडर मेनिफ़ेस्ट और ओडीएम मेनिफ़ेस्ट का इस्तेमाल किया जाता है. ओडीएम मेनिफ़ेस्ट, वेंडर के लेगसी मेनिफ़ेस्ट को पूरी तरह से बदल सकता है.
  • Android 9 के साथ लॉन्च किए गए डिवाइसों पर, ओडीएम मेनिफ़ेस्ट को वेंडर मेनिफ़ेस्ट के साथ जोड़ा जाता है.
  • मेनिफ़ेस्ट की सूची को जोड़ते समय, सूची में बाद में दिखने वाले मेनिफ़ेस्ट, सूची में पहले दिखने वाले मेनिफ़ेस्ट के टैग को बदल सकते हैं. हालांकि, ऐसा तब ही होगा, जब बाद में दिखने वाले मेनिफ़ेस्ट के टैग में override="true" एट्रिब्यूट हो. उदाहरण के लिए, हो सकता है कि ODM मेनिफ़ेस्ट, वेंडर मेनिफ़ेस्ट के कुछ <hal> टैग को बदल दे. override एट्रिब्यूट के लिए, यहां दिया गया दस्तावेज़ देखें.

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

यहां वेंडर मेनिफ़ेस्ट का उदाहरण दिया गया है.

<?xml version="1.0" encoding="UTF-8"?>
<!-- Comments, Legal notices, etc. here -->
<manifest version="2.0" type="device" target-level="1">
    <hal>
        <name>android.hardware.camera</name>
        <transport>hwbinder</transport>
        <version>3.4</version>
        <interface>
            <name>ICameraProvider</name>
            <instance>legacy/0</instance>
            <instance>proprietary/0</instance>
        </interface>
    </hal>
    <hal>
        <name>android.hardware.nfc</name>
        <transport>hwbinder</transport>
        <version>1.0</version>
        <version>2.0</version>
        <interface>
            <name>INfc</name>
            <instance>nfc_nci</instance>
        </interface>
    </hal>
    <hal>
        <name>android.hardware.nfc</name>
        <transport>hwbinder</transport>
        <fqname>@2.0::INfc/default</fqname>
    </hal>
    <hal>
        <name>android.hardware.drm</name>
        <transport>hwbinder</transport>
        <version>1.0</version>
        <interface>
            <name>ICryptoFactory</name>
            <instance>default</instance>
        </interface>
        <interface>
            <name>IDrmFactory</name>
            <instance>default</instance>
        </interface>
        <fqname>@1.1::ICryptoFactory/clearkey</fqname>
        <fqname>@1.1::IDrmFactory/clearkey</fqname>
    </hal>
    <hal format="aidl">
        <name>android.hardware.light</name>
        <version>1</version>
        <fqname>ILights/default</fqname>
    </hal>
    <hal format="aidl">
        <name>android.hardware.power</name>
        <version>2</version>
        <interface>
            <name>IPower</name>
            <instance>default</instance>
        </interface>
    </hal>
    <hal format="native">
        <name>EGL</name>
        <version>1.1</version>
    </hal>
    <hal format="native">
        <name>GLES</name>
        <version>1.1</version>
        <version>2.0</version>
        <version>3.0</version>
    </hal>
    <sepolicy>
        <version>25.0</version>
    </sepolicy>
</manifest>

यहां ओडीएम मेनिफ़ेस्ट का एक उदाहरण दिया गया है.

<?xml version="1.0" encoding="UTF-8"?>
<!-- Comments, Legal notices, etc. here -->
<manifest version="1.0" type="device">
    <!-- camera 3.4 in vendor manifest is ignored -->
    <hal override="true">
        <name>android.hardware.camera</name>
        <transport>hwbinder</transport>
        <version>3.5</version>
        <interface>
            <name>ICameraProvider</name>
            <instance>legacy/0</instance>
        </interface>
    </hal>
    <!-- NFC is declared to be disabled -->
    <hal override="true">
        <name>android.hardware.nfc</name>
        <transport>hwbinder</transport>
    </hal>
    <hal>
        <name>android.hardware.power</name>
        <transport>hwbinder</transport>
        <version>1.1</version>
        <interface>
            <name>IPower</name>
            <instance>default</instance>
        </interface>
    </hal>
</manifest>

यहां ओटीए पैकेज में डिवाइस मेनिफ़ेस्ट का उदाहरण दिया गया है.

<?xml version="1.0" encoding="UTF-8"?>
<!-- Comments, Legal notices, etc. here -->
<manifest version="1.0" type="device" target-level="1">
    <!-- hals ommited -->
    <kernel version="4.4.176">
        <config>
            <key>CONFIG_ANDROID</key>
            <value>y</value>
        </config>
        <config>
            <key>CONFIG_ARM64</key>
            <value>y</value>
        </config>
    <!-- other configs ommited -->
    </kernel>
</manifest>

ज़्यादा जानकारी के लिए, डिवाइस मेनिफ़ेस्ट का डेवलपमेंट लेख पढ़ें.

फ़्रेमवर्क मेनिफ़ेस्ट

फ़्रेमवर्क मेनिफ़ेस्ट फ़ाइल में सिस्टम मेनिफ़ेस्ट, प्रॉडक्ट मेनिफ़ेस्ट, और system_ext मेनिफ़ेस्ट शामिल होता है.

• Google की ओर से दिया गया सिस्टम मेनिफ़ेस्ट, मैन्युअल तरीके से जनरेट किया जाता है और यह /system/libhidl/manifest.xml पर मौजूद Android सोर्स ट्री में मौजूद होता है.
• डिवाइस से मिलने वाले प्रॉडक्ट मेनिफ़ेस्ट में, उन एचएएल की सूची होती है जिन्हें प्रॉडक्ट के partition पर इंस्टॉल किए गए मॉड्यूल से सेवा दी जाती है.
• डिवाइस से मिलने वाले system_ext मेनिफ़ेस्ट में ये चीज़ें शामिल होती हैं:
  • system_ext पार्टीशन पर इंस्टॉल किए गए मॉड्यूल से काम करने वाले एचएएल;
  • VNDK के वर्शन;
  • सिस्टम के SDK टूल का वर्शन.

डिवाइस मेनिफ़ेस्ट की तरह, कई फ़्रैगमेंट फ़ाइलों का इस्तेमाल किया जा सकता है. ज़्यादा जानकारी के लिए, मेनिफ़ेस्ट फ़्रैगमेंट देखें.

यहां फ़्रेमवर्क मेनिफ़ेस्ट का एक उदाहरण दिया गया है.

<?xml version="1.0" encoding="UTF-8"?>
<!-- Comments, Legal notices, etc. here -->
<manifest version="1.0" type="framework">
    <hal>
        <name>android.hidl.allocator</name>
        <transport>hwbinder</transport>
        <version>1.0</version>
        <interface>
            <name>IAllocator</name>
            <instance>ashmem</instance>
        </interface>
    </hal>
    <hal>
        <name>android.hidl.memory</name>
        <transport arch="32+64">passthrough</transport>
        <version>1.0</version>
        <interface>
            <name>IMapper</name>
            <instance>ashmem</instance>
        </interface>
    </hal>
    <hal>
        <name>android.hidl.manager</name>
        <transport>hwbinder</transport>
        <version>1.0</version>
        <interface>
            <name>IServiceManager</name>
            <instance>default</instance>
        </interface>
    </hal>
    <hal>
        <name>android.frameworks.sensorservice</name>
        <transport>hwbinder</transport>
        <version>1.0</version>
        <interface>
            <name>ISensorManager</name>
            <instance>default</instance>
        </interface>
    </hal>
    <hal max-level="5">
        <name>android.frameworks.schedulerservice</name>
        <transport>hwbinder</transport>
        <version>1.0</version>
        <interface>
            <name>ISchedulingPolicyService</name>
            <instance>default</instance>
        </interface>
    </hal>
    <vendor-ndk>
        <version>27</version>
    </vendor-ndk>
    <system-sdk>
        <version>27</version>
    </system-sdk>
</manifest>

मेनिफ़ेस्ट फ़्रैगमेंट

Android 10 और उसके बाद के वर्शन में, बिल्ड सिस्टम में किसी मेनिफ़ेस्ट एन्ट्री को एचएएल मॉड्यूल से जोड़ा जा सकता है. इससे, बिल्ड सिस्टम में HAL मॉड्यूल को शर्त के हिसाब से शामिल करना आसान हो जाता है.

उदाहरण

अपनी Android.bp या Android.mk फ़ाइल में, cc_binary या rust_binary जैसे किसी भी ऐसे मॉड्यूल में vintf_fragments जोड़ें जो डिवाइस पर साफ़ तौर पर इंस्टॉल किया गया है. उदाहरण के लिए, अपने एचएएल (my.package.foo@1.0-service-bar) को लागू करके, मॉड्यूल में बदलाव किया जा सकता है.

... {
    ...
    vintf_fragments: ["manifest_foo.xml"],
    ...
}

LOCAL_MODULE := ...
LOCAL_VINTF_FRAGMENTS := manifest_foo.xml

manifest_foo.xml नाम की फ़ाइल में, इस मॉड्यूल के लिए मेनिफ़ेस्ट बनाएं. बिल्ड के समय, यह मेनिफ़ेस्ट डिवाइस में जोड़ दिया जाता है. यहां कोई एंट्री जोड़ना, डिवाइस के मुख्य मेनिफ़ेस्ट में एंट्री जोड़ने जैसा ही है. इससे क्लाइंट, इंटरफ़ेस का इस्तेमाल कर सकते हैं. साथ ही, VTS यह पता लगा सकता है कि डिवाइस पर कौनसे HAL लागू किए गए हैं. रेगुलर मेनिफ़ेस्ट के सभी काम, यह मेनिफ़ेस्ट भी करता है.

नीचे दिए गए उदाहरण में, android.hardware.foo@1.0::IFoo/default को लागू किया गया है. इसे vendor या odm पार्टीशन में इंस्टॉल किया गया है. अगर इसे system, product या system_ext partition में इंस्टॉल किया गया है, तो टाइप device के बजाय टाइप framework का इस्तेमाल करें.

<manifest version="1.0" type="device">
    <hal format="hidl">
        <name>android.hardware.foo</name>
        <transport>hwbinder</transport>
        <fqname>@1.0::IFoo/default</fqname>
    </hal>
</manifest>

अगर किसी एचएएल मॉड्यूल को वेंडर एपीईएक्स में पैकेज किया गया है, तो उससे जुड़े VINTF फ़्रैगमेंट को उसी एपीईएक्स में prebuilt_etc के साथ पैकेज करें, जैसा कि VINTF फ़्रैगमेंट में बताया गया है.

मेनिफ़ेस्ट फ़ाइल का स्कीमा

इस सेक्शन में, इन एक्सएमएल टैग के बारे में बताया गया है. Android सोर्स ट्री में मौजूद सोर्स फ़ाइल में, कुछ "ज़रूरी" टैग मौजूद न हो सकते. साथ ही, ये टैग बिल्ड के समय assemble_vintf के ज़रिए लिखे जा सकते हैं. डिवाइस पर, ज़रूरी टैग, उनसे जुड़ी फ़ाइलों में मौजूद होने चाहिए.

?xml

ज़रूरी नहीं. सिर्फ़ एक्सएमएल पार्सर को जानकारी देता है.

manifest.version

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

manifest.type

ज़रूरी है. इस मेनिफ़ेस्ट का टाइप. डिवाइस मेनिफ़ेस्ट फ़ाइल के लिए इसकी वैल्यू device और फ़्रेमवर्क मेनिफ़ेस्ट फ़ाइल के लिए framework है.

manifest.target-level

डिवाइस मेनिफ़ेस्ट के लिए ज़रूरी है. फ़्रेमवर्क के साथ काम करने की जानकारी देने वाले मैट्रिक्स (एफ़सीएम) के उस वर्शन के बारे में बताता है जिसके साथ इस डिवाइस मेनिफ़ेस्ट को काम करने के लिए टारगेट किया गया है. इसे डिवाइस का शिपिंग FCM वर्शन भी कहा जाता है.

manifest.hal

ज़रूरी नहीं, दोहराया जा सकता है. format एट्रिब्यूट के आधार पर, एक HAL (HIDL या नेटिव, जैसे कि GL).

manifest.hal.format

ज़रूरी नहीं. वैल्यू इनमें से कोई एक हो सकती है:

• hidl: HIDL HALs. यह डिफ़ॉल्ट विकल्प है.
• aidl: AIDL HALs. सिर्फ़ मेनिफ़ेस्ट के मेटा-वर्शन 2.0 और उसके बाद के वर्शन के लिए मान्य है.
• native: नेटिव एचएएल.

manifest.hal.max-level

ज़रूरी नहीं. सिर्फ़ फ़्रेमवर्क मेनिफ़ेस्ट पर मान्य है. अगर यह सेट है, तो फ़्रेमवर्क मेनिफ़ेस्ट में टारगेट FCM वर्शन से ज़्यादा लेवल वाले एचएएल बंद कर दिए जाते हैं.

manifest.hal.override

ज़रूरी नहीं. वैल्यू इनमें से कोई एक हो सकती है:

• true: एक ही <name> और मेजर वर्शन वाले अन्य <hal> एलिमेंट को बदलें. अगर इस <hal> एलिमेंट में कोई <version> या <fqname> नहीं है, तो <hal> एलिमेंट यह बताता है कि इस एचएएल को बंद कर दिया गया है.
• false: एक ही <name> और मेजर वर्शन वाले अन्य <hal> एलिमेंट को बदलना

manifest.hal.name

ज़रूरी है. एचएएल का पूरी तरह क्वालिफ़ाइड पैकेज नेम. एक से ज़्यादा एचएएल एंट्री में एक ही नाम का इस्तेमाल किया जा सकता है. उदाहरण:

• android.hardware.camera (HIDL या AIDL HAL)
• GLES (नेटिव एचएएल, सिर्फ़ नाम की ज़रूरत है)

manifest.hal.transport

manifest.hal.format == "hidl" के लिए ज़रूरी है. अगर ऐसा नहीं है, तो यह एट्रिब्यूट मौजूद नहीं होना चाहिए. इससे पता चलता है कि इस पैकेज के किसी इंटरफ़ेस से सेवा मैनेजर से क्वेरी करने पर, किस ट्रांसपोर्ट का इस्तेमाल किया जाता है. वैल्यू इनमें से कोई एक हो सकती है:

• hwbinder: बाइंडर मोड
• passthrough: पास-थ्रू मोड

manifest.hal.format == "aidl" होने पर ज़रूरी नहीं. अगर ऐसा नहीं है, तो यह एट्रिब्यूट मौजूद नहीं होना चाहिए. इससे पता चलता है कि किसी इंटरफ़ेस को रिमोट तौर पर दिखाने के लिए, किस ट्रांसपोर्ट का इस्तेमाल किया जाता है. वैल्यू इनमें से कोई एक होनी चाहिए:

• inet: Inet सॉकेट

इंटरनेट कनेक्शन की जानकारी देने के लिए, manifest.hal.transport.ip और manifest.hal.transport.port का इस्तेमाल करना ज़रूरी है.

manifest.hal.transport.arch

passthrough के लिए ज़रूरी है और hwbinder के लिए मौजूद नहीं होना चाहिए. इससे, दी जा रही पासथ्रू सेवा के बिट रेट के बारे में पता चलता है. वैल्यू इनमें से कोई एक हो सकती है:

• 32: 32-बिट मोड
• 64: 64-बिट मोड
• 32+64: दोनों

manifest.hal.transport.ip

inet के लिए ज़रूरी है. अगर inet नहीं है, तो इसकी वैल्यू नहीं होनी चाहिए. उस आईपी पते के बारे में बताता है जिससे रिमोट इंटरफ़ेस को दिखाया जा रहा है.

manifest.hal.transport.port

inet के लिए ज़रूरी है. अगर inet नहीं है, तो इसकी वैल्यू नहीं होनी चाहिए. उस पोर्ट के बारे में बताता है जिससे रिमोट इंटरफ़ेस को दिखाया जा रहा है.

manifest.hal.version

ज़रूरी नहीं, दोहराया जा सकता है. मेनिफ़ेस्ट में hal टैग का वर्शन.

HIDL और नेटिव एचएएल के लिए, फ़ॉर्मैट MAJOR.MINOR है. उदाहरण के लिए, hardware/interfaces, vendor/${VENDOR}/interfaces, frameworks/hardware/interfaces या system/hardware/interfaces देखें.

HIDL और नेटिव एचएएल, कई वर्शन फ़ील्ड का इस्तेमाल तब तक कर सकते हैं, जब तक वे अलग-अलग मुख्य वर्शन दिखाते हैं. साथ ही, हर मुख्य वर्शन के लिए सिर्फ़ एक मामूली वर्शन दिया जाता है. उदाहरण के लिए, 3.1 और 3.2 एक साथ काम नहीं कर सकते, लेकिन 1.0 और 3.4 एक साथ काम कर सकते हैं. यह एक ही नाम वाले सभी hal एलिमेंट पर लागू होता है, बशर्ते कि override="true" न हो. <version> की वैल्यू, <fqname> से नहीं जुड़ी होतीं, क्योंकि <fqname> में एक वर्शन होता है.

एआईडीएल एचएएल के लिए, Android 11 और उससे पहले के वर्शन पर <version> मौजूद नहीं होना चाहिए. Android 12 और उसके बाद के वर्शन वाले डिवाइसों पर, <version> एक पूर्णांक होना चाहिए. हर (package, interface, instance) ट्यूपल के लिए, ज़्यादा से ज़्यादा एक <version> होना चाहिए. अगर यह मौजूद नहीं है, तो डिफ़ॉल्ट रूप से 1 का इस्तेमाल किया जाएगा. <version> की वैल्यू, एक ही <hal> में मौजूद सभी <fqname> से जुड़ी होती है, क्योंकि <fqname> में कोई वर्शन नहीं होता.

manifest.hal.interface

ज़रूरी है. डुप्लीकेट के बिना दोहराया जा सकता है. पैकेज में ऐसा इंटरफ़ेस बताएं जिसमें इंस्टेंस का नाम हो. <hal> में कई <interface> एलिमेंट हो सकते हैं. हालांकि, उनके नाम अलग-अलग होने चाहिए.

manifest.hal.interface.name

ज़रूरी है. इंटरफ़ेस का नाम.

manifest.hal.interface.instance

ज़रूरी है, दोहराया जा सकता है. इंटरफ़ेस का इंस्टेंस नाम. किसी इंटरफ़ेस के लिए कई उदाहरण हो सकते हैं, लेकिन डुप्लीकेट <instance> एलिमेंट

नहीं हो सकते.

manifest.hal.fqname

ज़रूरी नहीं, दोहराया जा सकता है. manifest.hal.name नाम वाले HAL के लिए, इंस्टेंस तय करने का दूसरा तरीका.

• HIDL HAL के लिए, फ़ॉर्मैट @MAJOR.MINOR::INTERFACE/INSTANCE है.
• AIDL HAL के लिए, फ़ॉर्मैट INTERFACE/INSTANCE है.

manifest.sepolicy

ज़रूरी है. इसमें sepolicy से जुड़ी सभी एंट्री शामिल होती हैं.

manifest.sepolicy.version

डिवाइस मेनिफ़ेस्ट के लिए ज़रूरी है. SELinux वर्शन की जानकारी देता है. इसका SDK_INT.PLAT_INT फ़ॉर्मैट है.

manifest.vendor-ndk

ज़रूरी है, दोहराया जा सकता है; फ़्रेमवर्क मेनिफ़ेस्ट के लिए ज़रूरी है. डिवाइस मेनिफ़ेस्ट में मौजूद नहीं होना चाहिए. एक से ज़्यादा <vendor-ndk> एंट्री में अलग-अलग <version> होने चाहिए. फ़्रेमवर्क से मिले VNDK स्नैपशॉट के सेट के बारे में बताता है.

manifest.vendor-ndk.version

ज़रूरी है. यह एक पॉज़िटिव इंटिजर है, जो VNDK स्नैपशॉट के वर्शन को दिखाता है.

manifest.vendor-ndk.library

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

manifest.system-sdk.version

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

manifest.kernel

ज़रूरी नहीं. इसमें, कर्नेल के बारे में स्टैटिक जानकारी दी जाती है.

manifest.kernel.target-level

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