मिलान नियम

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

यह सत्यापन बिल्ड समय पर, ओटीए अपडेट पैकेज जेनरेशन समय पर, बूट समय पर और वीटीएस संगतता परीक्षणों में किया जाता है।

निम्नलिखित अनुभाग विभिन्न घटकों द्वारा प्रयुक्त मिलान नियमों का विवरण देते हैं।

फ़्रेमवर्क संगतता मैट्रिक्स संस्करण मेल खाता है

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

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

एचएएल से मेल खाता है

एचएएल-मैच नियम एक मेनिफेस्ट फ़ाइल में hal तत्वों के संस्करणों की पहचान करता है जिन्हें संबंधित संगतता मैट्रिक्स के मालिक द्वारा समर्थित माना जाता है।

एचआईडीएल और देशी एचएएल

एचआईडीएल और देशी एचएएल के लिए मिलान नियम इस प्रकार हैं।

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

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

संस्करण 2.5 पर एचएएल के लिए, मिलान नियम इस प्रकार है:

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

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

फ़्रेमवर्क संगतता मैट्रिक्स 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 11 के बाद के सभी Android संस्करण (Android 11 को छोड़कर) VINTF में AIDL HALs के संस्करणों का समर्थन करते हैं। एआईडीएल एचएएल के लिए मिलान नियम एचआईडीएल और मूल एचएएल के समान हैं, सिवाय इसके कि कोई प्रमुख संस्करण नहीं है, और प्रति एचएएल उदाहरण में बिल्कुल एक संस्करण है (यदि संस्करण अनिर्दिष्ट है तो 1 )।

  • एकाधिक <hal> तत्वों का मूल्यांकन एकल AND संबंध के साथ किया जाता है।
  • <hal> तत्वों में उन्हें आवश्यक नहीं के रूप में चिह्नित करने के लिए <hal optional="true"> हो सकता है।
  • <hal> की आवश्यकता होने पर एक ही <hal> के भीतर एकाधिक <instance> और <regex-instance> तत्वों का मूल्यांकन एकल AND संबंध के साथ किया जाता है। (देखें वाइब्रेटर उदाहरण नीचे।)

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

संस्करण 5 में एचएएल के लिए, मिलान नियम इस प्रकार है:

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

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

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

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

  • कर्नेल FCM संस्करण लक्ष्य FCM संस्करण से भिन्न है। उदाहरण के लिए, उपरोक्त डिवाइस का लक्ष्य FCM संस्करण 4 है, और इसका कर्नेल FCM संस्करण 5 (कर्नेल शाखा प्रत्यय r ) है।
  • कर्नेल FCM संस्करण 5 (कर्नेल शाखा प्रत्यय r ) से बड़ा या उसके बराबर है।

वीटीएस परीक्षण लागू करते हैं कि, यदि कर्नेल एफसीएम संस्करण निर्दिष्ट किया गया है, तो कर्नेल एफसीएम संस्करण डिवाइस मैनिफ़ेस्ट में लक्ष्य एफसीएम संस्करण से बड़ा या उसके बराबर है।

उदाहरण: कर्नेल शाखा निर्धारित करें

यदि डिवाइस में लक्ष्य FCM संस्करण 4 (एंड्रॉइड 10 में जारी) है, लेकिन 4.19-r शाखा से कर्नेल चलाता है, तो डिवाइस मेनिफेस्ट को निम्नलिखित निर्दिष्ट करना चाहिए:

<manifest version="2.0" type="device" target-level="4">
   <kernel target-level="5" />
</manifest>

VINTF ऑब्जेक्ट 4.19-r कर्नेल शाखा पर आवश्यकताओं के विरुद्ध कर्नेल संगतता की जांच करता है, जो एफसीएम संस्करण 5 में निर्दिष्ट है। ये आवश्यकताएं एंड्रॉइड स्रोत ट्री में kernel/configs/r/android-4.19 से बनाई गई हैं।

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

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

