VINTF ऑब्जेक्ट, डिवाइस से डेटा इकट्ठा करता है मेनिफ़ेस्ट और फ़्रेमवर्क मेनिफ़ेस्ट फ़ाइलें (एक्सएमएल). दोनों मेनिफ़ेस्ट एक फ़ॉर्मैट शेयर करते हैं, हालांकि सभी एलिमेंट दोनों पर लागू नहीं होते (जानकारी के लिए स्कीमा पर जाकर, मेनिफ़ेस्ट फ़ाइल स्कीमा देखें).
डिवाइस मेनिफ़ेस्ट
डिवाइस मेनिफ़ेस्ट (डिवाइस से मिला) में वेंडर मेनिफ़ेस्ट शामिल होता है और ओडीएम मेनिफ़ेस्ट को भी शामिल करेंगे.
- वेंडर मेनिफ़ेस्ट में HAL, SELinux नीति वर्शन वगैरह के बारे में बताया जाता है. ये किसी SoC के लिए आम होते हैं. यह
Android सोर्स ट्री में
device/VENDOR/DEVICE/manifest.xml
, लेकिन कई फ़्रैगमेंट फ़ाइलों का इस्तेमाल किया जा सकता है. ज़्यादा जानकारी के लिए, मेनिफ़ेस्ट फ़्रैगमेंट देखें और जनरेट करें फ़्रैगमेंट से DM ढूंढें. - ओडीएम मेनिफ़ेस्ट में, प्रॉडक्ट के लिए खास तौर पर बने एचएएल की सूची होती है
ओडीएम का बंटवारा.
VINTF ऑब्जेक्ट, ओडीएम मेनिफ़ेस्ट को इस क्रम में लोड करता है:
- अगर
SKU
परिभाषित किया गया है (जहांSKU
प्रॉपर्टीro.boot.product.hardware.sku
),/odm/etc/vintf/manifest_SKU.xml
/odm/etc/vintf/manifest.xml
- अगर
SKU
तय किया गया है,/odm/etc/manifest_SKU.xml
/odm/etc/manifest.xml
- अगर
- वेंडर मेनिफ़ेस्ट में, प्रॉडक्ट के लिए खास तौर पर बने एचएएल की सूची मौजूद होती है. यह सूची वेंडर विभाजन में होती है.
VINTF ऑब्जेक्ट, वेंडर मेनिफ़ेस्ट को इस क्रम में लोड करता है:
- अगर
SKU
परिभाषित किया गया है (जहांSKU
प्रॉपर्टीro.boot.product.vendor.sku
),/vendor/etc/vintf/manifest_SKU.xml
/vendor/etc/vintf/manifest.xml
- अगर
- VINTF ऑब्जेक्ट, डिवाइस मेनिफ़ेस्ट को इस क्रम में लोड करता है:
- अगर वेंडर मेनिफ़ेस्ट मौजूद है, तो इन्हें मिला दें:
- वेंडर मेनिफ़ेस्ट
- वेंडर मेनिफ़ेस्ट के वैकल्पिक फ़्रैगमेंट
- वैकल्पिक ओडीएम मेनिफ़ेस्ट
- वैकल्पिक ओडीएम मेनिफ़ेस्ट फ़्रैगमेंट
- अगर ओडीएम मेनिफ़ेस्ट मौजूद है, तो उसे वैकल्पिक ओडीएम के साथ जोड़ें मेनिफ़ेस्ट फ़्रैगमेंट.
/vendor/manifest.xml
(लेगसी, कोई फ़्रैगमेंट नहीं)- आखिर में, किसी भी वेंडर APEXes के मेनिफ़ेस्ट फ़्रैगमेंट को जोड़ें.
ध्यान दें कि:
- लेगसी डिवाइसों पर, लेगसी वेंडर मेनिफ़ेस्ट और ओडीएम मेनिफ़ेस्ट का इस्तेमाल किया जाता है. कॉन्टेंट बनाने ओडीएम मेनिफ़ेस्ट, लेगसी वेंडर मेनिफ़ेस्ट को पूरी तरह बदल सकता है.
- Android 9 के साथ लॉन्च किए गए डिवाइसों पर, ओडीएम मेनिफ़ेस्ट को एक साथ के साथ सबमिट करना होगा.
- मेनिफ़ेस्ट की सूची को आपस में जोड़ने पर, इस सूची में बाद में दिखने वाले मेनिफ़ेस्ट को बदला जा सकता है
मेनिफ़ेस्ट में टैग जो सूची में पहले दिखते हैं, बशर्ते कि बाद में
मेनिफ़ेस्ट में
override="true"
एट्रिब्यूट है. उदाहरण के लिए, ओडीएम मेनिफ़ेस्ट में वेंडर मेनिफ़ेस्ट से कुछ<hal>
टैग को बदलें. इसके लिए दस्तावेज़ देखें एट्रिब्यूटoverride
एट्रिब्यूट की वैल्यू यहां दी गई है.
- अगर वेंडर मेनिफ़ेस्ट मौजूद है, तो इन्हें मिला दें:
इस सेटअप की मदद से, एक ही बोर्ड पर मौजूद कई प्रॉडक्ट के लिए एक जैसे हालांकि, वेंडर इमेज (जो कि सामान्य HAL प्रदान करती है) लेकिन फिर भी उसमें अलग ODM इमेज होती हैं (जिसमें खास तौर पर प्रॉडक्ट के लिए बने एचएएल के बारे में जानकारी देता है).
यहां वेंडर मेनिफ़ेस्ट का एक उदाहरण दिया गया है.
<?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 की ओर से उपलब्ध कराया गया) मैन्युअल तरीके से जनरेट किया जाता है और
Android सोर्स ट्री में मौजूद है
/system/libhidl/manifest.xml
. - डिवाइस के उपलब्ध कराए गए प्रॉडक्ट मेनिफ़ेस्ट में, ऐसे HAL की सूची दी जाती है जिन्हें इंस्टॉल किए गए मॉड्यूल की मदद से पूरा किया जाता है प्रॉडक्ट विभाजन.
-
system_ext मेनिफ़ेस्ट (डिवाइस से मिला) में यह सूची दी गई है:
- system_ext पार्टिशन में इंस्टॉल किए गए मॉड्यूल की मदद से सर्विस किए जाने वाले HAL;
- वीएनडीके वर्शन;
- सिस्टम 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 मॉड्यूल वाली एंट्री. इससे यह काम करना आसान हो जाता है बिल्ड सिस्टम में HAL मॉड्यूल को शर्त के साथ शामिल करना चाहिए.
उदाहरण
अपनी Android.bp
या Android.mk
फ़ाइल में, इसे जोड़ें
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
नाम की फ़ाइल में, इसके लिए मेनिफ़ेस्ट बनाएं
इस मॉड्यूल का उपयोग करें. बिल्ड टाइम के दौरान, इस मेनिफ़ेस्ट को डिवाइस में जोड़ा जाता है. जोड़ा जा रहा है
यहां एंट्री, डिवाइस के मुख्य मेनिफ़ेस्ट में किसी एंट्री को जोड़ने के समान है.
इससे क्लाइंट इंटरफ़ेस का इस्तेमाल कर पाते हैं. साथ ही, वीटीएस को यह पहचान करने में मदद मिलती है कि कौनसा एचएएल
डिवाइस पर लागू किए जा रहे हैं. ऐसी कोई भी चीज़ जो एक रेगुलर मेनिफ़ेस्ट फ़ाइल हो
इस मेनिफ़ेस्ट में भी बताया गया है.
नीचे दिया गया उदाहरण लागू करता है
android.hardware.foo@1.0::IFoo/default
, जो इस डिवाइस पर इंस्टॉल किया गया है
vendor
या odm
वाला सेगमेंट. अगर यह
system
, product
या system_ext
पार्टिशन, इस्तेमाल टाइप
के बजाय framework
device
टाइप करें.
<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>
अगर किसी HAL मॉड्यूल को वेंडर APEX में पैकेज किया जाता है,
इससे जुड़े VINTF फ़्रैगमेंट को prebuilt_etc
के साथ उसी APEX में इस तरह पैकेज करें:
VINTF फ़्रैगमेंट में बताया गया है.
मेनिफ़ेस्ट फ़ाइल स्कीमा
इस सेक्शन में, इन एक्सएमएल टैग का मतलब बताया गया है. कुछ "ज़रूरी" टैग
ऐसा हो सकता है कि Android सोर्स ट्री की सोर्स फ़ाइल से गायब हो और
assemble_vintf
अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है
बिल्ड टाइम के दौरान. ज़रूरी टैग, इस
डिवाइस.
?xml
- ज़रूरी नहीं. इसकी मदद से सिर्फ़ एक्सएमएल पार्सर को जानकारी दी जाती है.
manifest.version
- ज़रूरी है. इस मेनिफ़ेस्ट का मेटा-वर्शन. इसका वर्णन करता है मेनिफ़ेस्ट में उम्मीद के मुताबिक एलिमेंट. यह एक्सएमएल वर्शन से मिलता-जुलता नहीं है.
manifest.type
- ज़रूरी है. इस मेनिफ़ेस्ट का टाइप. इसका मान
device
है डिवाइस मेनिफ़ेस्ट फ़ाइल और फ़्रेमवर्क मेनिफ़ेस्ट के लिएframework
फ़ाइल खोलें.
manifest.target-level
- डिवाइस मेनिफ़ेस्ट के लिए ज़रूरी है. यह नीति, फ़्रेमवर्क के साथ काम करने वाले मैट्रिक्स की जानकारी देती है (FCM) का वह वर्शन जिसके साथ इस डिवाइस मेनिफ़ेस्ट को टारगेट किया गया है के साथ. इसे डिवाइस का शिपिंग FCM वर्शन भी कहा जाता है.
manifest.hal
- ज़रूरी नहीं, इसे दोहराया जा सकता है. एक एचएएल (HIDL या नेटिव), जैसे कि GL),
यह
format
एट्रिब्यूट के हिसाब से होता है. manifest.hal.format
- ज़रूरी नहीं. वैल्यू इनमें से एक हो सकती है:
hidl
: HIDL एचएएल. यह डिफ़ॉल्ट विकल्प है.aidl
: एआईडीएल एचएएल. सिर्फ़ मेनिफ़ेस्ट मेटा-वर्शन 2.0 और इसके बाद वाले वर्शन पर मान्य है.native
: नेटिव एचएएल.
manifest.hal.max-level
- ज़रूरी नहीं. सिर्फ़ फ़्रेमवर्क मेनिफ़ेस्ट पर मान्य है. अगर सेट हो, तो ज़्यादा से ज़्यादा निचले लेवल वाले एचएएल जबकि फ़्रेमवर्क मेनिफ़ेस्ट में टारगेट FCM वर्शन बंद है.
manifest.hal.override
- ज़रूरी नहीं. वैल्यू इनमें से एक हो सकती है:
true
: इससे दूसरे<hal>
एलिमेंट बदलें वही<name>
और मेजर वर्शन है. अगर नहीं<version>
या<fqname>
इसमें हैं<hal>
एलिमेंट और फिर<hal>
एलिमेंट इस एचएएल को बंद करने का एलान करता है.false
: अन्य<hal>
एलिमेंट न बदलें ऐसा ही<name>
और मेजर वर्शन के साथ करें.
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
का इस्तेमाल Inet कनेक्शन जानकारी को और ज़्यादा सटीक बनाने के लिए किया जाना चाहिए.manifest.hal.transport.arch
passthrough
के लिए ज़रूरी है और इनके लिए मौजूद नहीं होनी चाहिएhwbinder
. पासथ्रू सेवा की बिटनेस के बारे में बताता है दिया गया है. वैल्यू इनमें से एक हो सकती है:32
: 32-बिट मोड64
: 64-बिट मोड32+64
: दोनों
manifest.hal.transport.ip
inet
के लिए ज़रूरी है और किसी और वजह से मौजूद नहीं होना चाहिए. आईपी पते के बारे में बताता है जिससे रिमोट इंटरफ़ेस काम करता है.manifest.hal.transport.port
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>
वर्शन को ले जाता है.
एआईडीएल एचएएल के लिए, चल रहे डिवाइसों पर<version>
मौजूद नहीं होना चाहिए Android 11 और इससे पहले के वर्शन के लिए.<version>
Android 12 और उसके बाद के वर्शन वाले डिवाइसों पर सिंगल इंटीजर की सुविधा उपलब्ध है. हर एक के लिए ज़्यादा से ज़्यादा एक<version>
होना चाहिए(package, interface, instance)
टपल. अगर यह नहीं है, तो डिफ़ॉल्ट रूप से इस पर सेट होता है1
.<version>
की वैल्यू इससे जुड़ी होती है सभी<fqname>
एक ही<hal>
में, क्योंकि<fqname>
में कोई वर्शन नहीं है. manifest.hal.interface
- ज़रूरी है, डुप्लीकेट के बिना दोहराया जा सकता है.
वह पैकेज जिसका इंस्टेंस नाम है. एक से ज़्यादा
<hal>
में<interface>
एलिमेंट; नाम अलग होना चाहिए. manifest.hal.interface.name
- ज़रूरी है. इंटरफ़ेस का नाम.
manifest.hal.interface.instance
- ज़रूरी है, दोहराया जा सकता है. इंटरफ़ेस के इंस्टेंस का नाम. एक से ज़्यादा हो सकते हैं
इंटरफ़ेस के लिए इंस्टेंस, लेकिन
<instance>
का डुप्लीकेट नहीं है एलिमेंट शामिल करें. manifest.hal.fqname
- ज़रूरी नहीं, इसे दोहराया जा सकता है. एचएएल के लिए इंस्टेंस तय करने का एक दूसरा तरीका
manifest.hal.name
नाम से.- HIDL HAL के लिए, फ़ॉर्मैट यह है
@MAJOR.MINOR::INTERFACE/INSTANCE
. - एआईडीएल एचएएल के लिए फ़ॉर्मैट
INTERFACE/INSTANCE
.
- HIDL HAL के लिए, फ़ॉर्मैट यह है
manifest.sepolicy
- ज़रूरी है. में नीति से जुड़ी सभी एंट्री शामिल हैं.
manifest.sepolicy.version
- डिवाइस मेनिफ़ेस्ट के लिए ज़रूरी है. SELinux वर्शन की जानकारी देता है. इसमें
SDK_INT.PLAT_INT
फ़ॉर्मैट. manifest.vendor-ndk
- ज़रूरी है, दोहराया जा सकता है; मेनिफ़ेस्ट के लिए ज़रूरी है. मौजूद नहीं होना चाहिए
डिवाइस मेनिफ़ेस्ट फ़ाइल में. एक से ज़्यादा
<vendor-ndk>
एंट्री होनी चाहिए अलग-अलग<version>
. VNDK स्नैपशॉट के सेट के बारे में बताता है में दी गई जानकारी है. manifest.vendor-ndk.version
- ज़रूरी है. यह एक पॉज़िटिव पूर्णांक है, जो वीएनडीके के वर्शन को दिखाता है स्नैपशॉट.
manifest.vendor-ndk.library
- ज़रूरी नहीं, डुप्लीकेट के बिना, दोहराया जा सकता है. VNDK लाइब्रेरी के सेट के बारे में बताता है
जो वीएनडीके वेंडर स्नैपशॉट के फ़्रेमवर्क के ज़रिए उपलब्ध होते हैं. मान वह है
लाइब्रेरी का फ़ाइल नाम, जैसे
libjpeg.so
, प्रीफ़िक्स के साथlib
और सफ़िक्स.so
. कोई पाथ कॉम्पोनेंट नहीं है अनुमति है. manifest.system-sdk.version
- ज़रूरी नहीं, डुप्लीकेट के बिना, दोहराया जा सकता है; जिसे सिर्फ़ फ़्रेमवर्क से इस्तेमाल किया जाता है मेनिफ़ेस्ट. यह फ़्रेमवर्क, सिस्टम SDK टूल के वर्शन के ऐसे सेट के बारे में बताता है जो वेंडर ऐप्लिकेशन शामिल हैं.
manifest.kernel
- ज़रूरी नहीं. कर्नेल के बारे में स्टैटिक जानकारी देता है.
manifest.kernel.target-level
- ज़रूरी नहीं. कर्नेल ब्रांच के बारे में बताता है. इसकी वैल्यू डिफ़ॉल्ट तौर पर यह होती है
मौजूद न होने पर,
manifest.target-level
. से ज़्यादा होना चाहिए याmanifest.target-level
के बराबर. यहां जाएं: कर्नेल मैच के नियम देखें.