ম্যাচের নিয়ম

The two pairs of compatibility matrices and manifests are meant to be reconciled to verify that the framework and vendor implementation can work with each other. This verification is successful upon a match between the framework compatibility matrix and the device manifest, as well as between the framework manifest and the device compatibility matrix.

এই যাচাইকরণটি বিল্ড টাইমে, OTA আপডেট প্যাকেজ জেনারেশনের সময়ে, বুট করার সময় এবং VTS সামঞ্জস্যতা পরীক্ষায় করা হয়।

The following sections detail matching rules used by various components.

ফ্রেমওয়ার্ক সামঞ্জস্যতা ম্যাট্রিক্স সংস্করণ মেলে

একটি ফ্রেমওয়ার্ক সামঞ্জস্যতা ম্যাট্রিক্সের সাথে একটি ডিভাইস ম্যানিফেস্টকে মেলাতে, manifest.target-level দ্বারা নির্দিষ্ট করা Shipping FCM সংস্করণটি compatibility-matrix.level দ্বারা নির্দিষ্ট করা FCM সংস্করণের ঠিক সমান হতে হবে৷ নইলে মিল নেই।

যখন libvintf এর সাথে ফ্রেমওয়ার্ক কম্প্যাটিবিলিটি ম্যাট্রিক্সের অনুরোধ করা হয়, তখন এই ম্যাচটি সর্বদা সফল হয় কারণ libvintf ডিভাইস ম্যানিফেস্ট খোলে, শিপিং এফসিএম সংস্করণ পুনরুদ্ধার করে এবং সেই শিপিং এফসিএম সংস্করণে ফ্রেমওয়ার্ক সামঞ্জস্যতা ম্যাট্রিক্স ফেরত দেয় (এছাড়া উচ্চতর FCM-তে সামঞ্জস্যতা ম্যাট্রিক্স থেকে কিছু ঐচ্ছিক HALs) Versions).

HAL matches

The HAL-match rule identifies the versions of hal elements in a manifest file that are considered to be supported by the owner of the corresponding compatibility matrix.

HIDL and native HALs

এইচআইডিএল এবং নেটিভ এইচএএল-এর ম্যাচের নিয়ম নিম্নরূপ।

• Multiple <hal> elements are evaluated with a single AND relationship.
• <hal> elements can have <hal optional="true"> to mark them as not required.
• Multiple <version> elements within the same <hal> have the OR relationship. If two or more are specified, only one of the versions needs to be implemented. (See the DRM example below.)
• Multiple <instance> and <regex-instance> elements within the same <hal> are evaluated with a single AND relationship when the <hal> is required. (দেখুন নীচে DRM উদাহরণ।)

Example: Successful HAL match for a module

2.5 সংস্করণে HAL-এর জন্য, ম্যাচের নিয়ম নিম্নরূপ:

উদাহরণ: DRM মডিউলের জন্য সফল HAL ম্যাচ

The framework compatibility matrix states the following version information for 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>

A vendor must implement ONE of the following instances; হয়

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

AND must also implement all of these instances:

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

AIDL HALs

All Android versions later than Android 11 (excluding Android 11) supports versions for AIDL HALs in VINTF. এআইডিএল এইচএএল-এর ম্যাচের নিয়মগুলি এইচআইডিএল এবং নেটিভ এইচএএল-এর মতোই, ব্যতীত কোনও বড় সংস্করণ নেই, এবং প্রতি এইচএএল উদাহরণে ঠিক একটি সংস্করণ রয়েছে ( 1 সংস্করণ অনির্দিষ্ট থাকলে)।

• একাধিক <hal> উপাদান একটি একক এবং সম্পর্ক দিয়ে মূল্যায়ন করা হয়।
• <hal> উপাদানগুলির প্রয়োজন নেই হিসাবে চিহ্নিত করার জন্য <hal optional="true"> থাকতে পারে।
• একই <hal> এর মধ্যে একাধিক <instance> এবং <regex-instance> উপাদানগুলিকে একটি একক এবং সম্পর্ক দিয়ে মূল্যায়ন করা হয় যখন <hal> প্রয়োজন হয়। (দেখুন vibrator example below.)

উদাহরণ: একটি মডিউলের জন্য সফল HAL ম্যাচ

সংস্করণ 5-এ HAL-এর জন্য, ম্যাচের নিয়ম নিম্নরূপ:

Example: Successful HAL match for multiple modules

The framework compatibility matrix states the following version information for vibrator and camera HALs:

<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

কার্নেল মেলে

The <kernel> section of the framework compatibility matrix describes the framework's requirements of the Linux kernel on the device. This information is meant to be matched against the information about the kernel that gets reported by the device's VINTF object.

কার্নেল শাখা মেলান

Each kernel branch suffix (for example, 5.4- r ) is mapped to a unique kernel FCM version (for example, 5). The mapping is the same as the mapping between release letters (for example, R) and FCM versions (for example, 5).

VTS tests enforce that the device explicitly specifies the kernel FCM version in the device manifest, /vendor/etc/vintf/manifest.xml , if one of the following is true:

• কার্নেল FCM সংস্করণ লক্ষ্য FCM সংস্করণ থেকে ভিন্ন। উদাহরণস্বরূপ, উপরে উল্লিখিত ডিভাইসটির একটি লক্ষ্য FCM সংস্করণ 4 রয়েছে এবং এর কার্নেল FCM সংস্করণ 5 (কার্নেল শাখা প্রত্যয় r )।
• কার্নেল এফসিএম সংস্করণটি 5 (কার্নেল শাখা প্রত্যয় r ) এর চেয়ে বড় বা সমান।

VTS পরীক্ষাগুলি প্রয়োগ করে যে, যদি কার্নেল FCM সংস্করণ নির্দিষ্ট করা হয়, কার্নেল FCM সংস্করণটি ডিভাইস ম্যানিফেস্টে লক্ষ্য FCM সংস্করণের চেয়ে বড় বা সমান।

Example: Determine the kernel branch

যদি ডিভাইসটির লক্ষ্য 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 থেকে তৈরি করা হয়েছে।

Example: Determine the kernel branch for GKI

যদি ডিভাইসটি জেনেরিক কার্নেল ইমেজ (GKI) ব্যবহার করে এবং /proc/version থেকে কার্নেল রিলিজ স্ট্রিং নিম্নরূপ:

5.4.42-android12-0-00544-ged21d463f856

তারপর, VINTF অবজেক্টটি কার্নেল রিলিজ থেকে অ্যান্ড্রয়েড রিলিজ পায়, এবং কার্নেল FCM সংস্করণ নির্ধারণ করতে এটি ব্যবহার করে। এই উদাহরণে, android12 মানে কার্নেল FCM সংস্করণ 6 (Android 12 এ প্রকাশিত)।

For details on how the kernel release string is parsed, see GKI versioning .

Match kernel versions

