मिलान नियम

संगतता मैट्रिसेस और मैनिफ़ेस्ट के दो जोड़े का मिलान यह सत्यापित करने के लिए किया जाता है कि फ्रेमवर्क और विक्रेता कार्यान्वयन एक दूसरे के साथ काम कर सकते हैं। फ़्रेमवर्क संगतता मैट्रिक्स और डिवाइस मेनिफ़ेस्ट के साथ-साथ फ़्रेमवर्क मेनिफ़ेस्ट और डिवाइस संगतता मैट्रिक्स के बीच मिलान पर यह सत्यापन सफल होता है।

यह सत्यापन बिल्ड टाइम पर, OTA अपडेट पैकेज जनरेशन टाइम पर, बूट टाइम पर और VTS कम्पैटिबिलिटी टेस्ट में किया जाता है।

निम्नलिखित अनुभाग विभिन्न घटकों द्वारा उपयोग किए जाने वाले मिलान नियमों का विवरण देते हैं।

फ्रेमवर्क संगतता मैट्रिक्स संस्करण मेल खाता है

फ्रेमवर्क संगतता मैट्रिक्स के साथ डिवाइस मेनिफेस्ट का मिलान करने के लिए, manifest.target-level द्वारा निर्दिष्ट शिपिंग एफसीएम संस्करण compatibility-matrix.level मैट्रिक्स.लेवल द्वारा निर्दिष्ट एफसीएम संस्करण के बिल्कुल बराबर होना चाहिए। अन्यथा कोई मेल नहीं है।

जब फ्रेमवर्क संगतता मैट्रिक्स का अनुरोध libvintf के साथ किया जाता है, तो यह मैच हमेशा सफल होता है क्योंकि libvintf डिवाइस मेनिफेस्ट को खोलता है, शिपिंग FCM संस्करण को पुनः प्राप्त करता है, और उस शिपिंग FCM संस्करण पर फ्रेमवर्क संगतता मैट्रिक्स देता है (साथ ही उच्च FCM पर संगतता मैट्रिक्स से कुछ वैकल्पिक HALs) संस्करण)।

एचएएल मैच

hal -मैच नियम एक मेनिफेस्ट फ़ाइल में हाल तत्वों के संस्करणों की पहचान करता है जिन्हें संबंधित संगतता मैट्रिक्स के मालिक द्वारा समर्थित माना जाता है।

HIDL और देशी HALs

एचआईडीएल और देशी एचएएल के लिए मैच के नियम इस प्रकार हैं।

• एकाधिक <hal> तत्वों का मूल्यांकन एकल और संबंध के साथ किया जाता है।
• <hal> तत्वों में आवश्यक नहीं के रूप में चिह्नित करने के लिए <hal optional="true"> हो सकता है।
• एक ही <hal> में कई <version> तत्वों का OR संबंध होता है। यदि दो या अधिक निर्दिष्ट हैं, तो संस्करणों में से केवल एक को लागू करने की आवश्यकता है। (नीचे डीआरएम उदाहरण देखें।)
• एक ही <hal> के भीतर एक से अधिक <instance> और <regex-instance> तत्वों का मूल्यांकन एकल और संबंध के साथ किया जाता है जब <hal> की आवश्यकता होती है। (देखें नीचे डीआरएम उदाहरण।)

उदाहरण: मॉड्यूल के लिए सफल एचएएल मैच

संस्करण 2.5 पर एचएएल के लिए, मैच नियम इस प्रकार है:

आव्यूह	मैचिंग मैनिफेस्ट
2.5	2.5-2.∞. संगतता मैट्रिक्स में, 2.5 2.5-5 के लिए आशुलिपि है।
2.5-7	2.5-2.∞. निम्नलिखित इंगित करता है: 2.5 न्यूनतम आवश्यक संस्करण है, जिसका अर्थ है कि HAL 2.0-2.4 प्रदान करने वाला एक मेनिफेस्ट संगत नहीं है। 2.7 अधिकतम संस्करण है जिसका अनुरोध किया जा सकता है, जिसका अर्थ है कि संगतता मैट्रिक्स (फ्रेमवर्क या डिवाइस) का स्वामी 2.7 से अधिक संस्करणों का अनुरोध नहीं करेगा। जब 2.7 का अनुरोध किया जाता है, तब भी मेल खाने वाले मेनिफेस्ट का स्वामी संस्करण 2.10 (उदाहरण के तौर पर) प्रस्तुत कर सकता है। संगतता-मैट्रिक्स स्वामी केवल यह जानता है कि अनुरोधित सेवा API संस्करण 2.7 के साथ संगत है। -7 केवल सूचनात्मक है और ओटीए अद्यतन प्रक्रिया को प्रभावित नहीं करता है। इस प्रकार, एक डिवाइस जिसकी मेनिफेस्ट फ़ाइल में संस्करण 2.10 पर एचएएल है, एक फ्रेमवर्क के साथ संगत रहता है जो इसकी संगतता मैट्रिक्स में 2.5-7 बताता है।

