मिलते-जुलते नियम

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

यह पुष्टि, बिल्ड टाइम के दौरान की जाती है. इसे OTA पर अपडेट किया जाता है पैकेज जनरेट होने का समय, बूट के समय, और वीटीएस के साथ काम करने की जांच में शामिल हैं.

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

फ़्रेमवर्क कंपैटबिलिटी मैट्रिक्स वर्शन से मैच करता है

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

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

एचएएल के मैच

एचएएल-मैच नियम, सर्च इंजन में hal एलिमेंट के वर्शन की पहचान करता है ऐसी मेनिफ़ेस्ट फ़ाइल जिसे कंपैटबिलिटी मैट्रिक्स.

HIDL और नेटिव एचएएल

HIDL और नेटिव एचएएल के लिए मैच करने के नियम यहां दिए गए हैं.

• कई <hal> एलिमेंट का आकलन एक ही AND से किया जाता है संबंध.
• <hal> एलिमेंट के पास <hal optional="true"> एलिमेंट हो सकता है, ताकि उसे इस तौर पर मार्क किया जा सके ज़रूरी नहीं है.
• एक ही में कई <version> एलिमेंट <hal> के पास OR संबंध. अगर दो या दो से ज़्यादा के बारे में बताया गया है, तो सिर्फ़ इनमें से किसी एक वर्शन को लागू किया जाना चाहिए. (नीचे दिया गया डीआरएम का उदाहरण देखें.)
• एक से ज़्यादा <instance> और एक जैसे <regex-instance> एलिमेंट <hal> का आकलन किसी एक AND संबंध से किया जाता है, जब <hal> आवश्यक है. (यहां दिया गया <ahref="#drm">DRM का उदाहरण देखें.)</ahref="#drm">

उदाहरण: मॉड्यूल के लिए एचएएल मैच सही तरीके से सेट अप हो गया

वर्शन 2.5 में मौजूद HAL के लिए, मिलते-जुलते वीडियो का नियम इस तरह है:

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

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

फ़्रेमवर्क कंपैटबिलिटी मैट्रिक्स से वर्शन की यह जानकारी मिलती है डीआरएम एचएएल के लिए:

<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

अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है या फिर

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

AND, इन सभी मामलों को भी लागू किया जाना चाहिए:

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> एलिमेंट का आकलन एक ही AND से किया जाता है संबंध.
• <hal> एलिमेंट के पास <hal optional="true"> एलिमेंट हो सकता है, ताकि उसे इस तौर पर मार्क किया जा सके ज़रूरी नहीं है.
• एक से ज़्यादा <instance> और एक जैसे <regex-instance> एलिमेंट <hal> का आकलन किसी एक AND संबंध से किया जाता है, जब <hal> आवश्यक है. (यहां दिया गया <ahref="#vibrator">वाइब्रेटर का उदाहरण देखें.)</ahref="#vibrator">

उदाहरण: मॉड्यूल के लिए एचएएल मैच सही तरीके से सेट अप हो गया

वर्शन 5 में मौजूद HAL के लिए, मिलते-जुलते वीडियो से जुड़ा नियम यह है:

मैट्रिक्स	मिलता-जुलता मेनिफ़ेस्ट
5	5-∞. साथ काम करने वाले मैट्रिक्स में, 5 इसका शॉर्टहैंड है 5-5.
5-7	5-∞. इससे यह पता चलता है: अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है वर्शन 5 होना ज़रूरी है. इसका मतलब है कि ऐसा मेनिफ़ेस्ट जिसमें एचएएल की सुविधा हो 1-4 का इस्तेमाल नहीं किया जा सकता. अनुरोध किए जा सकने वाले ज़्यादा से ज़्यादा वर्शन 7 का मतलब है कि साथ काम करने वाला मैट्रिक्स (फ़्रेमवर्क या डिवाइस), वर्शन के लिए अनुरोध नहीं करेगा सात से ज़्यादा. मेल खाने वाले मेनिफ़ेस्ट के मालिक के पास अब भी वर्शन 10 चलाने का विकल्प है (उदाहरण के लिए) जब 7 का अनुरोध किया गया हो. कंपैटबिलिटी-मैट्रिक्स के मालिक को पता है यह ज़रूरी है कि अनुरोध की गई सेवा, एपीआई वर्शन 7 के साथ काम करती हो. -7 सिर्फ़ जानकारी देने के लिए है. इसका ओटीए अपडेट की प्रोसेस पर कोई असर नहीं पड़ता. इसलिए, मेनिफ़ेस्ट फ़ाइल में HAL वाले वर्शन 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> सेक्शन डिवाइस पर Linux कर्नेल के लिए फ़्रेमवर्क की ज़रूरी शर्तों के बारे में बताता है. यह जानकारी का मिलान जानकारी डिवाइस के VINTF ऑब्जेक्ट से रिपोर्ट किए जाने वाले कर्नेल के बारे में जानकारी.

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

