মিলে যাওয়া সংক্রান্ত নিয়ম

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

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

বিভিন্ন কম্পোনেন্ট ব্যবহার করে ম্যাচ করার নিয়মাবলী নিম্নলিখিত বিভাগে বিস্তারিতভাবে বলা আছে।

ফ্রেমওয়ার্ক মানানসই ম্যাট্রিক্স ভার্সন ম্যাচ করে

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

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

HAL ম্যাচ

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

HIDL ও নেটিভ HAL

HIDL ও নেটিভ HAL-এর জন্য ম্যাচ করার নিয়ম নিচে দেওয়া হল:

• একাধিক <hal> এলিমেন্ট একটি এবং সম্পর্কের সাথে মূল্যায়ন করা হয়।
• <hal> এলিমেন্টকে প্রয়োজনীয় নয় হিসেবে চিহ্নিত করতে <hal optional="true"> থাকতে পারে।
• একই <hal> এলিমেন্টের মধ্যে একাধিক <version> এলিমেন্ট অথবা সম্পর্কযুক্ত। দুটি বা তার বেশি উল্লেখ করা থাকলে, শুধুমাত্র একটি ভার্সন প্রয়োগ করতে হবে। (DRM মডিউলের জন্য সফল HAL ম্যাচ দেখুন।)
• <hal>-এর মধ্যে একাধিক <instance> এবং <regex-instance> এলিমেন্ট <hal>-এর প্রয়োজন হলে একটি এবং সম্পর্ক দিয়ে মূল্যায়ন করা হয়। (DRM মডিউলের জন্য সফল HAL ম্যাচ দেখুন।)

যেমন: কোনও মডিউলের জন্য HAL ম্যাচ করা

HAL-এর ভার্সন 2.5-এর জন্য, ম্যাচ করার নিয়ম হল:

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

ফ্রেমওয়ার্ক কম্প্যাটিবিলিটি ম্যাট্রিক্স DRM HAL-এর জন্য নিম্নলিখিত ভার্সন সংক্রান্ত তথ্য দেখায়:

<hal>
    <name>android.hardware.drm
    <version>1.0</version>
    <version>3.1-2</version>
    <interface>
        <name>IDrmFactory</name>
        <instance>default</instance>
        <instance>specific</instance>
    </interface>
</hal>
<hal>
    <name>android.hardware.drm
    <version>2.0</version>
    <interface>
        <name>ICryptoFactory</name>
        <instance>default</instance>
        <regex-instance>[a-z]+/[0-9]+</regex-instance>
    </interface>
</hal>

কোনও ভেন্ডর নিম্নলিখিত যেকোনও উদাহরণ প্রয়োগ করতে পারেন:

android.hardware.drm@1.x::IDrmFactory/default          // where x >= 0
android.hardware.drm@1.x::IDrmFactory/specific         // where x >= 0
android.hardware.drm@3.y::IDrmFactory/default          // where y >= 1
android.hardware.drm@3.y::IDrmFactory/specific         // where y >= 1
android.hardware.drm@2.z::ICryptoFactory/default       // where z >= 0
android.hardware.drm@2.z::ICryptoFactory/${INSTANCE}
            // where z >= 0 and ${INSTANCE} matches [a-z]+/[0-9]+
            // e.g. legacy/0

AIDL HAL

VINTF-এ AIDL HAL-এর জন্য Android ও তার পরবর্তী যেকোনও ভার্সন কাজ করে। AIDL HAL-এর জন্য ম্যাচ করার নিয়ম HIDL ও নেটিভ HAL-এর মতোই, তবে এতে কোনও মেজর ভার্সন নেই এবং প্রতিটি HAL ইনস্ট্যান্সের জন্য ঠিক একটি ভার্সন আছে (ভার্সন উল্লেখ করা না থাকলে 1):