उदाहरण: डीआरएम मॉड्यूल के लिए सफल एचएएल मैच

फ्रेमवर्क संगतता मैट्रिक्स DRM HAL के लिए निम्न संस्करण जानकारी बताता है:

<hal>
    <name>android.hardware.drm
    <version>1.0</version>
    <version>3.1-2</version>
    <interface>
        <name>IDrmFactory</name>
        <instance>default</instance>
        <instance>specific</instance>
    </interface>
</hal>
<hal>
    <name>android.hardware.drm
    <version>2.0</version>
    <interface>
        <name>ICryptoFactory</name>
        <instance>default</instance>
        <regex-instance>[a-z]+/[0-9]+</regex-instance>
    </interface>
</hal>

एक विक्रेता को निम्नलिखित उदाहरणों में से एक को लागू करना चाहिए; या

android.hardware.drm@1.x::IDrmFactory/default          // where x >= 0
android.hardware.drm@1.x::IDrmFactory/specific         // where x >= 0

2 या

android.hardware.drm@3.y::IDrmFactory/default          // where y >= 1
android.hardware.drm@3.y::IDrmFactory/specific         // where y >= 1

और इन सभी उदाहरणों को भी लागू करना चाहिए:

android.hardware.drm@2.z::ICryptoFactory/default       // where z >= 0
android.hardware.drm@2.z::ICryptoFactory/${INSTANCE}
            // where z >= 0 and ${INSTANCE} matches [a-z]+/[0-9]+
            // e.g. legacy/0

एआईडीएल एचएएल

Android 11 के बाद के सभी Android संस्करण (Android 11 को छोड़कर) VINTF में AIDL HAL के संस्करणों का समर्थन करते हैं। एआईडीएल एचएएल के लिए मैच नियम एचआईडीएल और देशी एचएएल के समान हैं, सिवाय इसके कि कोई प्रमुख संस्करण नहीं हैं, और एचएएल उदाहरण के लिए एक संस्करण है ( 1 यदि संस्करण अनिर्दिष्ट है)।

• एकाधिक <hal> तत्वों का मूल्यांकन एकल और संबंध के साथ किया जाता है।
• <hal> तत्वों में आवश्यक नहीं के रूप में चिह्नित करने के लिए <hal optional="true"> हो सकता है।
• एक ही <hal> के भीतर एक से अधिक <instance> और <regex-instance> तत्वों का मूल्यांकन एकल और संबंध के साथ किया जाता है जब <hal> की आवश्यकता होती है। (देखें थरथानेवाला उदाहरण नीचे।)

उदाहरण: मॉड्यूल के लिए सफल एचएएल मैच

संस्करण 5 में एचएएल के लिए, मैच नियम इस प्रकार है:

आव्यूह	मैचिंग मैनिफेस्ट
5	5-∞. संगतता मैट्रिक्स में, 5 5-5 के लिए आशुलिपि है।
5-7	5-∞. निम्नलिखित इंगित करता है: 5 न्यूनतम आवश्यक संस्करण है, जिसका अर्थ है कि एचएएल 1-4 प्रदान करने वाला मैनिफेस्ट संगत नहीं है। 7 अधिकतम संस्करण है जिसका अनुरोध किया जा सकता है, जिसका अर्थ है कि संगतता मैट्रिक्स (फ्रेमवर्क या डिवाइस) का स्वामी 7 से अधिक संस्करणों का अनुरोध नहीं करेगा। मिलान मैनिफेस्ट का स्वामी अभी भी संस्करण 10 (उदाहरण के रूप में) की सेवा कर सकता है जब 7 का अनुरोध किया जाता है . संगतता-मैट्रिक्स स्वामी केवल यह जानता है कि अनुरोधित सेवा API संस्करण 7 के साथ संगत है। -7 केवल सूचनात्मक है और ओटीए अद्यतन प्रक्रिया को प्रभावित नहीं करता है। इस प्रकार, मैनिफेस्ट फ़ाइल में संस्करण 10 पर एचएएल वाला एक उपकरण एक ढांचे के साथ संगत रहता है जो इसकी संगतता मैट्रिक्स में 5-7 बताता है।

उदाहरण: कई मॉड्यूल के लिए सफल एचएएल मैच

फ्रेमवर्क संगतता मैट्रिक्स वाइब्रेटर और कैमरा एचएएल के लिए निम्नलिखित संस्करण जानकारी बताता है:

<hal>
    <name>android.hardware.vibrator
    <version>1-2</version>
    <interface>
        <name>IVibrator</name>
        <instance>default</instance>
        <instance>specific</instance>
    </interface>
</hal>
<hal>
    <name>android.hardware.camera
    <version>5</version>
    <interface>
        <name>ICamera</name>
        <instance>default</instance>
        <regex-instance>[a-z]+/[0-9]+</regex-instance>
    </interface>