हर कर्नेल ब्रांच सफ़िक्स (उदाहरण के लिए, 5.4-r) को एक यूनीक वैल्यू से मैप किया जाता है कर्नेल FCM वर्शन (उदाहरण के लिए, 5). मैपिंग और रिलीज़ लेटर के बीच की मैपिंग एक ही होती है (उदाहरण के लिए, R) और FCM वर्शन (उदाहरण के लिए, 5).

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

• कर्नेल FCM वर्शन, टारगेट FCM वर्शन से अलग होता है. उदाहरण के लिए, ऊपर दिए गए डिवाइस का टारगेट FCM वर्शन 4 है और इसका कर्नेल FCM वर्शन 5 (कर्नेल) है ब्रांच सफ़िक्स r).
• कर्नेल FCM वर्शन 5 (कर्नेल ब्रांच सफ़िक्स r) से बड़ा या उसके बराबर है.

ध्यान दें: अगर कर्नेल FCM वर्शन, टारगेट FCM वर्शन के बराबर है और वे 5 से ज़्यादा या उसके बराबर हैं, DEVICE_MANIFEST_FILE के ज़रिए तय की गई डिवाइस मेनिफ़ेस्ट की सोर्स फ़ाइल में ऐसा नहीं है कर्नेल FCM वर्शन तय करने के लिए. assemble_vintf अपने-आप अगर टारगेट FCM वर्शन इससे बड़ा या उसके बराबर है, तो टारगेट FCM वर्शन से कर्नेल FCM वर्शन 5.

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

उदाहरण: कर्नेल ब्रांच पता करना

अगर डिवाइस पर, 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 में दी गई है. ये ज़रूरी शर्तें, kernel/configs/r/android-4.19 में आपका डेटा दिखता है.

उदाहरण: जीकेआई के लिए कर्नेल ब्रांच पता करना

अगर डिवाइस जेनेरिक कर्नेल इमेज (जीकेआई) और कर्नेल रिलीज़ स्ट्रिंग का इस्तेमाल करता है, /proc/version यह है:

5.4.42-android12-0-00544-ged21d463f856

इसके बाद, VINTF ऑब्जेक्ट, कर्नेल रिलीज़ से Android रिलीज़ लेता है और उसका इस्तेमाल यह पता लगाने के लिए करता है कि कर्नेल FCM वर्शन के हिसाब से. इस उदाहरण में, android12 का मतलब है, kernel FCM वर्शन 6 (Android 12 में रिलीज़ किया गया).

कर्नेल रिलीज़ स्ट्रिंग को पार्स करने के तरीके के बारे में जानकारी के लिए, देखें जीकेआई वर्शन.

kernel वर्शन का मिलान करें

किसी मैट्रिक्स में कई <kernel> सेक्शन शामिल हो सकते हैं. हर सेक्शन में इस फ़ॉर्मैट का इस्तेमाल करके, एक अलग version एट्रिब्यूट का इस्तेमाल करें:

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

VINTF ऑब्जेक्ट,<kernel> उसी FCM वर्शन वाला FCM वर्शन डिवाइस कर्नेल के तौर पर ${ver} और ${major_rev} (जैसे, version="${ver}.${major_rev}.${matrix_minor_rev}"); अन्य सेक्शन नज़रअंदाज़ किए जाते हैं. इसके अलावा, कर्नेल से छोटा संशोधन एक मान होना चाहिए कम्पैटिबिलिटी मैट्रिक्स (${kernel_minor_rev} >= ${matrix_minor_rev};) से लिया गया है. अगर <kernel> सेक्शन मेल न खाता हो ये आवश्यकताएं मेल नहीं खातीं.

उदाहरण: मैच करने के लिए ज़रूरी शर्तें चुनें