একটি ম্যাট্রিক্সে একাধিক <kernel> বিভাগ অন্তর্ভুক্ত থাকতে পারে, প্রত্যেকটি বিন্যাস ব্যবহার করে একটি ভিন্ন version বৈশিষ্ট্য সহ:

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

The VINTF object considers only the <kernel> section from the FCM with matching FCM version with the same ${ver} and ${major_rev} as the device kernel (ie, version="${ver}.${major_rev}.${matrix_minor_rev}") ; other sections are ignored. উপরন্তু, কার্নেল থেকে ছোটখাট সংশোধন অবশ্যই সামঞ্জস্য ম্যাট্রিক্স থেকে একটি মান হতে হবে ( ${kernel_minor_rev} >= ${matrix_minor_rev} ;)। যদি কোন <kernel> বিভাগ এই প্রয়োজনীয়তাগুলি পূরণ না করে, এটি একটি অ-ম্যাচ।

Example: Select requirements for matching

নিম্নলিখিত অনুমানমূলক ক্ষেত্রে বিবেচনা করুন যেখানে /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 -->

The target FCM version, the kernel FCM version, and the kernel version together select the kernel requirements from the FCMs:

Match kernel configurations

<kernel> বিভাগটি মিললে, /proc/config.gz এর সাথে config উপাদানগুলিকে মেলানোর চেষ্টা করে প্রক্রিয়াটি চলতে থাকে। সামঞ্জস্যতা ম্যাট্রিক্সের প্রতিটি কনফিগার উপাদানের জন্য, কনফিগার উপস্থিত আছে কিনা তা দেখতে এটি /proc/config.gz দেখায়। ম্যাচিং <kernel> বিভাগের জন্য সামঞ্জস্যপূর্ণ ম্যাট্রিক্সে একটি কনফিগার আইটেম n এ সেট করা হলে, এটি অবশ্যই /proc/config.gz থেকে অনুপস্থিত থাকবে। অবশেষে, সামঞ্জস্য ম্যাট্রিক্সে না থাকা একটি কনফিগার আইটেম /proc/config.gz এ উপস্থিত থাকতে পারে বা নাও থাকতে পারে।

Example: Match kernel configurations

• <value type="string">bar</value> matches "bar" . Quotes are omitted in the compatibility matrix but present in /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> matches y .
• <value type="tristate">m</value> m সাথে মেলে।
• <value type="tristate">n</value> means the config item must NOT exist in /proc/config.gz .
• <value type="range">1-0x3</value> matches 1 , 2 , or 3 , or hexadecimal equivalent.

