मिलान नियम

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

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

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

फ़्रेमवर्क के साथ काम करने वाले मैट्रिक्स वर्शन मेल खाते हैं

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

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

एचएएल से मिलते-जुलते मैच

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

एचआईडीएल और नेटिव एचएएल

एचआईडीएल और नेटिव एचएएल के लिए, मैच करने के नियम यहां दिए गए हैं:

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

उदाहरण: किसी मॉड्यूल के लिए HAL मैच होने की स्थिति

वर्शन 2.5 वाले एचएएल के लिए, मैच करने का नियम यह है:

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

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

• एक से ज़्यादा <hal> एलिमेंट का आकलन, एक AND संबंध के आधार पर किया जाता है.
• <hal> एलिमेंट में <hal optional="true"> हो सकता है, ताकि उन्हें 'ज़रूरी नहीं' के तौर पर मार्क किया जा सके.
• जब <hal> की ज़रूरत होती है, तब एक ही <hal> में मौजूद कई <instance> और <regex-instance> एलिमेंट का आकलन, AND लॉजिक से किया जाता है. (एक से ज़्यादा मॉड्यूल के लिए एचएएल मैच होने की स्थिति देखें.)

उदाहरण: किसी मॉड्यूल के लिए HAL मैच होने की स्थिति

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

उदाहरण: एक से ज़्यादा मॉड्यूल के लिए, HAL से मैच होने की स्थिति

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

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

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

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

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

उदाहरण: 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} से मेल खाने वाले FCM वर्शन को मानता है. इसका मतलब है कि यह सिर्फ़ 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 से कर्नल की ज़रूरी शर्तें चुनते हैं:

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

अगर <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> का मतलब है कि config item, /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> सेक्शन चुनने के बाद, 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 से मिलते-जुलते मैच

SEPolicy के लिए, इन शर्तों का पूरा होना ज़रूरी है:

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

उदाहरण: SEPolicy से मैच होने की पुष्टि हो गई है

फ़्रेमवर्क कंपैटबिलिटी मैट्रिक्स में, SEPolicy के बारे में यह जानकारी दी गई है:

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

एवीबी वर्शन से मिलान

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

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

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

कंपैटिबिलिटी मैच में इनकी तुलना की जाती है:

• sysprop ro.boot.vbmeta.avb_version with avb.vbmeta-version from framework compatibility matrix:
  • 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 with avb.vbmeta-version from framework compatibility matrix:
  • 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 के साथ):

पहली इमेज. AVB वर्शन मैच करता है (/system P है और अन्य सभी पार्टिशन O हैं).

दूसरी इमेज. एवीबी वर्शन मैच (सभी पार्टीशन P हैं).

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

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

1. Android 9 के सोर्स ट्री में, इन सीएल को चेरी-पिक करें:
   • CL 732261
   • CL 732262
2. डिवाइस के लिए BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE तय करें. इसकी वैल्यू, ओटीए से पहले के AVB वर्शन के बराबर होनी चाहिए. इसका मतलब है कि डिवाइस लॉन्च होने के समय AVB का जो वर्शन था वही इसकी वैल्यू होनी चाहिए.
3. OTA पैकेज को फिर से बनाएं.

इन बदलावों से, BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE को इन फ़ाइलों में compatibility-matrix.avb.vbmeta-version के तौर पर अपने-आप सेट कर दिया जाता है:

• /system/compatibility_matrix.xml (जिसका इस्तेमाल Android 9 में नहीं किया जाता)
• OTA पैकेज में compatibility.zip में system_matrix.xml

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

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

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

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

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

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

उदाहरण: 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 उस स्नैपशॉट में फ़्रेमवर्क के साथ काम नहीं करता. वीएनडीके वर्शन 26 को अनदेखा किया जाता है.

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

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

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

उदाहरण: सिस्टम एसडीके टूल के वर्शन का मिलान हो गया

अगर डिवाइस के साथ काम करने की ज़रूरी शर्तों के मैट्रिक्स में, System SDK के लिए यह ज़रूरी शर्त दी गई है:

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

उदाहरण 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 मैच नहीं करता, क्योंकि सिस्टम एसडीके का वर्शन 27 उपलब्ध नहीं कराया गया है.