नीचे दिए गए काल्पनिक मामले पर विचार करें जहां /system/etc/vintf में FCM ये शर्तें पूरी करनी होंगी (हेडर और फ़ुटर टैग शामिल नहीं किए गए हैं):

<!-- 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 की ज़रूरी शर्तें:

FCM वर्शन को टारगेट करें	Kernel 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 (R)	4.14.105	4.14-r
4 (क्यू)	5 (R)	5.4.41	5.4-r
5 (R)	बताया नहीं गया	कोई	वीटीएस काम नहीं करता (टारगेट FCM वर्शन 5 के लिए कर्नेल FCM वर्शन तय करना ज़रूरी है)
5 (R)	4 (क्यू)	कोई	VTS विफल (कर्नेल FCM वर्शन < टारगेट FCM वर्शन)
5 (R)	5 (R)	4.14.180	4.14-r

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

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

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

कर्नेल ब्रांच का मिलान पहले किया जाता है. 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> सेक्शन चुनने के बाद, n के अलावा किसी भी अन्य मूल्य वाले प्रत्येक <config> आइटम के लिए, हम /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

एसई नीति का मिलान हुआ

एसई नीति के मुताबिक ये मैच होने चाहिए:

• <sepolicy-version>, नाबालिग की सीमित रेंज के बारे में बताता है हर मेजर वर्शन के लिए अलग-अलग वर्शन हैं. डिवाइस से, नीति का जो वर्शन रिपोर्ट किया गया है फ़्रेमवर्क के साथ काम करने के लिए, ज़रूरी है कि दस्तावेज़ इनमें से किसी एक रेंज के दायरे में हो. मिलता-जुलता नियम, एचएएल वर्शन जैसे होते हैं; यह तब मैच होगा, जब सेनीति का वर्शन तय की गई सीमा के लिए, कम से कम वर्शन से ज़्यादा या उसके बराबर होना चाहिए. ज़्यादा से ज़्यादा वर्शन यह है सिर्फ़ जानकारी देने के लिए.
• <kernel-sepolicy-version> यानी कि policydb वर्शन. ज़रूर डिवाइस से रिपोर्ट किए गए security_policyvers() से कम होनी चाहिए.

उदाहरण: एसई नीति का मिलान हो गया

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

<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 है, तो उसे मैच माना जाता है.
• एसई नीति का वर्शन 25.0-∞ या 26.0-∞ में से कोई एक होना चाहिए. नहीं तो यह मिलान. ("26.0" के बाद "-3" पूरी तरह से जानकारी.)

एवीबी वर्शन मैच हो रहा है

AVB वर्शन में, इस फ़ॉर्मैट के साथ एक MAJOR वर्शन और MINOR वर्शन शामिल होता है MAJOR.MINOR के तौर पर (जैसे, 1.0, 2.1). जानकारी के लिए, इसे देखें वर्शन और साथ में काम करता है. एवीबी वर्शन में ये सिस्टम प्रॉपर्टी होती हैं:

• ro.boot.vbmeta.avb_version, libavb वर्शन है बूटलोडर में
• ro.boot.avb_version, इस देश में libavb वर्शन है Android OS (init/fs_mgr)

सिस्टम प्रॉपर्टी सिर्फ़ तब दिखती है, जब संबंधित libavb का इस्तेमाल किया गया हो का इस्तेमाल करें. पुष्टि नहीं होने पर यह मौजूद नहीं है (या कोई पुष्टि नहीं हुई है).

कंपैटबिलिटी मैच की सुविधा, इनकी तुलना करती है:

• sysprop ro.boot.vbmeta.avb_version को फ़्रेमवर्क कंपैटबिलिटी मैट्रिक्स से avb.vbmeta-version;
  • ro.boot.vbmeta.avb_version.MAJOR == avb.vbmeta-version.MAJOR
  • ro.boot.vbmeta.avb_version.MINOR >= avb.vbmeta-version.MINOR
• sysprop ro.boot.avb_version को फ़्रेमवर्क कंपैटबिलिटी मैट्रिक्स से avb.vbmeta-version.
  • ro.boot.avb_version.MAJOR == avb.vbmeta-version.MAJOR
  • ro.boot.avb_version.MINOR >= avb.vbmeta-version.MINOR