</hal>

एक विक्रेता को इन सभी उदाहरणों को लागू करना चाहिए:

android.hardware.vibrator.IVibrator/default     // version >= 1
android.hardware.vibrator.IVibrator/specific    // version >= 1
android.hardware.camera.ICamera/default         // version >= 5
android.hardware.camera.ICamera/${INSTANCE}
            // with version >= 5, where ${INSTANCE} matches [a-z]+/[0-9]+
            // e.g. legacy/0

कर्नेल मैच

फ्रेमवर्क संगतता मैट्रिक्स का <kernel> खंड डिवाइस पर लिनक्स कर्नेल की ढांचे की आवश्यकताओं का वर्णन करता है। यह जानकारी डिवाइस के VINTF ऑब्जेक्ट द्वारा रिपोर्ट किए जाने वाले कर्नेल के बारे में जानकारी से मिलान करने के लिए है।

कर्नेल शाखाओं का मिलान करें

प्रत्येक कर्नेल शाखा प्रत्यय (उदाहरण के लिए, 5.4- r ) को एक अद्वितीय कर्नेल FCM संस्करण में मैप किया जाता है (उदाहरण के लिए, 5)। मैपिंग रिलीज अक्षरों (उदाहरण के लिए, आर) और एफसीएम संस्करणों (उदाहरण के लिए, 5) के बीच मैपिंग के समान है।

वीटीएस परीक्षण लागू करते हैं कि डिवाइस डिवाइस मेनिफेस्ट में कर्नेल एफसीएम संस्करण को स्पष्ट रूप से निर्दिष्ट करता है, /vendor/etc/vintf/manifest.xml , यदि निम्न में से कोई एक सत्य है:

• कर्नेल FCM संस्करण लक्ष्य FCM संस्करण से भिन्न है। उदाहरण के लिए, उपरोक्त डिवाइस का लक्ष्य FCM संस्करण 4 है, और इसका कर्नेल FCM संस्करण 5 (कर्नेल शाखा प्रत्यय r ) है।
• कर्नेल FCM संस्करण 5 से बड़ा या उसके बराबर है (कर्नेल शाखा प्रत्यय r )।

नोट: यदि कर्नेल FCM संस्करण लक्ष्य FCM संस्करण के बराबर है और वे 5 से अधिक या उसके बराबर हैं, तो DEVICE_MANIFEST_FILE द्वारा निर्दिष्ट डिवाइस मेनिफेस्ट की स्रोत फ़ाइल को कर्नेल FCM संस्करण निर्दिष्ट करने की आवश्यकता नहीं है। अगर लक्ष्य एफसीएम संस्करण 5 से अधिक या उसके बराबर है, तो assemble_vintf स्वचालित रूप से लक्ष्य एफसीएम संस्करण से कर्नेल एफसीएम संस्करण का अनुमान लगाता है।

वीटीएस परीक्षण लागू करते हैं कि, यदि कर्नेल एफसीएम संस्करण निर्दिष्ट है, तो कर्नेल एफसीएम संस्करण डिवाइस मेनिफेस्ट में लक्ष्य एफसीएम संस्करण से अधिक या उसके बराबर है।

उदाहरण: कर्नेल शाखा निर्धारित करें

यदि डिवाइस का लक्ष्य FCM संस्करण 4 (Android 10 में जारी) है, लेकिन 4.19-r शाखा से कर्नेल चलाता है, तो डिवाइस मेनिफेस्ट को निम्नलिखित निर्दिष्ट करना चाहिए:

<manifest version="2.0" type="device" target-level="4">
   <kernel target-level="5" />
</manifest>

VINTF ऑब्जेक्ट 4.19-r कर्नेल शाखा पर आवश्यकताओं के विरुद्ध कर्नेल संगतता की जाँच करता है, जो FCM संस्करण 5 में निर्दिष्ट है। ये आवश्यकताएँ Android स्रोत ट्री में kernel/configs/r/android-4.19 से बनाई गई हैं।

उदाहरण: GKI के लिए कर्नेल शाखा निर्धारित करें

यदि डिवाइस जेनेरिक कर्नेल इमेज (GKI) का उपयोग करता है, और /proc/version से कर्नेल रिलीज़ स्ट्रिंग निम्न है:

5.4.42-android12-0-00544-ged21d463f856

फिर, VINTF ऑब्जेक्ट कर्नेल रिलीज़ से Android रिलीज़ प्राप्त करता है, और इसका उपयोग कर्नेल FCM संस्करण को निर्धारित करने के लिए करता है। इस उदाहरण में, android12 का अर्थ है कर्नेल FCM संस्करण 6 (Android 12 में जारी)।

कर्नेल रिलीज़ स्ट्रिंग को कैसे पार्स किया जाता है, इसके विवरण के लिए, GKI संस्करण देखें।

कर्नेल संस्करणों का मिलान करें