• একাধিক <hal> এলিমেন্ট একটি এবং সম্পর্কের সাথে মূল্যায়ন করা হয়।
• <hal> এলিমেন্টকে প্রয়োজনীয় নয় হিসেবে চিহ্নিত করতে <hal optional="true"> ব্যবহার করা যেতে পারে।
• <hal>-এর প্রয়োজন হলে, একই <hal>-এর মধ্যে থাকা একাধিক <instance> ও <regex-instance> এলিমেন্টকে একটি এবং সম্পর্ক দিয়ে মূল্যায়ন করা হয়। (একাধিক মডিউলের জন্য HAL ম্যাচ সফল হয়েছে দেখুন।)

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

HAL-এর ৫ নম্বর ভার্সনের জন্য, ম্যাচ করার নিয়ম নিচে দেওয়া হল:

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

ফ্রেমওয়ার্কের মানানসই ম্যাট্রিক্স ভাইব্রেটর ও ক্যামেরা HAL-এর জন্য নিচের ভার্সন সংক্রান্ত তথ্য প্রদান করে:

<hal>
    <name>android.hardware.vibrator
    <version>1-2</version>
    <interface>
        <name>IVibrator</name>
        <instance>default</instance>
        <instance>specific</instance>
    </interface>
</hal>
<hal>
    <name>android.hardware.camera
    <version>5</version>
    <interface>
        <name>ICamera</name>
        <instance>default</instance>
        <regex-instance>[a-z]+/[0-9]+</regex-instance>
    </interface>
</hal>

কোনও ভেন্ডর এইসব ইনস্ট্যান্সের যেকোনও একটি প্রয়োগ করতে পারেন:

android.hardware.vibrator.IVibrator/default     // version >= 1
android.hardware.vibrator.IVibrator/specific    // version >= 1
android.hardware.camera.ICamera/default         // version >= 5
android.hardware.camera.ICamera/${INSTANCE}
            // with version >= 5, where ${INSTANCE} matches [a-z]+/[0-9]+
            // e.g. legacy/0

কার্নেল ম্যাচ

ফ্রেমওয়ার্ক কম্প্যাটিবিলিটি ম্যাট্রিক্সের <kernel> বিভাগে ডিভাইসে Linux কার্নেলের প্রয়োজনীয়তা সম্পর্কে বর্ণনা করা আছে। এই তথ্যটি ডিভাইসের VINTF অবজেক্টের মাধ্যমে রিপোর্ট করা কার্নেল সম্পর্কিত তথ্যের সাথে ম্যাচ করার জন্য ব্যবহার করা হয়।

কার্নেল ব্রাঞ্চ ম্যাচ করা

প্রতিটি কার্নেল ব্রাঞ্চ সাফিক্স (যেমন, 5.4-r) একটি অনন্য কার্নেল FCM ভার্সনের (যেমন, ৫) সাথে ম্যাপ করা হয়। ম্যাপিংটি রিলিজ লেটার (যেমন, R) এবং FCM ভার্সন (যেমন, 5)-এর মধ্যে ম্যাপিংয়ের মতোই।

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

• কার্নেল FCM ভার্সন টার্গেট FCM ভার্সনের থেকে আলাদা। যেমন, উপরে উল্লিখিত ডিভাইসে টার্গেট FCM ভার্সন ৪ আছে এবং এর কার্নেল FCM ভার্সন ৫ (কার্নেল ব্রাঞ্চ সাফিক্স r)।
• কার্নেল FCM ভার্সন ৫ বা তার থেকে বেশি (কার্নেল ব্রাঞ্চ সাফিক্স r)।

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

উদাহরণ: কার্নেল ব্রাঞ্চ নির্ধারণ করা

ডিভাইসে টার্গেট FCM ভার্সন 4 (Android 10-এ রিলিজ করা হয়েছে) থাকলে, কিন্তু 4.19-r ব্রাঞ্চ থেকে কার্নেল রান করলে, ডিভাইস ম্যানিফেস্টে নিম্নলিখিত বিষয় উল্লেখ করতে হবে:

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