बूटलोडर या Android OS में libavb की दो कॉपी हो सकती हैं लाइब्रेरी, जिसमें हर डिवाइस के लिए एक अलग MAJOR वर्शन होता है. इसकी मदद से, डिवाइसों को अपग्रेड और लॉन्च किया जा सकता है डिवाइस. इस मामले में, बिना हस्ताक्षर वाली सिस्टम इमेज को शेयर किया जा सकता है, लेकिन अंतिम हस्ताक्षरित सिस्टम इमेज अलग हैं (अलग avb.vbmeta-version):

पहला डायग्राम. एवीबी वर्शन मैच करता है (/सिस्टम P है, बाकी सभी पार्टिशन O हैं).

दूसरा डायग्राम. एवीबी वर्शन मैच करता है (सभी पार्टिशन P हैं).

उदाहरण: एवीबी वर्शन मैच हो गया

फ़्रेमवर्क कंपैटबिलिटी मैट्रिक्स से एवीबी की यह जानकारी मिलती है:

<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.

Android 9 या इससे पहले के वर्शन वाले डिवाइसों पर अपडेट करते समय Android 10, AVB फ़्रेमवर्क के साथ काम करने वाले मैट्रिक्स में, वर्शन की ज़रूरी शर्तों को मौजूदा एवीबी से मैच किया जाता है एक वर्शन है. अगर ओटीए के दौरान, एवीबी वर्शन का मेजर वर्शन अपग्रेड है, तो वर्शन 0.0 से 1.0 तक है, तो VINTF यह जांच करता है कि ओटीए में काम करता है या नहीं. साथ ही, यह भी पता नहीं चलता कि बाद में OTA को देखें.

इस समस्या को कम करने के लिए, OEM, ओटीए पैकेज में नकली एवीबी वर्शन डाल सकता है जांच में पास होने के लिए, (compatibility.zip) दबाएं. ऐसा करने के लिए:

1. 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 में नहीं किया जाता)
• ओटीए पैकेज में, compatibility.zip में system_matrix.xml

इन बदलावों का असर, फ़्रेमवर्क के साथ काम करने वाले अन्य मैट्रिक्स पर नहीं पड़ता है. इनमें ये शामिल हैं /system/etc/vintf/compatibility_matrix.xml. OTA के बाद, नई वैल्यू इसके बजाय, /system/etc/vintf/compatibility_matrix.xml का इस्तेमाल यह जांच करने के लिए किया जाता है कि यह सुविधा काम करती है या नहीं.

VNDK वर्शन से मैच करता है

डिवाइस के साथ काम करने वाला मैट्रिक्स, ज़रूरी VNDK वर्शन के बारे में बताता है compatibility-matrix.vendor-ndk.version. अगर डिवाइस कंपैटबिलिटी मैट्रिक्स में <vendor-ndk> टैग नहीं है, नहीं शर्तें लागू होती हैं और इसलिए इसे हमेशा मिलान माना जाता है.

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

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

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

उदाहरण: सफल 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>

उदाहरण A एक मैच है, क्योंकि VNDK वर्शन 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>

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

सिस्टम SDK टूल के वर्शन का मिलान

डिवाइस के साथ काम करने वाला मैट्रिक्स, ज़रूरी सिस्टम SDK टूल के सेट के बारे में बताता है compatibility-matrix.system-sdk.version में वर्शन है. कई सिर्फ़ तब मैच करे, जब सेट, सिस्टम SDK टूल के दिए गए वर्शन का सबसेट हो फ़्रेमवर्क मेनिफ़ेस्ट में manifest.system-sdk.version में.

• खास तौर पर, अगर डिवाइस में सिस्टम SDK टूल के किसी भी वर्शन की गिनती नहीं की जाती है कंपैटबिलिटी मैट्रिक्स, इसे हमेशा मिलान माना जाता है, क्योंकि खाली है सेट, किसी सेट का सबसेट होता है.

उदाहरण: सिस्टम SDK टूल के चुने गए वर्शन का मैच हुआ

अगर डिवाइस के साथ काम करने वाला मैट्रिक्स, सिस्टम पर यह ज़रूरी शर्त बताता है SDK टूल:

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

इसके बाद, फ़्रेमवर्क में सिस्टम SDK टूल का वर्शन 26 और 27 उपलब्ध होना चाहिए, ताकि वह मैच कर सके.

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

उदाहरण A एक मैच है.

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

उदाहरण B, मैच होता है.

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

उदाहरण C मेल नहीं खाता है, क्योंकि सिस्टम SDK वर्शन 27 उपलब्ध नहीं कराया गया है.