एक मैट्रिक्स में कई <kernel> अनुभाग शामिल हो सकते हैं, जिनमें से प्रत्येक प्रारूप का उपयोग करके एक अलग version विशेषता के साथ होता है:

${ver}.${major_rev}.${kernel_minor_rev}

VINTF ऑब्जेक्ट FCM से केवल <kernel> अनुभाग को समान ${ver} और ${major_rev} के साथ डिवाइस कर्नेल (यानी, version="${ver}.${major_rev}.${matrix_minor_rev}") के साथ मिलान करने वाले FCM संस्करण पर विचार करता है। version="${ver}.${major_rev}.${matrix_minor_rev}") ; अन्य वर्गों की उपेक्षा की जाती है। इसके अलावा, कर्नेल से मामूली संशोधन संगतता मैट्रिक्स ( ${kernel_minor_rev} >= ${matrix_minor_rev} ;) से एक मान होना चाहिए। यदि कोई <kernel> अनुभाग इन आवश्यकताओं को पूरा नहीं करता है, तो यह एक गैर-मिलान है।

उदाहरण: मिलान के लिए आवश्यकताओं का चयन करें

निम्नलिखित काल्पनिक मामले पर विचार करें जहां /system/etc/vintf में एफसीएम निम्नलिखित आवश्यकताओं की घोषणा करते हैं (शीर्षलेख और पाद लेख टैग छोड़े जाते हैं):

<!-- compatibility_matrix.3.xml -->
<kernel version="4.4.107" level="3"/>
<!-- See kernel/configs/p/android-4.4/ for 4.4-p requirements -->
<kernel version="4.9.84" level="3"/>
<!-- See kernel/configs/p/android-4.9/ for 4.9-p requirements -->
<kernel version="4.14.42" level="3"/>
<!-- See kernel/configs/p/android-4.14/ for 4.14-p requirements -->

<!-- compatibility_matrix.4.xml -->
<kernel version="4.9.165" level="4"/>
<!-- See kernel/configs/q/android-4.9/ for 4.9-q requirements -->
<kernel version="4.14.105" level="4"/>
<!-- See kernel/configs/q/android-4.14/ for 4.14-q requirements -->
<kernel version="4.19.42" level="4"/>
<!-- See kernel/configs/q/android-4.19/ for 4.19-q requirements -->

<!-- compatibility_matrix.5.xml -->
<kernel version="4.14.180" level="5"/>
<!-- See kernel/configs/r/android-4.14/ for 4.14-r requirements -->
<kernel version="4.19.123" level="5"/>
<!-- See kernel/configs/r/android-4.19/ for 4.19-r requirements -->
<kernel version="5.4.41" level="5"/>
<!-- See kernel/configs/r/android-5.4/ for 5.4-r requirements -->

लक्ष्य FCM संस्करण, कर्नेल FCM संस्करण, और कर्नेल संस्करण मिलकर FCM से कर्नेल आवश्यकताओं का चयन करते हैं:

लक्ष्य एफसीएम संस्करण	कर्नेल एफसीएम संस्करण	कर्नेल संस्करण	साथ मिलाना
3 (पी)	अनिर्दिष्ट	4.4.106	कोई मैच नहीं (मामूली संस्करण बेमेल)
3 (पी)	अनिर्दिष्ट	4.4.107	4.4-p
3 (पी)	अनिर्दिष्ट	4.19.42	4.19-q (नीचे नोट देखें)
3 (पी)	अनिर्दिष्ट	5.4.41	5.4-r (नीचे नोट देखें)
3 (पी)	3 (पी)	4.4.107	4.4-p
3 (पी)	3 (पी)	4.19.42	कोई मेल नहीं (कोई 4.19-p कर्नेल शाखा नहीं)
3 (पी)	4 (क्यू)	4.19.42	4.19-q
4 (क्यू)	अनिर्दिष्ट	4.4.107	कोई मेल नहीं (कोई 4.4-q कर्नेल शाखा नहीं)
4 (क्यू)	अनिर्दिष्ट	4.9.165	4.9-q
4 (क्यू)	अनिर्दिष्ट	5.4.41	5.4-r (नीचे नोट देखें)
4 (क्यू)	4 (क्यू)	4.9.165	4.9-q
4 (क्यू)	4 (क्यू)	5.4.41	कोई मेल नहीं (कोई 5.4-q कर्नेल शाखा नहीं)
4 (क्यू)	5 (आर)	4.14.105	4.14-r
4 (क्यू)	5 (आर)	5.4.41	5.4-r
5 (आर)	अनिर्दिष्ट	कोई	VTS विफल रहता है (लक्ष्य FCM संस्करण 5 के लिए कर्नेल FCM संस्करण अवश्य निर्दिष्ट करें)
5 (आर)	4 (क्यू)	कोई	VTS विफल रहता है (कर्नेल FCM संस्करण < लक्ष्य FCM संस्करण)
5 (आर)	5 (आर)	4.14.180	4.14-r