VINTF অবজেক্ট 4.19-r কার্নেল ব্রাঞ্চে প্রয়োজনীয়তার সাথে কার্নেল কম্প্যাটিবিলিটি চেক করে, যা FCM ভার্সন ৫-এ উল্লেখ করা আছে। এইসব প্রয়োজনীয়তা Android সোর্স ট্রি-তে kernel/configs/r/android-4.19 থেকে তৈরি করা হয়েছে।

উদাহরণ: GKI-এর জন্য কার্নেল ব্রাঞ্চ নির্ধারণ করা

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

5.4.42-android12-0-00544-ged21d463f856

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

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

কার্নেল ভার্সন ম্যাচ করুন

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

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

VINTF অবজেক্ট শুধুমাত্র <kernel> বিভাগ থেকে FCM বিবেচনা করে, যার FCM ভার্সন ডিভাইসের কার্নেলের সাথে ম্যাচ করে (অর্থাৎ, version="${ver}.${major_rev}.${matrix_minor_rev}"); অন্যান্য বিভাগ উপেক্ষা করা হয়)।${ver}${major_rev} এছাড়াও, কার্নেলের মাইনর রিভিশন অবশ্যই কম্প্যাটিবিলিটি ম্যাট্রিক্স (${kernel_minor_rev} >= ${matrix_minor_rev};) থেকে নেওয়া ভ্যালু হতে হবে। কোনও <kernel> বিভাগ এই প্রয়োজনীয়তা পূরণ না করলে, সেটি ম্যাচ করে না।

যেমন: ম্যাচ করার জন্য প্রয়োজনীয়তা বেছে নিন

নিচের কাল্পনিক পরিস্থিতিটি বিবেচনা করুন যেখানে /system/etc/vintf-এ FCM নিম্নলিখিত প্রয়োজনীয়তাগুলি ঘোষণা করে (হেডার এবং ফুটার ট্যাগ বাদ দেওয়া হয়েছে):

<!-- compatibility_matrix.3.xml -->
<kernel version="4.4.107" level="3"/>
<!-- See kernel/configs/p/android-4.4/ for 4.4-p requirements -->
<kernel version="4.9.84" level="3"/>
<!-- See kernel/configs/p/android-4.9/ for 4.9-p requirements -->
<kernel version="4.14.42" level="3"/>
<!-- See kernel/configs/p/android-4.14/ for 4.14-p requirements -->

<!-- compatibility_matrix.4.xml -->
<kernel version="4.9.165" level="4"/>
<!-- See kernel/configs/q/android-4.9/ for 4.9-q requirements -->
<kernel version="4.14.105" level="4"/>
<!-- See kernel/configs/q/android-4.14/ for 4.14-q requirements -->
<kernel version="4.19.42" level="4"/>
<!-- See kernel/configs/q/android-4.19/ for 4.19-q requirements -->

<!-- compatibility_matrix.5.xml -->
<kernel version="4.14.180" level="5"/>
<!-- See kernel/configs/r/android-4.14/ for 4.14-r requirements -->
<kernel version="4.19.123" level="5"/>
<!-- See kernel/configs/r/android-4.19/ for 4.19-r requirements -->
<kernel version="5.4.41" level="5"/>
<!-- See kernel/configs/r/android-5.4/ for 5.4-r requirements -->

টার্গেট FCM ভার্সন, কার্নেল FCM ভার্সন এবং কার্নেল ভার্সন একসাথে FCM থেকে কার্নেল সংক্রান্ত প্রয়োজনীয়তা বেছে নেয়:

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

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

উদাহরণ: কার্নেল কনফিগারেশন ম্যাচ করা

