मिलान नियम

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

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

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

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

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

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

HAL के मैच

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

HIDL और नेटिव HAL

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

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

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

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

मैट्रिक्स	मिलता-जुलता मेनिफ़ेस्ट
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 वर्शन दिखा सकता है. कंपैटबिलिटी-मैट्रिक्स के मालिक को सिर्फ़ यह पता है कि अनुरोध की गई सेवा, एपीआई के वर्शन 2.7 के साथ काम करती है. -7 सिर्फ़ जानकारी के लिए है और इससे ओटीए अपडेट की प्रोसेस पर कोई असर नहीं पड़ता. इसलिए, जिस डिवाइस की मेनिफ़ेस्ट फ़ाइल में HAL का वर्शन 2.10 है वह डिवाइस, ऐसे फ़्रेमवर्क के साथ काम करता रहेगा जिसके काम करने के मैट्रिक्स में 2.5-7 लिखा है.

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

फ़्रेमवर्क के साथ काम करने की जानकारी देने वाले मैट्रिक्स में, डीआरएम एचएएल के लिए वर्शन की यह जानकारी दी गई है:

<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

साथ ही, आपको इन सभी इंस्टेंस को भी लागू करना होगा:

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 11 को छोड़कर), VINTF में AIDL HALs के वर्शन के साथ काम करते हैं. AIDL HAL के लिए मैच करने से जुड़े नियम, HIDL और नेटिव HAL के जैसे होते हैं. हालांकि, इनका कोई मेजर वर्शन नहीं होता है. साथ ही, हर एचएएल इंस्टेंस के लिए सिर्फ़ एक वर्शन होता है (अगर वर्शन की जानकारी नहीं दी गई है, तो 1).

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

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

HAL के वर्शन 5 के लिए, मैच करने का नियम इस तरह है:

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

फ़्रेमवर्क के साथ काम करने वाले डिवाइसों के मैट्रिक्स के <kernel> सेक्शन में, डिवाइस पर Linux kernel के लिए फ़्रेमवर्क की ज़रूरी शर्तों के बारे में बताया गया है. इस जानकारी को, डिवाइस के VINTF ऑब्जेक्ट से मिली, कर्नेल के बारे में जानकारी से मैच किया जाता है.

कर्नेल की शाखाओं को मैच करना

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

VTS की जांचों से यह पक्का किया जाता है कि डिवाइस के मेनिफ़ेस्ट, /vendor/etc/vintf/manifest.xml में, डिवाइस के kernel FCM वर्शन के बारे में साफ़ तौर पर बताया गया हो. ऐसा तब ज़रूरी है, जब इनमें से कोई एक शर्त पूरी हो:

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

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

वीटीएस टेस्ट से यह बात लागू होती है कि अगर कर्नेल 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 kernel branch पर ज़रूरी शर्तों के हिसाब से, kernel के साथ काम करने की जांच करता है. इसकी जानकारी, FCM वर्शन 5 में दी गई है. ये ज़रूरी शर्तें, Android सोर्स ट्री में मौजूद kernel/configs/r/android-4.19 से बनाई गई हैं.

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

अगर डिवाइस में Generic Kernel Image (GKI) का इस्तेमाल किया जा रहा है और /proc/version में मौजूद कर्नेल रिलीज़ स्ट्रिंग यह है:

5.4.42-android12-0-00544-ged21d463f856

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

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

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

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

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

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

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

यहां एक उदाहरण दिया गया है. इसमें /system/etc/vintf में FCMs ने ये ज़रूरी शर्तें बताई हैं (हेडर और फ़ुटर टैग हटा दिए गए हैं):

<!-- 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 (P)	बताया नहीं गया	4.4.106	कोई मैच नहीं (मामूली वर्शन मेल नहीं खाता)
3 (पी)	बताया नहीं गया	4.4.107	4.4-p
3 (P)	बताया नहीं गया	4.19.42	4.19-q (नीचे दिया गया नोट देखें)
3 (P)	बताया नहीं गया	5.4.41	5.4-r (नीचे दिया गया नोट देखें)
3 (पी)	3 (पी)	4.4.107	4.4-p
3 (P)	3 (P)	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)	बताया नहीं गया	कोई	VTS काम नहीं करता (टारगेट FCM वर्शन 5 के लिए, कर्नेल FCM वर्शन की जानकारी देना ज़रूरी है)
5 (R)	4 (सवाल)	कोई	VTS की प्रोसेस पूरी नहीं हो पाती (kernel FCM version < target FCM version)
5 (R)	5 (R)	4.14.180	4.14-r

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

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

अगर <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 का इस्तेमाल किया जाता है. अगर डिवाइस मेनिफ़ेस्ट में मौजूद कर्नेल की शाखा:

• है, तो अगले चरण पर जाता है और कर्नेल वर्शन की जांच करता है.
• है, तो मैट्रिक से मैच नहीं होगा. 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

SE की नीति से जुड़े मैच

एसई की नीति के मुताबिक, इन चीज़ों का मेल होना ज़रूरी है:

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

एवीबी वर्शन के मैच

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

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

सिस्टम प्रॉपर्टी सिर्फ़ तब दिखती है, जब AVB मेटाडेटा की पुष्टि करने के लिए, संबंधित libavb का इस्तेमाल किया गया हो और वह 'ठीक है' दिखाता हो. अगर पुष्टि नहीं हो पाई है या पुष्टि की प्रोसेस पूरी नहीं हुई है, तो यह एट्रिब्यूट मौजूद नहीं होता.

काम करने की सुविधा के हिसाब से मैच करने के लिए, इन चीज़ों की तुलना की जाती है:

• फ़्रेमवर्क के कंपैटबिलिटी मैट्रिक्स से avb.vbmeta-version के साथ sysprop 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 के साथ sysprop ro.boot.avb_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 के साथ):

पहली इमेज. एवीबी वर्शन मैच करता है (/system 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 

ओटीए के दौरान AVB वर्शन मैच करना

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

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

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

1. Android 9 के सोर्स ट्री में, इन सीएल को चुनें:
   • CL 732261
   • CL 732262
2. डिवाइस के लिए BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE तय करें. इसकी वैल्यू, ओटीए से पहले के AVB वर्शन के बराबर होनी चाहिए. इसका मतलब है कि डिवाइस के लॉन्च होने के समय का AVB वर्शन.
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 भी शामिल हैं. ओटीए के बाद, /system/etc/vintf/compatibility_matrix.xml में मौजूद नई वैल्यू का इस्तेमाल, डिवाइस के साथ काम करने की जांच के लिए किया जाता है.

वीएनडीके वर्शन मैच

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

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

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

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

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

उदाहरण 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 का मिलान नहीं हो रहा है. फ़्रेमवर्क के मेनिफ़ेस्ट में VNDK का वर्शन 27 मौजूद है. हालांकि, उस स्नैपशॉट में फ़्रेमवर्क के साथ libjpeg.so काम नहीं करता. VNDK टूल के वर्शन 26 को अनदेखा किया जाता है.

सिस्टम का SDK टूल वर्शन मैच होना

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

• किसी खास मामले में, अगर डिवाइस के साथ काम करने की सुविधा वाले मैट्रिक्स में सिस्टम SDK टूल के किसी वर्शन की जानकारी नहीं दी गई है, तो इसे हमेशा मैच माना जाता है. ऐसा इसलिए होता है, क्योंकि खाली सेट किसी भी सेट का सबसेट होता है.

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

अगर डिवाइस के साथ काम करने की जानकारी देने वाले मैट्रिक में, System 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>

पहला उदाहरण मैच करता है.

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

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