मिलान नियम

संग्रह की मदद से व्यवस्थित रहें अपनी प्राथमिकताओं के आधार पर, कॉन्टेंट को सेव करें और कैटगरी में बांटें.

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

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

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

फ़्रेमवर्क के साथ काम करने की सुविधा देने वाले मैट्रिक्स के वर्शन मैच करते हैं

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

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

एचएएल के मैच

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

HIDL और नेटिव HAL

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

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

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

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

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

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

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

उदाहरण: एक से ज़्यादा मॉड्यूल के लिए 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 मैच

फ़्रेमवर्क के साथ काम करने वाले डिवाइसों के मैट्रिक्स के <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).

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 के लिए कर्नेल की शाखा तय करना

अगर डिवाइस में Generic Kernel Image (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 ऑब्जेक्ट, डिवाइस के कर्नेल के ${ver} और ${major_rev} के हिसाब से, FCM के उस वर्शन के <kernel> सेक्शन को ही ध्यान में रखता है जो FCM के वर्शन से मैच करता है. उदाहरण के लिए, 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 से कर्नेल की ज़रूरी शर्तें चुनते हैं:

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

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

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

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 का इस्तेमाल किया गया हो और वह 'ठीक है' दिखाता हो. अगर पुष्टि नहीं हो पाई है या पुष्टि की प्रोसेस पूरी नहीं हुई है, तो यह एट्रिब्यूट मौजूद नहीं होता.

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

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