• <value type="string">bar</value>টি ম্যাচ "bar". মানানসই হওয়ার ম্যাট্রিক্সে কোটেশন বাদ দেওয়া হয়েছে, কিন্তু /proc/config.gz-এ সেটি রয়েছে।
• <value type="int">4096</value>, 4096, 0x1000 বা 0X1000-এর সাথে ম্যাচ করে।
• <value type="int">0x1000</value>, 4096, 0x1000 বা 0X1000-এর সাথে ম্যাচ করে।
• <value type="int">0X1000</value>, 4096, 0x1000 বা 0X1000-এর সাথে ম্যাচ করে।
• <value type="tristate">y</value>টি ম্যাচ y.
• <value type="tristate">m</value>টি ম্যাচ m।
• <value type="tristate">n</value> মানে হল config item অবশ্যই /proc/config.gz-এ থাকতে পারবে না।
• <value type="range">1-0x3</value>-এর সাথে 1, 2, বা 3, অথবা হেক্সাডেসিমেল সমতুল্য মেলে।

উদাহরণ: সফলভাবে কার্নেল ম্যাচ করা

FCM ভার্সন ১ সহ ফ্রেমওয়ার্ক কম্প্যাটিবিলিটি ম্যাট্রিক্সে নিম্নলিখিত কার্নেল সংক্রান্ত তথ্য থাকে:

<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 হিসেবে ডিফল্ট হয়ে যায় যদি প্রথমটি নির্দিষ্ট করা না থাকে:

• ডিভাইস ম্যানিফেস্টে কার্নেল ব্রাঞ্চ ১ হলে, প্রসেসটি পরবর্তী ধাপে এগিয়ে যায় এবং কার্নেল ভার্সন চেক করে।
• ডিভাইস ম্যানিফেস্টে কার্নেল ব্রাঞ্চ ২ হলে, ম্যাট্রিক্সের সাথে কোনও মিল নেই। VINTF অবজেক্ট FCM ভার্সন ২-এর পরিবর্তে ম্যাট্রিক্স থেকে কার্নেল সংক্রান্ত প্রয়োজনীয়তা পড়ে।

তারপরে, কার্নেল ভার্সন ম্যাচ করানো হয়। uname() কোনও ডিভাইস থেকে এই রিপোর্ট পেলে:

• 4.9.84 (<kernel version="4.9.x"> সহ আলাদা কার্নেল বিভাগ না থাকলে, ম্যাট্রিক্সের সাথে মিল নেই, যেখানে x <= 84)
• 4.14.41 (ম্যাট্রিক্সের সাথে মিলছে না, version-এর থেকে ছোট)
• 4.14.42 (ম্যাট্রিক্সের সাথে ম্যাচ করে)
• ৪.১৪.৪৩ (ম্যাট্রিক্সের সাথে ম্যাচ করুন)
• 4.1.22 (<kernel version="4.1.x"> সহ আলাদা কার্নেল বিভাগ না থাকলে ম্যাট্রিক্সের সাথে ম্যাচ করে না যেখানে x <= 22)

উপযুক্ত <kernel> বিভাগ বেছে নেওয়ার পরে, n ছাড়া অন্য ভ্যালু সহ প্রতিটি <config> আইটেমের জন্য, /proc/config.gz-এ সংশ্লিষ্ট এন্ট্রি থাকতে হবে; n ভ্যালু সহ প্রতিটি <config> আইটেমের জন্য, /proc/config.gz-এ সংশ্লিষ্ট এন্ট্রি থাকলে চলবে না। <value>-এর কন্টেন্ট সমান চিহ্নের পরে নিউলাইন ক্যারেক্টার বা # পর্যন্ত টেক্সটের সাথে ঠিক হুবহু মিলতে হবে (উদ্ধৃতি সহ), যার আগে ও পরে থাকা হোয়াইটস্পেস বাদ দেওয়া হয়েছে।

নিচে দেওয়া কার্নেল কনফিগারেশন হল সফল ম্যাচের একটি উদাহরণ:

# comments don't matter
CONFIG_TRI=y
# CONFIG_NOEXIST shouldn't exist
CONFIG_DEC = 4096 # trailing comments and whitespaces are fine
CONFIG_HEX=57005  # 0XDEAD == 57005
CONFIG_STR="str"
CONFIG_EMPTY=""   # empty string must have quotes
CONFIG_EXTRA="extra config items are fine too"

নিচে দেওয়া কার্নেল কনফিগারেশন হল ম্যাচ না করার একটি উদাহরণ:

CONFIG_TRI="y"   # mismatch: quotes
CONFIG_NOEXIST=y # mismatch: CONFIG_NOEXIST exists
CONFIG_HEX=0x0   # mismatch; value doesn't match
CONFIG_DEC=""    # mismatch; type mismatch (expect int)
CONFIG_EMPTY=1   # mismatch; expects ""
# mismatch: CONFIG_STR is missing

SEPolicy ম্যাচ

SEPolicy-তে নিম্নলিখিত ম্যাচ প্রয়োজন:

• <sepolicy-version> প্রতিটি মেজর ভার্সনের জন্য মাইনর ভার্সনের একটি ক্লোজড রেঞ্জ নির্ধারণ করে। ফ্রেমওয়ার্কের সাথে মানানসই হতে হলে, ডিভাইসের রিপোর্ট করা SEPolicy ভার্সন অবশ্যই এই রেঞ্জের মধ্যে থাকতে হবে। Match নিয়মগুলি HAL ভার্সনের মতো; SEPolicy ভার্সন যদি রেঞ্জের ন্যূনতম ভার্সনের সমান বা তার বেশি হয়, তাহলে তা ম্যাচ করে। সর্বাধিক ভার্সন হল সম্পূর্ণ তথ্যমূলক।
• <kernel-sepolicy-version>, অর্থাৎ, নীতি সংক্রান্ত DB ভার্সন, ডিভাইসের রিপোর্ট করা security_policyvers()-এর থেকে কম হতে হবে।

উদাহরণ: SEPolicy সফলভাবে ম্যাচ করেছে

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

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

ডিভাইসে:

• security_policyvers()-এর রিটার্ন করা ভ্যালু অবশ্যই ৩০-এর সমান বা তার চেয়ে বেশি হতে হবে। অন্যথায়, এটি ম্যাচ করবে না। যেমন:
  • কোনও ডিভাইস ২৯ রিটার্ন করলে, সেটি ম্যাচ করে না।
  • কোনও ডিভাইস ৩১ রিটার্ন করলে, সেটি ম্যাচ করে।
• SEPolicy ভার্সন অবশ্যই 25.0-∞ বা 26.0-∞ হতে হবে। তা না হলে এটি ম্যাচ করবে না। (26.0-এর পরে -3 শুধুমাত্র তথ্যমূলক।)

AVB ভার্সন ম্যাচ করে

AVB ভার্সনে একটি মেজর ভার্সন ও একটি মাইনর ভার্সন থাকে, যার ফর্ম্যাট হল মেজর.মাইনর (যেমন, 1.0, 2.1)। বিবরণের জন্য, ভার্সনিং ও কম্প্যাটিবিলিটি দেখুন। AVB ভার্সনে নিম্নলিখিত সিস্টেম প্রপার্টি আছে:

• ro.boot.vbmeta.avb_version হল বুটলোডারে থাকা libavb ভার্সন ।
• ro.boot.avb_version হল libavb ভার্সন যা Android OS (init/fs_mgr)-এ আছে।

সিস্টেম প্রপার্টি তখনই দেখা যায় যখন AVB মেটাডেটা যাচাই করার জন্য সংশ্লিষ্ট libavb ব্যবহার করা হয় (এবং OK রিটার্ন করে)। যাচাইকরণ না হলে এটি থাকে না (অথবা যাচাইকরণ একেবারেই না হলে)।

মানানসই ম্যাচ নিম্নলিখিত বিষয়গুলি তুলনা করে:

• ফ্রেমওয়ার্ক কম্প্যাটিবিলিটি ম্যাট্রিক্স থেকে avb.vbmeta-version সহ sysprop ro.boot.vbmeta.avb_version:
  • ro.boot.vbmeta.avb_version.MAJOR == avb.vbmeta-version.MAJOR
  • ro.boot.vbmeta.avb_version.MINOR >= avb.vbmeta-version.MINOR