5.4.42-android12-0-00544-ged21d463f856

फिर, VINTF ऑब्जेक्ट कर्नेल रिलीज़ से एंड्रॉइड रिलीज़ प्राप्त करता है, और कर्नेल 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 संस्करण और कर्नेल संस्करण मिलकर FCMs से कर्नेल आवश्यकताओं का चयन करते हैं:

लक्ष्य FCM संस्करण कर्नेल एफसीएम संस्करण कर्नेल संस्करण के साथ मेल
3 (पी) अनिर्दिष्ट 4.4.106 कोई मिलान नहीं (मामूली संस्करण बेमेल)
3 (पी) अनिर्दिष्ट 4.4.107 4.4-p
3 (पी) अनिर्दिष्ट 4.19.42 4.19-q (नीचे नोट देखें)
3 (पी) अनिर्दिष्ट 5.4.41 5.4-r (नीचे नोट देखें)
3 (पी) 3 (पी) 4.4.107 4.4-p
3 (पी) 3 (पी) 4.19.42 कोई मेल नहीं (कोई 4.19-p कर्नेल शाखा नहीं)
3 (पी) 4 (क्यू) 4.19.42 4.19-q
4 (क्यू) अनिर्दिष्ट 4.4.107 कोई मेल नहीं (कोई 4.4-q कर्नेल शाखा नहीं)
4 (क्यू) अनिर्दिष्ट 4.9.165 4.9-q
4 (क्यू) अनिर्दिष्ट 5.4.41 5.4-r (नीचे नोट देखें)
4 (क्यू) 4 (क्यू) 4.9.165 4.9-q
4 (क्यू) 4 (क्यू) 5.4.41 कोई मेल नहीं (कोई 5.4-q कर्नेल शाखा नहीं)
4 (क्यू) 5 (आर) 4.14.105 4.14-r
4 (क्यू) 5 (आर) 5.4.41 5.4-r
5 (आर) अनिर्दिष्ट कोई वीटीएस विफल (लक्ष्य एफसीएम संस्करण 5 के लिए कर्नेल एफसीएम संस्करण निर्दिष्ट करना होगा)
5 (आर) 4 (क्यू) कोई वीटीएस विफल (कर्नेल एफसीएम संस्करण <लक्ष्य एफसीएम संस्करण)
5 (आर) 5 (आर) 4.14.180 4.14-r

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

यदि <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 , या हेक्साडेसिमल समकक्ष से मेल खाता है।

उदाहरण: सफल कर्नेल मिलान

एफसीएम संस्करण 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-version> प्रत्येक प्रमुख संस्करण के लिए छोटे संस्करणों की एक बंद श्रेणी को परिभाषित करता है। डिवाइस द्वारा रिपोर्ट किया गया सेपॉलिसी संस्करण फ्रेमवर्क के साथ संगत होने के लिए इनमें से किसी एक सीमा के भीतर आना चाहिए। मिलान नियम एचएएल संस्करणों के समान हैं; यह एक मेल है यदि सेपॉलिसी संस्करण रेंज के लिए न्यूनतम संस्करण से अधिक या उसके बराबर है। अधिकतम संस्करण विशुद्ध रूप से सूचनात्मक है.
  • <kernel-sepolicy-version> यानी पॉलिसीडीबी संस्करण। डिवाइस द्वारा रिपोर्ट की गई security_policyvers() से कम होनी चाहिए।

उदाहरण: सफल एसई नीति मिलान

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

<sepolicy>
    <kernel-sepolicy-version>30</kernel-sepolicy-version>
    <sepolicy-version>25.0</sepolicy-version>
    <sepolicy-version>26.0-3</sepolicy-version>
</sepolicy>

