मिलान नियम

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

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

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

फ़्रेमवर्क के साथ काम करने वाले मैट्रिक्स वर्शन के मैच

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

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

एचएएल मैच

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

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

एचआईडीएल और नेटिव एचएएल के लिए, मैच करने के नियम इस तरह हैं:

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

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

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

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

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

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

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

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

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

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

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

<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 कर्नेल के लिए फ़्रेमवर्क की ज़रूरी शर्तों के बारे में बताया गया है. इस जानकारी को, डिवाइस के VINTF ऑब्जेक्ट से मिली, कर्नेल के बारे में जानकारी से मैच किया जाता है.

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

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

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

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

VTS की जांचों से यह पक्का किया जाता है कि अगर kernel FCM वर्शन दिया गया है, तो kernel 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 के लिए कर्नेल की शाखा तय करना

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

5.4.42-android12-0-00544-ged21d463f856

इसके बाद, VINTF ऑब्जेक्ट, Android रिलीज़ को कर्नेल रिलीज़ से पाता है और इसका इस्तेमाल करके, कर्नेल FCM वर्शन का पता लगाता है. इस उदाहरण में, android12 का मतलब है कि kernel 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 में मौजूद एफ़सीएम, इन ज़रूरी शर्तों का एलान करते हैं (हेडर और फ़ुटर टैग हटा दिए गए हैं):

<!-- 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 कॉन्फ़िगरेशन का मिलान करना

अगर <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.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 वर्शन को इनमें से किसी एक रेंज में होना चाहिए. मैच करने के नियम, HAL वर्शन से मिलते-जुलते होते हैं. अगर 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 वर्शन है.

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

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

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

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