नोट: 5 (R) से कम लक्ष्य FCM संस्करण और एक अनिर्दिष्ट कर्नेल FCM संस्करण वाले डिवाइस के लिए, VINTF ऑब्जेक्ट सबसे कम प्रत्यय वाली कर्नेल शाखा का चयन करता है जो मिलान कर्नेल संस्करण के साथ लक्ष्य FCM संस्करण से अधिक है। उपरोक्त उदाहरण में, 3 (P) के लक्ष्य FCM संस्करण वाला एक उपकरण 4.19-q कर्नेल शाखा का उपयोग करता है क्योंकि 4.19-q में सभी 4.19-* कर्नेल शाखाओं में सबसे कम प्रत्यय है, [4.19-q, 4.19-r, 4.19-s] । यह आवश्यकता चयन व्यवहार 5 (R) या उच्चतर के लक्ष्य FCM संस्करण वाले उपकरणों के लिए अस्वीकृत है, क्योंकि कर्नेल FCM संस्करण को निर्दिष्ट किया जाना चाहिए।

कर्नेल कॉन्फ़िगरेशन का मिलान करें

यदि <kernel> अनुभाग मेल खाता है, तो config तत्वों को /proc/config.gz के विरुद्ध मिलान करने का प्रयास करके प्रक्रिया जारी रहती है। संगतता मैट्रिक्स में प्रत्येक कॉन्फ़िगरेशन तत्व के लिए, यह देखने के लिए /proc/config.gz देखता है कि कॉन्फ़िगरेशन मौजूद है या नहीं। जब एक कॉन्फिग आइटम को मैचिंग <kernel> सेक्शन के लिए कम्पैटिबिलिटी मैट्रिक्स में n पर सेट किया जाता है, तो यह /proc/config.gz से अनुपस्थित होना चाहिए। अंत में, एक कॉन्फिग आइटम जो संगतता मैट्रिक्स में नहीं है /proc/config.gz में मौजूद हो भी सकता है और नहीं भी।

उदाहरण: कर्नेल विन्यास का मिलान करें

• <value type="string">bar</value> "bar" से मेल खाता है। संगतता मैट्रिक्स में उद्धरण छोड़े गए हैं लेकिन /proc/config.gz में मौजूद हैं।
• <value type="int">4096</value> 4096 या 0x1000 या 0X1000 से मेल खाता है।
• <value type="int">0x1000</value> 4096 या 0x1000 या 0X1000 से मेल खाता है।
• <value type="int">0X1000</value> 4096 या 0x1000 या 0X1000 से मेल खाता है।
• <value type="tristate">y</value> y से मेल खाता है।
• <value type="tristate">m</value> m से मेल खाता है।
• <value type="tristate">n</value> का अर्थ है कि कॉन्फिग आइटम /proc/config.gz में मौजूद नहीं होना चाहिए।
• <value type="range">1-0x3</value> 1 , 2 , या 3 , या हेक्साडेसिमल समकक्ष से मेल खाता है।

उदाहरण: सफल कर्नेल मिलान

FCM संस्करण 1 के साथ एक फ्रेमवर्क संगतता मैट्रिक्स में निम्नलिखित कर्नेल जानकारी होती है:

<kernel version="4.14.42">
   <config>
      <key>CONFIG_TRI</key>
      <value type="tristate">y</value>
   </config>
   <config>
      <key>CONFIG_NOEXIST</key>
      <value type="tristate">n</value>
   </config>
   <config>
      <key>CONFIG_DEC</key>
      <value type="int">4096</value>
   </config>
   <config>
      <key>CONFIG_HEX</key>
      <value type="int">0XDEAD</value>
   </config>
   <config>
      <key>CONFIG_STR</key>
      <value type="string">str</value>
   </config>
   <config>
      <key>CONFIG_EMPTY</key>
      <value type="string"></value>
   </config>
</kernel>

पहले कर्नेल शाखा का मिलान किया जाता है। कर्नेल शाखा को manifest.kernel.target-level में डिवाइस manifest.level में निर्दिष्ट किया जाता है। यदि डिवाइस में कर्नेल शाखा प्रकट होती है:

• 1 है, अगले चरण पर आगे बढ़ता है और कर्नेल संस्करण की जांच करता है।
• 2 है, मैट्रिक्स से कोई मेल नहीं है। VINTF ऑब्जेक्ट इसके बजाय FCM संस्करण 2 में मैट्रिक्स से कर्नेल आवश्यकताओं को पढ़ता है।

फिर, कर्नेल संस्करण का मिलान किया जाता है। यदि कोई डिवाइस uname() रिपोर्ट करता है:

• 4.9.84 (मैट्रिक्स से कोई मेल नहीं है जब तक कि <kernel version="4.9.x"> के साथ एक अलग कर्नेल अनुभाग न हो, जहां x <= 84 )
• 4.14.41 (मैट्रिक्स से कोई मेल नहीं, version से छोटा)
• 4.14.42 (मैट्रिक्स से मिलान)
• 4.14.43 (मैट्रिक्स से मिलान)
• 4.1.22 (मैट्रिक्स से कोई मेल नहीं जब तक कि <kernel version="4.1.x"> जहां x <= 22 ) के साथ एक अलग कर्नेल अनुभाग न हो।

उपयुक्त <kernel> अनुभाग के चयन के बाद, प्रत्येक <config> आइटम के लिए n के अलावा अन्य मूल्य के साथ, हम उम्मीद करते हैं कि संबंधित प्रविष्टि /proc/config.gz में मौजूद होगी; मान n के साथ प्रत्येक <config> आइटम के लिए, हम उम्मीद करते हैं कि संबंधित प्रविष्टि /proc/config.gz में मौजूद नहीं होगी। हम उम्मीद करते हैं कि <value> की सामग्री बराबर चिह्न (उद्धरण सहित) के बाद टेक्स्ट से बिल्कुल मेल खाएगी, न्यूलाइन कैरेक्टर तक या # , जिसमें अग्रणी और पिछला व्हाइटस्पेस छोटा कर दिया गया है।

निम्नलिखित कर्नेल विन्यास एक सफल मिलान का एक उदाहरण है:

# comments don't matter
CONFIG_TRI=y
# CONFIG_NOEXIST shouldn't exist
CONFIG_DEC = 4096 # trailing comments and whitespaces are fine
CONFIG_HEX=57005  # 0XDEAD == 57005
CONFIG_STR="str"
CONFIG_EMPTY=""   # empty string must have quotes
CONFIG_EXTRA="extra config items are fine too"

निम्न कर्नेल कॉन्फ़िगरेशन असफल मिलान का एक उदाहरण है:

CONFIG_TRI="y"   # mismatch: quotes
CONFIG_NOEXIST=y # mismatch: CONFIG_NOEXIST exists
CONFIG_HEX=0x0   # mismatch; value doesn't match
CONFIG_DEC=""    # mismatch; type mismatch (expect int)
CONFIG_EMPTY=1   # mismatch; expects ""
# mismatch: CONFIG_STR is missing

एसई नीति मैच

SE नीति के लिए निम्नलिखित मिलानों की आवश्यकता है:

• <sepolicy-version> प्रत्येक प्रमुख संस्करण के लिए छोटे संस्करणों की एक बंद श्रेणी को परिभाषित करता है। डिवाइस द्वारा रिपोर्ट किया गया सेपॉलिसी संस्करण ढांचे के अनुकूल होने के लिए इनमें से किसी एक सीमा के भीतर होना चाहिए। मैच के नियम एचएएल संस्करणों के समान हैं; यह एक मैच है यदि सेपॉलिसी संस्करण सीमा के लिए न्यूनतम संस्करण के बराबर या अधिक है। अधिकतम संस्करण विशुद्ध रूप से सूचनात्मक है।
• <kernel-sepolicy-version> यानी पॉलिसीडीबी संस्करण। डिवाइस द्वारा रिपोर्ट की गई security_policyvers() से कम होनी चाहिए।

उदाहरण: सफल SE नीति मिलान

फ्रेमवर्क संगतता मैट्रिक्स निम्नलिखित सेपॉलिसी जानकारी बताता है:

<sepolicy>
    <kernel-sepolicy-version>30</kernel-sepolicy-version>
    <sepolicy-version>25.0</sepolicy-version>
    <sepolicy-version>26.0-3</sepolicy-version>
</sepolicy>

उपकरण पर:

• security_policyvers() द्वारा लौटाया गया मान 30 से अधिक या उसके बराबर होना चाहिए। अन्यथा यह मेल नहीं है। उदाहरण के लिए:
  • यदि कोई उपकरण 29 लौटाता है, तो यह मिलान नहीं है।
  • यदि कोई उपकरण 31 लौटाता है, तो यह एक मिलान है।
• SE नीति संस्करण 25.0-∞ या 26.0-∞ में से एक होना चाहिए। अन्यथा यह मैच नहीं है। (" 26.0 " के बाद " -3 " विशुद्ध रूप से सूचनात्मक है।)

एवीबी संस्करण मेल खाता है

AVB संस्करण में MAJOR.MINOR (जैसे, 1.0, 2.1) के रूप में प्रारूप के साथ एक MAJOR संस्करण और MINOR संस्करण शामिल है। विवरण के लिए, संस्करण और संगतता देखें। AVB संस्करण में निम्नलिखित सिस्टम गुण हैं:

• ro.boot.vbmeta.avb_version बूटलोडर में libavb संस्करण है
• ro.boot.avb_version Android OS ( init/fs_mgr ) में libavb संस्करण है।