উদাহরণ: সফল কার্নেল মিল

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 (no match to matrix unless there's a separate kernel section with <kernel version="4.1.x"> where x <= 22 )

After the appropriate <kernel> section is selected, for each <config> item with value other than n , we expect the corresponding entry to be present in /proc/config.gz ; for each <config> item with value n , we expect the corresponding entry to not be present in /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> defines a closed range of minor versions for every major version. The sepolicy version reported by the device must fall within one of these ranges to be compatible with the framework. ম্যাচের নিয়মগুলি HAL সংস্করণের অনুরূপ; এটি একটি মিল যদি সেপলিসি সংস্করণটি পরিসরের ন্যূনতম সংস্করণের উচ্চতর বা সমান হয়। The maximum version is purely informational.
• <kernel-sepolicy-version> ie policydb version. ডিভাইস দ্বারা রিপোর্ট করা security_policyvers() থেকে কম হতে হবে।

Example: Successful SE policy match

ফ্রেমওয়ার্ক সামঞ্জস্যতা ম্যাট্রিক্স নিম্নলিখিত সেপলিসি তথ্য জানায়:

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

On the device:

• security_policyvers() দ্বারা প্রত্যাবর্তিত মান অবশ্যই 30 এর বেশি বা সমান হতে হবে। অন্যথায় এটি একটি মিল নয়। যেমন:
  • যদি একটি ডিভাইস 29 রিটার্ন করে, এটি একটি মিল নয়।
  • যদি একটি ডিভাইস 31 রিটার্ন করে, এটি একটি ম্যাচ।
• SE নীতি সংস্করণ অবশ্যই 25.0-∞ বা 26.0-∞-এর একটি হতে হবে৷ অন্যথায় এটি একটি ম্যাচ নয়। (" 26.0 " এর পরে " -3 " সম্পূর্ণরূপে তথ্যপূর্ণ।)

AVB সংস্করণ মেলে

The AVB version contains a MAJOR version and MINOR version, with the format as MAJOR.MINOR (eg, 1.0, 2.1). বিস্তারিত জানার জন্য, সংস্করণ এবং সামঞ্জস্যতা পড়ুন। AVB সংস্করণে নিম্নলিখিত সিস্টেম বৈশিষ্ট্য রয়েছে:

• ro.boot.vbmeta.avb_version হল বুটলোডারে libavb সংস্করণ
• ro.boot.avb_version is the libavb version in Android OS ( init/fs_mgr )

The system property appears only when the corresponding libavb has been used to verify AVB metadata (and returns 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

বুটলোডার বা অ্যান্ড্রয়েড ওএসে দুটি কপি libavb লাইব্রেরি থাকতে পারে, প্রতিটিতে আপগ্রেড ডিভাইস এবং লঞ্চ ডিভাইসের জন্য আলাদা প্রধান সংস্করণ রয়েছে। In this case, the same unsigned system image can be shared but the final signed system images are different (with different avb.vbmeta-version ):

চিত্র 1. AVB সংস্করণ মেলে (/সিস্টেম হল P, অন্য সব পার্টিশন হল O)।

Figure 2. AVB version matches (all partitions are P).

উদাহরণ: সফল AVB সংস্করণ মিল

ফ্রেমওয়ার্ক সামঞ্জস্যতা ম্যাট্রিক্স নিম্নলিখিত AVB তথ্য জানায়:

<avb>
    <vbmeta-version>2.1</vbmeta-version>
</avb>

On the device:

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 

OTA চলাকালীন AVB সংস্করণের সাথে ম্যাচ করুন

অ্যান্ড্রয়েড 9 বা তার চেয়ে কম সংস্করণের সাথে লঞ্চ করা ডিভাইসগুলির জন্য, Android 10 এ আপডেট করার সময়, ফ্রেমওয়ার্ক সামঞ্জস্যতা ম্যাট্রিক্সে AVB সংস্করণের প্রয়োজনীয়তাগুলি ডিভাইসের বর্তমান AVB সংস্করণের সাথে মিলে যায়৷ If the AVB version has a major version upgrade during an OTA (for example, from 0.0 to 1.0), the VINTF check for compatibility in OTA doesn't reflect the compatibility after the OTA.

সমস্যাটি প্রশমিত করতে, একটি OEM চেক পাস করার জন্য OTA প্যাকেজে ( compatibility.zip ) একটি জাল AVB সংস্করণ রাখতে পারে। এটি করতে:

1. অ্যান্ড্রয়েড 9 সোর্স ট্রিতে নিম্নলিখিত CLগুলিকে চেরি-পিক করুন:
   • CL 732261
   • CL 732262
2. ডিভাইসের জন্য BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE সংজ্ঞায়িত করুন। এটির মান OTA-এর আগে 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 সহ অন্যান্য ফ্রেমওয়ার্ক সামঞ্জস্যতা ম্যাট্রিক্সকে প্রভাবিত করে না। OTA-এর পরে, /system/etc/vintf/compatibility_matrix.xml এ নতুন মানটি এর পরিবর্তে সামঞ্জস্য পরীক্ষা করার জন্য ব্যবহার করা হয়।

VNDK সংস্করণ মেলে

ডিভাইস সামঞ্জস্য ম্যাট্রিক্স compatibility-matrix.vendor-ndk.version এ প্রয়োজনীয় VNDK সংস্করণ ঘোষণা করে। যদি ডিভাইসের সামঞ্জস্যপূর্ণ ম্যাট্রিক্সে একটি <vendor-ndk> ট্যাগ না থাকে, তাহলে কোনো প্রয়োজনীয়তা আরোপ করা হয় না, এবং তাই এটি সর্বদা একটি মিল হিসাবে বিবেচিত হয়।

যদি ডিভাইসের সামঞ্জস্যতা ম্যাট্রিক্সে একটি <vendor-ndk> ট্যাগ থাকে, তাহলে ফ্রেমওয়ার্ক ম্যানিফেস্টে ফ্রেমওয়ার্ক দ্বারা প্রদত্ত VNDK ভেন্ডর স্ন্যাপশটগুলির সেট থেকে একটি ম্যাচিং <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>

Example A is a match, because VNDK version 27 is in the framework manifest, and {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>

Example B isn't a match. যদিও VNDK সংস্করণ 27 ফ্রেমওয়ার্ক ম্যানিফেস্টে রয়েছে, libjpeg.so সেই স্ন্যাপশটে ফ্রেমওয়ার্ক দ্বারা সমর্থিত নয়। VNDK version 26 is ignored.

সিস্টেম SDK সংস্করণ মেলে

ডিভাইস সামঞ্জস্যতা ম্যাট্রিক্স compatibility-matrix.system-sdk.version এ প্রয়োজনীয় সিস্টেম SDK সংস্করণের একটি সেট ঘোষণা করে। ফ্রেমওয়ার্ক ম্যানিফেস্টে manifest.system-sdk.version এ ঘোষিত সেটটি প্রদত্ত সিস্টেম SDK সংস্করণগুলির একটি উপসেট হলেই একটি মিল রয়েছে৷

• একটি বিশেষ ক্ষেত্রে, যদি ডিভাইসের সামঞ্জস্যতা ম্যাট্রিক্সে কোনো সিস্টেম SDK সংস্করণ গণনা করা না থাকে, তবে এটি সর্বদা একটি মিল হিসাবে বিবেচিত হয়, কারণ খালি সেটটি যেকোনো সেটের একটি উপসেট।

Example: Successful System SDK version match

যদি ডিভাইসের সামঞ্জস্যতা ম্যাট্রিক্স সিস্টেম SDK-তে নিম্নলিখিত প্রয়োজনীয়তাগুলি উল্লেখ করে:

<!-- Example Device Compatibility Matrix -->
<system-sdk>
    <version>26</version>
    <version>27</version>
</system-sdk>

Then, the framework must provide System SDK version 26 and 27 to match.

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

Example B is a match.

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

উদাহরণ C একটি মিল নয়, কারণ সিস্টেম SDK সংস্করণ 27 প্রদান করা হয়নি।

The two pairs of compatibility matrices and manifests are meant to be reconciled to verify that the framework and vendor implementation can work with each other. ফ্রেমওয়ার্ক কম্প্যাটিবিলিটি ম্যাট্রিক্স এবং ডিভাইস ম্যানিফেস্ট, সেইসাথে ফ্রেমওয়ার্ক ম্যানিফেস্ট এবং ডিভাইসের সামঞ্জস্যতা ম্যাট্রিক্সের মধ্যে মিলের ভিত্তিতে এই যাচাইকরণ সফল হয়।

এই যাচাইকরণটি বিল্ড টাইমে, OTA আপডেট প্যাকেজ জেনারেশনের সময়ে, বুট করার সময় এবং VTS সামঞ্জস্যতা পরীক্ষায় করা হয়।

নিম্নলিখিত বিভাগগুলি বিভিন্ন উপাদান দ্বারা ব্যবহৃত মেলা নিয়মগুলির বিশদ বিবরণ দেয়৷

Framework compatibility matrix version matches

একটি ফ্রেমওয়ার্ক সামঞ্জস্যতা ম্যাট্রিক্সের সাথে একটি ডিভাইস ম্যানিফেস্টকে মেলাতে, manifest.target-level দ্বারা নির্দিষ্ট করা Shipping FCM সংস্করণটি compatibility-matrix.level দ্বারা নির্দিষ্ট করা FCM সংস্করণের ঠিক সমান হতে হবে৷ নইলে মিল নেই।

When the framework compatibility matrix is requested with libvintf , this match is always successful because libvintf opens the device manifest, retrieves the Shipping FCM Version, and returns the framework compatibility matrix at that Shipping FCM Version (plus some optional HALs from compatibility matrices at higher FCM সংস্করণ)।

HAL মিলে

HAL-ম্যাচ নিয়ম একটি ম্যানিফেস্ট ফাইলে hal উপাদানগুলির সংস্করণগুলি সনাক্ত করে যেগুলি সংশ্লিষ্ট সামঞ্জস্যতা ম্যাট্রিক্সের মালিক দ্বারা সমর্থিত বলে মনে করা হয়।

HIDL এবং স্থানীয় HALs

The match rules for HIDL and native HALs are as follows.

• Multiple <hal> elements are evaluated with a single AND relationship.
• <hal> উপাদানগুলির প্রয়োজন নেই হিসাবে চিহ্নিত করার জন্য <hal optional="true"> থাকতে পারে।
• একই <hal> এর মধ্যে একাধিক <version> উপাদানের OR সম্পর্ক রয়েছে। If two or more are specified, only one of the versions needs to be implemented. (নীচে DRM উদাহরণ দেখুন।)
• একই <hal> এর মধ্যে একাধিক <instance> এবং <regex-instance> উপাদানগুলিকে একটি একক এবং সম্পর্ক দিয়ে মূল্যায়ন করা হয় যখন <hal> প্রয়োজন হয়। (দেখুন নীচে DRM উদাহরণ।)

উদাহরণ: একটি মডিউলের জন্য সফল HAL ম্যাচ

For a HAL at version 2.5, the match rule is as follows:

উদাহরণ: 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

AIDL HALs

অ্যান্ড্রয়েড 11 (অ্যান্ড্রয়েড 11 ব্যতীত) এর পরে সমস্ত অ্যান্ড্রয়েড সংস্করণ VINTF-এ AIDL HAL-এর সংস্করণগুলিকে সমর্থন করে। এআইডিএল এইচএএল-এর ম্যাচের নিয়মগুলি এইচআইডিএল এবং নেটিভ এইচএএল-এর মতোই, ব্যতীত কোনও বড় সংস্করণ নেই, এবং প্রতি এইচএএল উদাহরণে ঠিক একটি সংস্করণ রয়েছে ( 1 সংস্করণ অনির্দিষ্ট থাকলে)।

• একাধিক <hal> উপাদান একটি একক এবং সম্পর্ক দিয়ে মূল্যায়ন করা হয়।
• <hal> elements can have <hal optional="true"> to mark them as not required.
• একই <hal> এর মধ্যে একাধিক <instance> এবং <regex-instance> উপাদানগুলিকে একটি একক এবং সম্পর্ক দিয়ে মূল্যায়ন করা হয় যখন <hal> প্রয়োজন হয়। (দেখুন vibrator example below.)

Example: Successful HAL match for a module

সংস্করণ 5-এ HAL-এর জন্য, ম্যাচের নিয়ম নিম্নরূপ:

উদাহরণ: একাধিক মডিউলের জন্য সফল HAL ম্যাচ

The framework compatibility matrix states the following version information for vibrator and camera HALs:

<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

কার্নেল মেলে

The <kernel> section of the framework compatibility matrix describes the framework's requirements of the Linux kernel on the device. এই তথ্যটি ডিভাইসের VINTF অবজেক্ট দ্বারা রিপোর্ট করা কার্নেল সম্পর্কিত তথ্যের সাথে মিলে যাওয়ার জন্য বোঝানো হয়েছে।

কার্নেল শাখা মেলান

প্রতিটি কার্নেল শাখা প্রত্যয় (উদাহরণস্বরূপ, 5.4- r ) একটি অনন্য কার্নেল FCM সংস্করণে ম্যাপ করা হয় (উদাহরণস্বরূপ, 5)। ম্যাপিং রিলিজ অক্ষর (উদাহরণস্বরূপ, R) এবং FCM সংস্করণের (উদাহরণস্বরূপ, 5) মধ্যে ম্যাপিংয়ের মতোই।

VTS tests enforce that the device explicitly specifies the kernel FCM version in the device manifest, /vendor/etc/vintf/manifest.xml , if one of the following is true:

• কার্নেল FCM সংস্করণ লক্ষ্য FCM সংস্করণ থেকে ভিন্ন। For example, the aforementioned device has a target FCM version 4, and its kernel FCM version is 5 (kernel branch suffix r ).
• কার্নেল এফসিএম সংস্করণটি 5 (কার্নেল শাখা প্রত্যয় r ) এর চেয়ে বড় বা সমান।

VTS tests enforce that, if the kernel FCM version is specified, the kernel FCM version is greater than or equal to the target FCM version in the device manifest.

Example: Determine the kernel branch

যদি ডিভাইসটির লক্ষ্য 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 থেকে তৈরি করা হয়েছে।

Example: Determine the kernel branch for GKI

যদি ডিভাইসটি জেনেরিক কার্নেল ইমেজ (GKI) ব্যবহার করে এবং /proc/version থেকে কার্নেল রিলিজ স্ট্রিং নিম্নরূপ:

5.4.42-android12-0-00544-ged21d463f856

তারপর, VINTF অবজেক্টটি কার্নেল রিলিজ থেকে অ্যান্ড্রয়েড রিলিজ পায়, এবং কার্নেল FCM সংস্করণ নির্ধারণ করতে এটি ব্যবহার করে। এই উদাহরণে, android12 মানে কার্নেল FCM সংস্করণ 6 (Android 12 এ প্রকাশিত)।

কিভাবে কার্নেল রিলিজ স্ট্রিং পার্স করা হয় তার বিস্তারিত জানার জন্য, GKI সংস্করণ দেখুন।

Match kernel versions

একটি ম্যাট্রিক্সে একাধিক <kernel> বিভাগ অন্তর্ভুক্ত থাকতে পারে, প্রত্যেকটি বিন্যাস ব্যবহার করে একটি ভিন্ন version বৈশিষ্ট্য সহ:

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

VINTF অবজেক্টটি শুধুমাত্র এফসিএম থেকে <kernel> বিভাগটিকেই বিবেচনা করে যার সাথে এফসিএম সংস্করণের সাথে মিল রয়েছে ${ver} এবং ${major_rev} ডিভাইস কার্নেলের মতো (যেমন, version="${ver}.${major_rev}.${matrix_minor_rev}") ; অন্যান্য বিভাগ উপেক্ষা করা হয়। In addition, the minor revision from the kernel must be a value from the compatibility matrix ( ${kernel_minor_rev} >= ${matrix_minor_rev} ;). If no <kernel> section meets these requirements, it's a non-match.

উদাহরণ: মিলের জন্য প্রয়োজনীয়তা নির্বাচন করুন

নিম্নলিখিত অনুমানমূলক ক্ষেত্রে বিবেচনা করুন যেখানে /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 -->

The target FCM version, the kernel FCM version, and the kernel version together select the kernel requirements from the FCMs:

Match kernel configurations

<kernel> বিভাগটি মিললে, /proc/config.gz এর সাথে config উপাদানগুলিকে মেলানোর চেষ্টা করে প্রক্রিয়াটি চলতে থাকে। সামঞ্জস্যতা ম্যাট্রিক্সের প্রতিটি কনফিগার উপাদানের জন্য, কনফিগার উপস্থিত আছে কিনা তা দেখতে এটি /proc/config.gz দেখায়। ম্যাচিং <kernel> বিভাগের জন্য সামঞ্জস্যপূর্ণ ম্যাট্রিক্সে একটি কনফিগার আইটেম n এ সেট করা হলে, এটি অবশ্যই /proc/config.gz থেকে অনুপস্থিত থাকবে। Finally, a config item not in the compatibility matrix might or might not be present in /proc/config.gz .

Example: Match kernel configurations

• <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> matches 4096 or 0x1000 or 0X1000 .
• <value type="tristate">y</value> y সাথে মেলে।
• <value type="tristate">m</value> m সাথে মেলে।
• <value type="tristate">n</value> means the config item must NOT exist in /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>

কার্নেল শাখাটি প্রথমে মেলে। The kernel branch is specified in the device manifest in manifest.kernel.target-level , which defaults to manifest.level if the former isn't specified. যদি ডিভাইসে কার্নেল শাখা প্রকাশ করে:

• হল 1, পরবর্তী ধাপে যান এবং কার্নেল সংস্করণ পরীক্ষা করে।
• is 2, no match to matrix. VINTF objects reads kernel requirements from matrix at FCM version 2 instead.

তারপর, কার্নেল সংস্করণ মিলেছে। যদি uname() এর কোনো ডিভাইস রিপোর্ট করে:

• 4.9.84 ( <kernel version="4.9.x"> সহ একটি পৃথক কার্নেল বিভাগ না থাকলে ম্যাট্রিক্সের সাথে কোন মিল নেই, যেখানে x <= 84 )
• 4.14.41 (no match to matrix, smaller than 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"

The following kernel configuration is an example of an unsuccessful match:

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 policy matches

SE policy requires the following matches:

• <sepolicy-version> প্রতিটি বড় সংস্করণের জন্য ছোটখাট সংস্করণের একটি বন্ধ পরিসর সংজ্ঞায়িত করে। ফ্রেমওয়ার্কের সাথে সামঞ্জস্যপূর্ণ হতে ডিভাইসের দ্বারা রিপোর্ট করা সেপলিসি সংস্করণটি অবশ্যই এই সীমাগুলির মধ্যে একটির মধ্যে পড়তে হবে৷ ম্যাচের নিয়মগুলি HAL সংস্করণের অনুরূপ; এটি একটি মিল যদি সেপলিসি সংস্করণটি পরিসরের ন্যূনতম সংস্করণের উচ্চতর বা সমান হয়। The maximum version is purely informational.
• <kernel-sepolicy-version> ie policydb version. ডিভাইস দ্বারা রিপোর্ট করা 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>

On the device:

• security_policyvers() দ্বারা প্রত্যাবর্তিত মান অবশ্যই 30 এর বেশি বা সমান হতে হবে। অন্যথায় এটি একটি মিল নয়। যেমন:
  • যদি একটি ডিভাইস 29 রিটার্ন করে, এটি একটি মিল নয়।
  • যদি একটি ডিভাইস 31 রিটার্ন করে, এটি একটি ম্যাচ।
• SE Policy version must be one of 25.0-∞ or 26.0-∞. অন্যথায় এটি একটি ম্যাচ নয়। (" 26.0 " এর পরে " -3 " সম্পূর্ণরূপে তথ্যপূর্ণ।)

AVB সংস্করণ মেলে

AVB সংস্করণে একটি MAJOR সংস্করণ এবং MINOR সংস্করণ রয়েছে, যার বিন্যাসটি MAJOR.MINOR (যেমন, 1.0, 2.1)। For details, refer to Versioning and Compatibility . AVB সংস্করণে নিম্নলিখিত সিস্টেম বৈশিষ্ট্য রয়েছে:

• ro.boot.vbmeta.avb_version is the libavb version in bootloader
• ro.boot.avb_version হল Android OS এর libavb সংস্করণ ( init/fs_mgr )

সিস্টেমের বৈশিষ্ট্যটি তখনই প্রদর্শিত হয় যখন সংশ্লিষ্ট libavb AVB মেটাডেটা যাচাই করতে ব্যবহার করা হয় (এবং ঠিক আছে)। এটি অনুপস্থিত যদি একটি যাচাইকরণ ব্যর্থ হয় (বা কোনো যাচাইকরণ ঘটেনি)।

একটি সামঞ্জস্যপূর্ণ মিল নিম্নলিখিত তুলনা করে:

• Sysprop ro.boot.vbmeta.avb_version সহ ফ্রেমওয়ার্কের সামঞ্জস্যতা ম্যাট্রিক্স থেকে avb.vbmeta-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। এভিবি সংস্করণ মেলে (/সিস্টেম পি, অন্যান্য সমস্ত পার্টিশন ও)।

চিত্র 2। এভিবি সংস্করণ ম্যাচগুলি (সমস্ত পার্টিশনগুলি পি হয়)।

উদাহরণ: সফল এভিবি সংস্করণ ম্যাচ

ফ্রেমওয়ার্কের সামঞ্জস্যতা ম্যাট্রিক্স নিম্নলিখিত এভিবি তথ্য জানিয়েছে:

<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 পর্যন্ত), ওটিএতে সামঞ্জস্যের জন্য ভিন্টফ চেকটি ওটিএর পরে সামঞ্জস্যতা প্রতিফলিত করে না।

সমস্যাটি প্রশমিত করতে, একটি ওএম চেকটি পাস করার জন্য ওটিএ প্যাকেজে ( compatibility.zip ) একটি জাল এভিবি সংস্করণ রাখতে পারে। এটি করতে:

1. অ্যান্ড্রয়েড 9 সোর্স ট্রি তে নিম্নলিখিত সিএলএস-চেরি-পিক:
   • সিএল 732261
   • সিএল 732262
2. ডিভাইসের জন্য BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE সংজ্ঞায়িত করুন। এর মানটি ওটিএর আগে এভিবি সংস্করণটির সমান হওয়া উচিত, এটি হ'ল ডিভাইসের এভিবি সংস্করণ এটি চালু হওয়ার সময়।
3. ওটিএ প্যাকেজটি পুনর্নির্মাণ করুন।

এই পরিবর্তনগুলি স্বয়ংক্রিয়ভাবে BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE compatibility-matrix.avb.vbmeta-version নিম্নলিখিত ফাইলগুলিতে রাখে:

• /system/compatibility_matrix.xml (যা অ্যান্ড্রয়েড 9 এ ব্যবহৃত হয় না) ডিভাইসে
• OTA প্যাকেজে compatibility.zip system_matrix.xml

এই পরিবর্তনগুলি অন্যান্য কাঠামোর সামঞ্জস্যতা ম্যাট্রিক্সকে প্রভাবিত করে না, /system/etc/vintf/compatibility_matrix.xml সহ। ওটিএর পরে, /system/etc/vintf/compatibility_matrix.xml -তে নতুন মানটি পরিবর্তে সামঞ্জস্যতা চেকগুলির জন্য ব্যবহৃত হয়।

Vndk সংস্করণ মেলে

ডিভাইস সামঞ্জস্যতা ম্যাট্রিক্স compatibility-matrix.vendor-ndk.version প্রয়োজনীয় ভিএনডিকে সংস্করণ ঘোষণা করে। যদি ডিভাইসের সামঞ্জস্যতা ম্যাট্রিক্সে কোনও <vendor-ndk> ট্যাগ না থাকে তবে কোনও প্রয়োজনীয়তা আরোপ করা হয় না এবং তাই এটি সর্বদা একটি ম্যাচ হিসাবে বিবেচিত হয়।

যদি ডিভাইসের সামঞ্জস্যতা ম্যাট্রিক্সে একটি <vendor-ndk> ট্যাগ থাকে তবে একটি <vendor-ndk> একটি ম্যাচিং <version> এর সাথে এন্ট্রিটি ভিএনডিকে বিক্রেতার স্ন্যাপশটগুলির সেট থেকে সন্ধান করা হয় যা ফ্রেমওয়ার্ক ম্যানিফেস্টে ফ্রেমওয়ার্ক দ্বারা সরবরাহ করা হয়। যদি এই জাতীয় প্রবেশের অস্তিত্ব না থাকে তবে কোনও মিল নেই।

যদি এই জাতীয় প্রবেশের উপস্থিতি থাকে তবে ডিভাইসের সামঞ্জস্যতা ম্যাট্রিক্সে গণিত লাইব্রেরির সেটটি অবশ্যই ফ্রেমওয়ার্ক ম্যানিফেস্টে বর্ণিত গ্রন্থাগারগুলির সেটের একটি উপসেট হতে হবে; অন্যথায়, এন্ট্রি একটি ম্যাচ হিসাবে বিবেচিত হয় না।

• একটি বিশেষ কেস হিসাবে, যদি কোনও লাইব্রেরি ডিভাইস সামঞ্জস্যতা ম্যাট্রিক্সে গণনা করা হয় তবে এন্ট্রিটি সর্বদা একটি ম্যাচ হিসাবে বিবেচিত হয়, কারণ খালি সেটটি কোনও সেটের একটি উপসেট।

উদাহরণ: সফল ভিএনডিকে সংস্করণ ম্যাচ

যদি ডিভাইসের সামঞ্জস্যতা ম্যাট্রিক্স ভিএনডিকে নিম্নলিখিত প্রয়োজনীয়তা উল্লেখ করে:

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

উদাহরণ খ ম্যাচ নয়। যদিও ভিএনডিকে সংস্করণ 27 ফ্রেমওয়ার্ক ম্যানিফেস্টে রয়েছে, তবুও libjpeg.so সেই স্ন্যাপশটের ফ্রেমওয়ার্ক দ্বারা সমর্থিত নয়। ভিএনডিকে সংস্করণ 26 উপেক্ষা করা হয়।

সিস্টেম এসডিকে সংস্করণ মেলে

ডিভাইস সামঞ্জস্যতা ম্যাট্রিক্স 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>

উদাহরণ এ একটি ম্যাচ।

<!-- 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 সরবরাহ করা হয়নি।

ফ্রেমওয়ার্ক এবং বিক্রেতার বাস্তবায়ন একে অপরের সাথে কাজ করতে পারে তা যাচাই করার জন্য দুটি জোড়া সামঞ্জস্যতা ম্যাট্রিক্স এবং ম্যানিফেস্টগুলি পুনর্মিলন করা বোঝানো হয়। এই যাচাইকরণ ফ্রেমওয়ার্কের সামঞ্জস্যতা ম্যাট্রিক্স এবং ডিভাইস ম্যানিফেস্টের পাশাপাশি ফ্রেমওয়ার্ক ম্যানিফেস্ট এবং ডিভাইসের সামঞ্জস্যতা ম্যাট্রিক্সের মধ্যে একটি ম্যাচে সফল।

এই যাচাইকরণটি বিল্ড টাইমে, ওটিএ আপডেট প্যাকেজ জেনারেশন টাইম, বুট সময় এবং ভিটিএসের সামঞ্জস্যতা পরীক্ষায় করা হয়।

নিম্নলিখিত বিভাগগুলি বিভিন্ন উপাদান দ্বারা ব্যবহৃত বিধি বিধি বিধিগুলি।

ফ্রেমওয়ার্কের সামঞ্জস্যতা ম্যাট্রিক্স সংস্করণ মেলে

ফ্রেমওয়ার্কের সামঞ্জস্যতা ম্যাট্রিক্সের সাথে কোনও ডিভাইস ম্যানিফেস্টের সাথে মেলে, manifest.target-level অবশ্যই compatibility-matrix.level দ্বারা নির্দিষ্ট করা এফসিএম সংস্করণের সমান হতে হবে। অন্যথায় কোন মিল নেই।

যখন ফ্রেমওয়ার্কের সামঞ্জস্যতা ম্যাট্রিক্সকে libvintf সাথে অনুরোধ করা হয়, তখন এই ম্যাচটি সর্বদা সফল হয় কারণ libvintf ডিভাইসটি প্রকাশ করে, শিপিং এফসিএম সংস্করণটি পুনরুদ্ধার করে এবং সেই শিপিং এফসিএম সংস্করণে ফ্রেমওয়ার্কের সামঞ্জস্যতা ম্যাট্রিক্স দেয় (প্লাস উচ্চতর এফসিএম -এ কিছু al চ্ছিক হালাল সংস্করণ)।

হাল ম্যাচ

হাল-ম্যাচ নিয়মটি একটি ম্যানিফেস্ট ফাইলে hal উপাদানগুলির সংস্করণগুলি সনাক্ত করে যা সংশ্লিষ্ট সামঞ্জস্যতা ম্যাট্রিক্সের মালিক দ্বারা সমর্থিত বলে বিবেচিত হয়।

হিডল এবং নেটিভ হালস

এইচআইডিএল এবং নেটিভ হালালগুলির জন্য ম্যাচের নিয়মগুলি নিম্নরূপ।

• একাধিক <hal> উপাদানগুলি একটি একক এবং সম্পর্কের সাথে মূল্যায়ন করা হয়।
• <hal> উপাদানগুলির প্রয়োজন হিসাবে চিহ্নিত করার জন্য <hal optional="true"> থাকতে পারে।
• একাধিক <version> একই <hal> এর মধ্যে উপাদানগুলির মধ্যে বা সম্পর্ক রয়েছে। যদি দুটি বা আরও বেশি নির্দিষ্ট করা থাকে তবে কেবলমাত্র একটি সংস্করণ প্রয়োগ করা দরকার। (নীচে ডিআরএম উদাহরণ দেখুন))
• একাধিক <instance> এবং <regex-instance> একই <hal> এর মধ্যে উপাদানগুলি যখন <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

এইডল হালস

অ্যান্ড্রয়েড 11 এর পরে সমস্ত অ্যান্ড্রয়েড সংস্করণ (অ্যান্ড্রয়েড 11 বাদে) ভিন্টফের এইডল হালসের জন্য সংস্করণগুলি সমর্থন করে। এইডল হালসের জন্য ম্যাচের নিয়মগুলি এইচআইডিএল এবং নেটিভ হালসের মতোই, সেখানে কোনও বড় সংস্করণ নেই, এবং এইচএল উদাহরণ প্রতি ঠিক একটি সংস্করণ রয়েছে (1 সংস্করণটি অনির্ধারিত হলে 1 )।

• একাধিক <hal> উপাদানগুলি একটি একক এবং সম্পর্কের সাথে মূল্যায়ন করা হয়।
• <hal> উপাদানগুলির প্রয়োজন হিসাবে চিহ্নিত করার জন্য <hal optional="true"> থাকতে পারে।
• একাধিক <instance> এবং <regex-instance> একই <hal> এর মধ্যে উপাদানগুলি যখন <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> বিভাগটি ডিভাইসে লিনাক্স কার্নেলের কাঠামোর প্রয়োজনীয়তা বর্ণনা করে। এই তথ্যটি হ'ল ডিভাইসের ভিন্টফ অবজেক্ট দ্বারা রিপোর্ট করা কার্নেল সম্পর্কিত তথ্যের সাথে মিলে যাওয়া।

কার্নেল শাখা মেলে

প্রতিটি কার্নেল শাখা প্রত্যয় (উদাহরণস্বরূপ, 5.4- r ) একটি অনন্য কার্নেল এফসিএম সংস্করণে ম্যাপ করা হয় (উদাহরণস্বরূপ, 5)। ম্যাপিংটি রিলিজ লেটারগুলির (উদাহরণস্বরূপ, আর) এবং এফসিএম সংস্করণগুলির মধ্যে ম্যাপিংয়ের সমান (উদাহরণস্বরূপ, 5)।

ভিটিএস পরীক্ষাগুলি প্রয়োগ করে যে ডিভাইসটি স্পষ্টভাবে ডিভাইস ম্যানিফেস্টে কার্নেল এফসিএম সংস্করণ নির্দিষ্ট করে, /vendor/etc/vintf/manifest.xml , যদি নিম্নলিখিতগুলির মধ্যে একটি সত্য হয়:

• কার্নেল এফসিএম সংস্করণটি লক্ষ্য এফসিএম সংস্করণ থেকে পৃথক। উদাহরণস্বরূপ, পূর্বোক্ত ডিভাইসে একটি লক্ষ্য এফসিএম সংস্করণ 4 রয়েছে এবং এর কার্নেল এফসিএম সংস্করণ 5 (কার্নেল শাখা প্রত্যয় r )।
• কার্নেল এফসিএম সংস্করণটি 5 এর চেয়ে বেশি বা সমান (কার্নেল শাখা প্রত্যয় r )।

ভিটিএস পরীক্ষাগুলি প্রয়োগ করে যে, যদি কার্নেল এফসিএম সংস্করণটি নির্দিষ্ট করা থাকে তবে কার্নেল এফসিএম সংস্করণটি ডিভাইস ম্যানিফেস্টের লক্ষ্য এফসিএম সংস্করণের চেয়ে বেশি বা সমান।

উদাহরণ: কার্নেল শাখা নির্ধারণ করুন

যদি ডিভাইসে লক্ষ্য এফসিএম সংস্করণ 4 (অ্যান্ড্রয়েড 10 এ প্রকাশিত) থাকে তবে 4.19-r শাখা থেকে কার্নেল চালায়, ডিভাইস ম্যানিফেস্টের নিম্নলিখিতগুলি নির্দিষ্ট করা উচিত:

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

ভিন্টফ অবজেক্টটি 4.19-r কার্নেল শাখায় প্রয়োজনীয়তার বিরুদ্ধে কার্নেল সামঞ্জস্যতা পরীক্ষা করে, যা এফসিএম সংস্করণ kernel/configs/r/android-4.19 এ নির্দিষ্ট করা হয়েছে These

উদাহরণ: জিকেআইয়ের জন্য কার্নেল শাখা নির্ধারণ করুন

যদি ডিভাইসটি জেনেরিক কার্নেল চিত্র (জিকেআই) ব্যবহার করে এবং /proc/version থেকে কার্নেল রিলিজ স্ট্রিংটি নিম্নলিখিত:

5.4.42-android12-0-00544-ged21d463f856

তারপরে, ভিন্টফ অবজেক্টটি কার্নেল রিলিজ থেকে অ্যান্ড্রয়েড রিলিজ গ্রহণ করে এবং কার্নেল এফসিএম সংস্করণ নির্ধারণ করতে এটি ব্যবহার করে। এই উদাহরণে, android12 অর্থ কার্নেল এফসিএম সংস্করণ 6 (অ্যান্ড্রয়েড 12 এ প্রকাশিত)।

কার্নেল রিলিজ স্ট্রিংটি কীভাবে পার্স করা হয়েছে সে সম্পর্কে বিশদগুলির জন্য, জি কেআই সংস্করণ দেখুন।

কার্নেল সংস্করণগুলি মেলে

একটি ম্যাট্রিক্সে একাধিক <kernel> বিভাগ অন্তর্ভুক্ত থাকতে পারে, প্রতিটি ফর্ম্যাটটি ব্যবহার করে আলাদা version বৈশিষ্ট্যযুক্ত:

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

ভিন্টফ অবজেক্টটি এফসিএম থেকে কেবল <kernel> বিভাগকে একই ${ver} এবং ${major_rev} সাথে ডিভাইস কার্নেল হিসাবে (যেমন, 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 -->

লক্ষ্য এফসিএম সংস্করণ, কার্নেল এফসিএম সংস্করণ এবং কার্নেল সংস্করণ একসাথে এফসিএমএস থেকে কার্নেলের প্রয়োজনীয়তা নির্বাচন করুন:

কার্নেল কনফিগারেশন মেলে

যদি <kernel> বিভাগটি মেলে, প্রক্রিয়াটি /proc/config.gz বিরুদ্ধে config উপাদানগুলির সাথে মেলে চেষ্টা করে প্রক্রিয়াটি অব্যাহত রয়েছে। সামঞ্জস্যতা ম্যাট্রিক্সের প্রতিটি কনফিগার উপাদানটির জন্য, কনফিগারেশনটি উপস্থিত রয়েছে কিনা তা দেখার জন্য এটি /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, ম্যাট্রিক্সের সাথে কোনও মিল নেই। ভিন্টফ অবজেক্টগুলি পরিবর্তে এফসিএম সংস্করণ 2 এ ম্যাট্রিক্স থেকে কার্নেলের প্রয়োজনীয়তাগুলি পড়ে।

তারপরে, কার্নেল সংস্করণটি মিলছে। যদি কোনও ডিভাইস uname() প্রতিবেদন করে:

• 4.9.84 ( <kernel version="4.9.x"> এর সাথে পৃথক কার্নেল বিভাগ না থাকলে ম্যাট্রিক্সের সাথে কোনও মিল নেই, যেখানে x <= 84 )
• 4.14.41 (ম্যাট্রিক্সের সাথে কোনও মিল নেই, version চেয়ে ছোট)
• 4.14.42 (ম্যাট্রিক্সের সাথে ম্যাচ)
• 4.14.43 (ম্যাট্রিক্সের সাথে ম্যাচ)
• ৪.১.২২ ( <kernel version="4.1.x"> যেখানে x <= 22 ) সহ পৃথক কার্নেল বিভাগ না থাকলে ম্যাট্রিক্সের সাথে কোনও মিল নেই

উপযুক্ত <kernel> বিভাগটি নির্বাচিত হওয়ার পরে, প্রতিটি <config> আইটেমের জন্য n ব্যতীত অন্য মানের সাথে, আমরা আশা করি যে সংশ্লিষ্ট এন্ট্রিটি / /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 এর চেয়ে বেশি বা সমান হতে হবে Otherwise অন্যথায় এটি কোনও মিল নয়। যেমন:
  • যদি কোনও ডিভাইস 29 ফিরে আসে তবে এটি কোনও মিল নয়।
  • যদি কোনও ডিভাইস 31 ফিরে আসে তবে এটি একটি ম্যাচ।
• এসই নীতি সংস্করণ অবশ্যই 25.0-∞ বা 26.0-∞ এর মধ্যে একটি হতে হবে ∞ অন্যথায় এটি কোনও ম্যাচ নয়। (" 26.0 " এর পরে " -3 " খাঁটি তথ্যমূলক))

এভিবি সংস্করণ মেলে

এভিবি সংস্করণে মেজর.মিনোর হিসাবে ফর্ম্যাট সহ একটি প্রধান সংস্করণ এবং ছোটখাট সংস্করণ রয়েছে (যেমন, 1.0, 2.1)। বিশদ জন্য, সংস্করণ এবং সামঞ্জস্যতা দেখুন। এভিবি সংস্করণে নিম্নলিখিত সিস্টেমের বৈশিষ্ট্য রয়েছে:

• ro.boot.vbmeta.avb_version বুটলোডার মধ্যে libavb সংস্করণ
• ro.boot.avb_version android OS ( init/fs_mgr ) এর libavb সংস্করণ

সিস্টেমের সম্পত্তিটি তখনই উপস্থিত হয় যখন সংশ্লিষ্ট libavb এভিবি মেটাডেটা যাচাই করতে ব্যবহৃত হয় (এবং ঠিক আছে ফিরে আসে)। যদি কোনও যাচাইকরণ ব্যর্থতা ঘটে (বা কোনও যাচাইকরণ মোটেই ঘটেনি) অনুপস্থিত।

একটি সামঞ্জস্যতা ম্যাচ নিম্নলিখিতগুলির সাথে তুলনা করে:

• Sysprop ro.boot.vbmeta.avb_version সহ ফ্রেমওয়ার্কের সামঞ্জস্যতা ম্যাট্রিক্স থেকে avb.vbmeta-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। এভিবি সংস্করণ মেলে (/সিস্টেম পি, অন্যান্য সমস্ত পার্টিশন ও)।

চিত্র 2। এভিবি সংস্করণ ম্যাচগুলি (সমস্ত পার্টিশনগুলি পি হয়)।

উদাহরণ: সফল এভিবি সংস্করণ ম্যাচ

ফ্রেমওয়ার্কের সামঞ্জস্যতা ম্যাট্রিক্স নিম্নলিখিত এভিবি তথ্য জানিয়েছে:

<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 পর্যন্ত), ওটিএতে সামঞ্জস্যের জন্য ভিন্টফ চেকটি ওটিএর পরে সামঞ্জস্যতা প্রতিফলিত করে না।

সমস্যাটি প্রশমিত করতে, একটি ওএম চেকটি পাস করার জন্য ওটিএ প্যাকেজে ( compatibility.zip ) একটি জাল এভিবি সংস্করণ রাখতে পারে। এটি করতে:

1. অ্যান্ড্রয়েড 9 সোর্স ট্রি তে নিম্নলিখিত সিএলএস-চেরি-পিক:
   • সিএল 732261
   • সিএল 732262
2. ডিভাইসের জন্য BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE সংজ্ঞায়িত করুন। এর মানটি ওটিএর আগে এভিবি সংস্করণটির সমান হওয়া উচিত, এটি হ'ল ডিভাইসের এভিবি সংস্করণ এটি চালু হওয়ার সময়।
3. ওটিএ প্যাকেজটি পুনর্নির্মাণ করুন।

এই পরিবর্তনগুলি স্বয়ংক্রিয়ভাবে BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE compatibility-matrix.avb.vbmeta-version নিম্নলিখিত ফাইলগুলিতে রাখে:

• /system/compatibility_matrix.xml (যা অ্যান্ড্রয়েড 9 এ ব্যবহৃত হয় না) ডিভাইসে
• OTA প্যাকেজে compatibility.zip system_matrix.xml

এই পরিবর্তনগুলি অন্যান্য কাঠামোর সামঞ্জস্যতা ম্যাট্রিক্সকে প্রভাবিত করে না, /system/etc/vintf/compatibility_matrix.xml সহ। ওটিএর পরে, /system/etc/vintf/compatibility_matrix.xml -তে নতুন মানটি পরিবর্তে সামঞ্জস্যতা চেকগুলির জন্য ব্যবহৃত হয়।

Vndk সংস্করণ মেলে

ডিভাইস সামঞ্জস্যতা ম্যাট্রিক্স compatibility-matrix.vendor-ndk.version প্রয়োজনীয় ভিএনডিকে সংস্করণ ঘোষণা করে। যদি ডিভাইসের সামঞ্জস্যতা ম্যাট্রিক্সে কোনও <vendor-ndk> ট্যাগ না থাকে তবে কোনও প্রয়োজনীয়তা আরোপ করা হয় না এবং তাই এটি সর্বদা একটি ম্যাচ হিসাবে বিবেচিত হয়।

যদি ডিভাইসের সামঞ্জস্যতা ম্যাট্রিক্সে একটি <vendor-ndk> ট্যাগ থাকে তবে একটি <vendor-ndk> একটি ম্যাচিং <version> এর সাথে এন্ট্রিটি ভিএনডিকে বিক্রেতার স্ন্যাপশটগুলির সেট থেকে সন্ধান করা হয় যা ফ্রেমওয়ার্ক ম্যানিফেস্টে ফ্রেমওয়ার্ক দ্বারা সরবরাহ করা হয়। যদি এই জাতীয় প্রবেশের অস্তিত্ব না থাকে তবে কোনও মিল নেই।

যদি এই জাতীয় প্রবেশের উপস্থিতি থাকে তবে ডিভাইসের সামঞ্জস্যতা ম্যাট্রিক্সে গণিত লাইব্রেরির সেটটি অবশ্যই ফ্রেমওয়ার্ক ম্যানিফেস্টে বর্ণিত গ্রন্থাগারগুলির সেটের একটি উপসেট হতে হবে; অন্যথায়, এন্ট্রি একটি ম্যাচ হিসাবে বিবেচিত হয় না।

• একটি বিশেষ কেস হিসাবে, যদি কোনও লাইব্রেরি ডিভাইস সামঞ্জস্যতা ম্যাট্রিক্সে গণনা করা হয় তবে এন্ট্রিটি সর্বদা একটি ম্যাচ হিসাবে বিবেচিত হয়, কারণ খালি সেটটি কোনও সেটের একটি উপসেট।

উদাহরণ: সফল ভিএনডিকে সংস্করণ ম্যাচ

যদি ডিভাইসের সামঞ্জস্যতা ম্যাট্রিক্স ভিএনডিকে নিম্নলিখিত প্রয়োজনীয়তা উল্লেখ করে:

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

উদাহরণ খ ম্যাচ নয়। যদিও ভিএনডিকে সংস্করণ 27 ফ্রেমওয়ার্ক ম্যানিফেস্টে রয়েছে, তবুও libjpeg.so সেই স্ন্যাপশটের ফ্রেমওয়ার্ক দ্বারা সমর্থিত নয়। ভিএনডিকে সংস্করণ 26 উপেক্ষা করা হয়।

সিস্টেম এসডিকে সংস্করণ মেলে

ডিভাইসের সামঞ্জস্যতা ম্যাট্রিক্স 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>

উদাহরণ এ একটি ম্যাচ।

<!-- 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 সরবরাহ করা হয়নি।