• ফ্রেমওয়ার্ক কম্প্যাটিবিলিটি ম্যাট্রিক্স থেকে sysprop ro.boot.avb_version with avb.vbmeta-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 সহ):

ছবি ১. AVB ভার্সন ম্যাচ করে (/system হল P, বাকি সব পার্টিশন হল O)।

ছবি ২. 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 

OTA চলাকালীন AVB ভার্সন ম্যাচ করুন

Android 9 বা এর আগের যেকোনও ভার্সন সহ লঞ্চ করা ডিভাইসের ক্ষেত্রে, Android 10-এ আপডেট করার সময়, ফ্রেমওয়ার্ক কম্প্যাটিবিলিটি ম্যাট্রিক্সে AVB ভার্সন সংক্রান্ত প্রয়োজনীয়তা ডিভাইসে বর্তমান AVB ভার্সনের সাথে ম্যাচ করা হয়। OTA চলাকালীন AVB ভার্সনে কোনও মেজর ভার্সন আপগ্রেড হলে (যেমন, 0.0 থেকে 1.0), OTA-তে মানানসই হওয়ার জন্য VINTF চেক, OTA হয়ে যাওয়ার পরে মানানসই হওয়ার বিষয়টি প্রতিফলিত করে না।

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

1. Android 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 ভেন্ডর স্ন্যাপশটের সেট থেকে <vendor-ndk> ম্যাচ করা এন্ট্রি <version> খুঁজে দেখা হয়। এই ধরনের কোনও এন্ট্রি না থাকলে, কোনও ম্যাচ নেই।

এই ধরনের কোনও এন্ট্রি থাকলে, ডিভাইস কম্প্যাটিবিলিটি ম্যাট্রিক্সে উল্লেখ করা লাইব্রেরির সেটকে অবশ্যই ফ্রেমওয়ার্ক ম্যানিফেস্টে উল্লেখ করা লাইব্রেরির সেটের সাবসেট হতে হবে; তা না হলে, এন্ট্রিটি ম্যাচ হিসেবে বিবেচনা করা হবে না।

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

উদাহরণ: VNDK ভার্সন ম্যাচ করেছে

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

<!-- Example Device Compatibility Matrix -->
<vendor-ndk>
    <version>27</version>
    <library>libjpeg.so</library>
    <library>libbase.so</library>
</vendor-ndk>

ফ্রেমওয়ার্ক ম্যানিফেস্টে, শুধুমাত্র ভার্সন ২৭ সহ এন্ট্রি বিবেচনা করা হয়।

<!-- Framework Manifest Example A -->
<vendor-ndk>
    <version>27</version>
    <library>libjpeg.so</library>
    <library>libbase.so</library>
    <library>libfoo.so</library>
</vendor-ndk>

উদাহরণ 'ক' হল একটি ম্যাচ, কারণ 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 ভার্সন ২৭ থাকলেও, সেই স্ন্যাপশটে ফ্রেমওয়ার্কের মাধ্যমে libjpeg.so কাজ করে না। VNDK ভার্সন ২৬ উপেক্ষা করা হয়েছে।

সিস্টেম SDK ভার্সন ম্যাচ করে

ডিভাইস কম্প্যাটিবিলিটি ম্যাট্রিক্স compatibility-matrix.system-sdk.version-এ প্রয়োজনীয় সিস্টেম SDK ভার্সনের সেট ঘোষণা করে। প্রদত্ত সিস্টেম SDK ভার্সনের সেটটি ফ্রেমওয়ার্ক ম্যানিফেস্টে manifest.system-sdk.version-এ ঘোষণা করা হলে, তবেই ম্যাচ করা যাবে।

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

উদাহরণ: সিস্টেম SDK ভার্সন ম্যাচ করেছে

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

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

তারপরে, ফ্রেমওয়ার্ককে অবশ্যই সিস্টেম SDK ভার্সন ২৬ ও ২৭ প্রদান করতে হবে:

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

উদাহরণ'গ' ম্যাচ করছে না, কারণ সিস্টেম SDK ভার্সন ২৭ প্রদান করা হয়নি।