सिस्टम गुण केवल तभी प्रकट होता है जब संबंधित libavb का उपयोग AVB मेटाडेटा को सत्यापित करने के लिए किया गया हो (और ठीक लौटाता है)। यदि सत्यापन विफलता हुई (या कोई सत्यापन बिल्कुल नहीं हुआ) तो यह अनुपस्थित है।

एक संगतता मिलान निम्नलिखित की तुलना करता है:

• फ्रेमवर्क संगतता मैट्रिक्स से avb.vbmeta-version ro.boot.vbmeta.avb_version
  • ro.boot.vbmeta.avb_version.MAJOR == avb.vbmeta-version.MAJOR
  • ro.boot.vbmeta.avb_version.MINOR >= avb.vbmeta-version.MINOR
• फ्रेमवर्क संगतता मैट्रिक्स से avb.vbmeta-version ro.boot.avb_version
  • ro.boot.avb_version.MAJOR == avb.vbmeta-version.MAJOR
  • ro.boot.avb_version.MINOR >= avb.vbmeta-version.MINOR

बूटलोडर या एंड्रॉइड ओएस में libavb पुस्तकालयों की दो प्रतियां हो सकती हैं, प्रत्येक अपग्रेड डिवाइस और लॉन्च डिवाइस के लिए एक अलग प्रमुख संस्करण के साथ। इस मामले में, एक ही अहस्ताक्षरित सिस्टम छवि साझा की जा सकती है लेकिन अंतिम हस्ताक्षरित सिस्टम छवियां अलग हैं (विभिन्न avb.vbmeta-version साथ):

चित्रा 1. एवीबी संस्करण मेल खाता है ( /system पी है, अन्य सभी विभाजन ओ हैं)।

चित्रा 2. एवीबी संस्करण मेल खाता है (सभी विभाजन पी हैं)।

उदाहरण: सफल AVB संस्करण मिलान

फ्रेमवर्क संगतता मैट्रिक्स निम्नलिखित AVB जानकारी बताता है:

<avb>
    <vbmeta-version>2.1</vbmeta-version>
</avb>

उपकरण पर:

ro.boot.avb_version              == 1.0 &&
ro.boot.vbmeta.avb_version       == 2.1  mismatch 

ro.boot.avb_version              == 2.1 &&
ro.boot.vbmeta.avb_version       == 3.0  mismatch 

ro.boot.avb_version              == 2.1 &&
ro.boot.vbmeta.avb_version       == 2.3  match 

ro.boot.avb_version              == 2.3 &&
ro.boot.vbmeta.avb_version       == 2.1  match 

ओटीए के दौरान एवीबी संस्करण का मिलान

ध्यान दें: यह सेक्शन Android 11 में अपडेट होने वाले डिवाइस पर लागू नहीं होता है।

एंड्रॉइड 9 या उससे कम के साथ लॉन्च किए गए उपकरणों के लिए, एंड्रॉइड 10 में अपडेट करते समय, फ्रेमवर्क संगतता मैट्रिक्स में एवीबी संस्करण की आवश्यकताएं डिवाइस पर वर्तमान एवीबी संस्करण के साथ मेल खाती हैं। यदि ओटीए के दौरान एवीबी संस्करण में एक प्रमुख संस्करण अपग्रेड है (उदाहरण के लिए, 0.0 से 1.0 तक), तो ओटीए में संगतता के लिए वीआईएनटीएफ जांच ओटीए के बाद संगतता को प्रतिबिंबित नहीं करती है।

समस्या को कम करने के लिए, एक OEM एक नकली AVB संस्करण को OTA पैकेज में रख सकता है ( compatibility.zip । ज़िप) चेक पास करने के लिए। ऐसा करने के लिए:

1. चेरी-निम्न CL को Android 9 स्रोत ट्री में चुनें:
   • सीएल 732261
   • सीएल 732262
2. डिवाइस के लिए BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE परिभाषित करें। इसका मान ओटीए से पहले के एवीबी संस्करण के बराबर होना चाहिए, यानी डिवाइस के एवीबी संस्करण को लॉन्च करते समय।
3. ओटीए पैकेज का पुनर्निर्माण करें।

ये परिवर्तन स्वचालित रूप से BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE को निम्न फ़ाइलों में compatibility-matrix.avb.vbmeta-version रूप में रखते हैं:

• डिवाइस पर /system/compatibility_matrix.xml (जो Android 9 में उपयोग नहीं किया जाता है)
• ओटीए पैकेज में system_matrix.xml में compatibility.zip

ये परिवर्तन /system/etc/vintf/compatibility_matrix.xml सहित अन्य फ्रेमवर्क संगतता मैट्रिक्स को प्रभावित नहीं करते हैं। ओटीए के बाद, /system/etc/vintf/compatibility_matrix.xml में नया मान इसके बजाय संगतता जांच के लिए उपयोग किया जाता है।

वीएनडीके संस्करण मेल खाता है