उपकरण पर:

  • security_policyvers() द्वारा लौटाया गया मान 30 से अधिक या उसके बराबर होना चाहिए। अन्यथा यह मेल नहीं खाता है। उदाहरण के लिए:
    • यदि कोई डिवाइस 29 लौटाता है, तो यह मेल नहीं है।
    • यदि कोई डिवाइस 31 लौटाता है, तो यह एक मिलान है।
  • एसई नीति संस्करण 25.0-∞ या 26.0-∞ में से एक होना चाहिए। अन्यथा यह कोई मेल नहीं है. (" 26.0 " के बाद " -3 " विशुद्ध रूप से सूचनात्मक है।)

AVB संस्करण मेल खाता है

AVB संस्करण में एक प्रमुख संस्करण और लघु संस्करण शामिल है, जिसका प्रारूप 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

बूटलोडर या एंड्रॉइड ओएस में libavb लाइब्रेरीज़ की दो प्रतियां हो सकती हैं, जिनमें से प्रत्येक में अपग्रेड डिवाइस और लॉन्च डिवाइस के लिए एक अलग प्रमुख संस्करण होगा। इस मामले में, एक ही अहस्ताक्षरित सिस्टम छवि साझा की जा सकती है लेकिन अंतिम हस्ताक्षरित सिस्टम छवियां अलग-अलग हैं (अलग-अलग avb.vbmeta-version के साथ):

चित्र 1. AVB संस्करण मेल खाता है ( /system P है, अन्य सभी विभाजन O हैं)।


चित्र 2. AVB संस्करण मेल खाता है (सभी विभाजन 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 

ओटीए के दौरान एवीबी संस्करण का मिलान

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

समस्या को कम करने के लिए, एक OEM चेक पास करने के लिए OTA पैकेज ( compatibility.zip ) में एक नकली AVB संस्करण रख सकता है। ऐसा करने के लिए:

  1. चेरी-एंड्रॉइड 9 स्रोत ट्री के लिए निम्नलिखित सीएल चुनें:
  2. डिवाइस के लिए BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE परिभाषित करें। इसका मान OTA से पहले के 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 में नए मान का उपयोग संगतता जांच के लिए किया जाता है।

VNDK संस्करण मेल खाता है

डिवाइस संगतता मैट्रिक्स compatibility-matrix.vendor-ndk.version में आवश्यक VNDK संस्करण घोषित करता है। यदि डिवाइस संगतता मैट्रिक्स में <vendor-ndk> टैग नहीं है, तो कोई आवश्यकता नहीं लगाई जाती है, और इसलिए इसे हमेशा एक मिलान माना जाता है।

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

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

  • एक विशेष मामले के रूप में, यदि डिवाइस संगतता मैट्रिक्स में कोई पुस्तकालयों की गणना नहीं की जाती है, तो प्रविष्टि को हमेशा एक मिलान माना जाता है, क्योंकि खाली सेट किसी भी सेट का सबसेट है।

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

उदाहरण ए एक मेल है, क्योंकि वीएनडीके संस्करण 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 में आवश्यक सिस्टम एसडीके संस्करण का एक सेट घोषित करता है। कोई मिलान तभी होता है जब सेट फ्रेमवर्क मेनिफेस्ट में manifest.system-sdk.version में घोषित किए गए सिस्टम एसडीके संस्करणों का एक सबसेट हो।

  • एक विशेष मामले के रूप में, यदि डिवाइस संगतता मैट्रिक्स में कोई सिस्टम एसडीके संस्करण नहीं गिना जाता है, तो इसे हमेशा एक मिलान माना जाता है, क्योंकि खाली सेट किसी भी सेट का सबसेट होता है।

उदाहरण: सफल सिस्टम एसडीके संस्करण मिलान

यदि डिवाइस संगतता मैट्रिक्स सिस्टम एसडीके पर निम्नलिखित आवश्यकता बताता है:

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

उदाहरण बी एक मेल है.

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

उदाहरण सी मेल नहीं खाता, क्योंकि सिस्टम एसडीके संस्करण 27 प्रदान नहीं किया गया है।