डिवाइस संगतता मैट्रिक्स compatibility-matrix.vendor-ndk.version में आवश्यक VNDK संस्करण की घोषणा करता है। यदि डिवाइस संगतता मैट्रिक्स में <vendor-ndk> टैग नहीं है, तो कोई आवश्यकता नहीं लगाई जाती है, और इसलिए इसे हमेशा एक मैच माना जाता है।

यदि डिवाइस संगतता मैट्रिक्स में एक <vendor-ndk> टैग है, तो एक मिलान <version> के साथ एक <vendor-ndk> प्रविष्टि को वीएनडीके विक्रेता स्नैपशॉट के सेट से देखा जाता है जो फ्रेमवर्क मैनिफेस्ट में ढांचे द्वारा प्रदान किया जाता है। यदि ऐसी प्रविष्टि मौजूद नहीं है, तो कोई मेल नहीं है।

यदि ऐसी प्रविष्टि मौजूद है, तो डिवाइस संगतता मैट्रिक्स में सूचीबद्ध पुस्तकालयों का सेट फ्रेमवर्क मेनिफेस्ट में वर्णित पुस्तकालयों के सेट का सबसेट होना चाहिए; अन्यथा, प्रविष्टि को मिलान नहीं माना जाता है।

• एक विशेष मामले के रूप में, यदि डिवाइस संगतता मैट्रिक्स में कोई पुस्तकालय नहीं है, तो प्रविष्टि को हमेशा एक मैच माना जाता है, क्योंकि खाली सेट किसी भी सेट का सबसेट है।

उदाहरण: सफल VNDK संस्करण मिलान

यदि डिवाइस संगतता मैट्रिक्स VNDK पर निम्न आवश्यकता बताता है:

<!-- Example Device Compatibility Matrix -->
<vendor-ndk>
    <version>27</version>
    <library>libjpeg.so</library>
    <library>libbase.so</library>
</vendor-ndk>

फ्रेमवर्क मेनिफेस्ट में, केवल 27 संस्करण वाली प्रविष्टि पर विचार किया जाता है।

<!-- Framework Manifest Example A -->
<vendor-ndk>
    <version>27</version>
    <library>libjpeg.so</library>
    <library>libbase.so</library>
    <library>libfoo.so</library>
</vendor-ndk>

उदाहरण ए एक मैच है, क्योंकि वीएनडीके संस्करण 27 फ्रेमवर्क मेनिफेस्ट में है, और {libjpeg.so, libbase.so, libfoo.so} ⊇ {libjpeg.so, libbase.so} ।

<!-- Framework Manifest Example B -->
<vendor-ndk>
    <version>26</version>
    <library>libjpeg.so</library>
    <library>libbase.so</library>
</vendor-ndk>
<vendor-ndk>
    <version>27</version>
    <library>libbase.so</library>
</vendor-ndk>

उदाहरण बी एक मैच नहीं है। भले ही VNDK संस्करण 27 फ्रेमवर्क मेनिफेस्ट में है, libjpeg.so उस स्नैपशॉट में फ्रेमवर्क द्वारा समर्थित नहीं है। वीएनडीके संस्करण 26 को नजरअंदाज कर दिया गया है।

सिस्टम एसडीके संस्करण मेल खाता है

युक्ति संगतता मैट्रिक्स compatibility-matrix.system-sdk.version में आवश्यक सिस्टम SDK संस्करण का एक सेट घोषित करता है। एक मैच केवल तभी होता है जब सेट प्रदान किए गए सिस्टम एसडीके संस्करणों का एक सबसेट है जैसा कि फ्रेमवर्क मेनिफेस्ट में manifest.system-sdk.version में घोषित किया गया है।

• एक विशेष मामले के रूप में, यदि डिवाइस संगतता मैट्रिक्स में कोई सिस्टम एसडीके संस्करण नहीं है, तो इसे हमेशा एक मैच माना जाता है, क्योंकि खाली सेट किसी भी सेट का सबसेट है।

उदाहरण: सफल सिस्टम एसडीके संस्करण मिलान

यदि डिवाइस संगतता मैट्रिक्स सिस्टम एसडीके पर निम्नलिखित आवश्यकता बताता है:

<!-- Example Device Compatibility Matrix -->
<system-sdk>
    <version>26</version>
    <version>27</version>
</system-sdk>

फिर, ढांचे को मिलान के लिए सिस्टम एसडीके संस्करण 26 और 27 प्रदान करना होगा।

<!-- Framework Manifest Example A -->
<system-sdk>
    <version>26</version>
    <version>27</version>
</system-sdk>

उदाहरण ए एक मैच है।

<!-- Framework Manifest Example B -->
<system-sdk>
    <version>26</version>
    <version>27</version>
    <version>28</version>
</system-sdk>

उदाहरण बी एक मैच है।

<!-- Framework Manifest Example C -->
<system-sdk>
    <version>26</version>
</system-sdk>

उदाहरण सी एक मेल नहीं है, क्योंकि सिस्टम एसडीके संस्करण 27 प्रदान नहीं किया गया है।