ম্যাচিং নিয়ম

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

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

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

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

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

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

HAL মিলে

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

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

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

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

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

2.5 সংস্করণে 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 HALs

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

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

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

সংস্করণ 5-এ 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 সংস্করণে ম্যাপ করা হয় (উদাহরণস্বরূপ, 5)। ম্যাপিং রিলিজ অক্ষর (উদাহরণস্বরূপ, R) এবং FCM সংস্করণের (উদাহরণস্বরূপ, 5) মধ্যে ম্যাপিংয়ের মতোই।

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

• কার্নেল FCM সংস্করণ লক্ষ্য FCM সংস্করণ থেকে ভিন্ন। উদাহরণস্বরূপ, উপরে উল্লিখিত ডিভাইসটির একটি লক্ষ্য FCM সংস্করণ 4 রয়েছে এবং এর কার্নেল FCM সংস্করণ 5 (কার্নেল শাখা প্রত্যয় r )।
• কার্নেল এফসিএম সংস্করণটি 5 (কার্নেল শাখা প্রত্যয় 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 সংস্করণ 5-এ নির্দিষ্ট করা হয়েছে। এই প্রয়োজনীয়তাগুলি Android সোর্স ট্রিতে kernel/configs/r/android-4.19 থেকে তৈরি করা হয়েছে।

উদাহরণ: GKI-এর জন্য কার্নেল শাখা নির্ধারণ করুন

যদি ডিভাইসটি জেনেরিক কার্নেল ইমেজ (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 অবজেক্টটি শুধুমাত্র এফসিএম থেকে <kernel> বিভাগটিকেই বিবেচনা করে যার সাথে এফসিএম সংস্করণের সাথে মিল রয়েছে ${ver} এবং ${major_rev} ডিভাইস কার্নেলের মতো (যেমন, 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 সংস্করণ এবং কার্নেল সংস্করণ একসাথে FCM থেকে কার্নেলের প্রয়োজনীয়তা নির্বাচন করে:

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

<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 , বা হেক্সাডেসিমেল সমতুল্য৷

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

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 (ম্যাট্রিক্সের সাথে কোন মিল নেই যদি না <kernel version="4.1.x"> এর সাথে একটি পৃথক কার্নেল বিভাগ না থাকে যেখানে x <= 22 )

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

নিম্নলিখিত কার্নেল কনফিগারেশন একটি সফল মিলের উদাহরণ:

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

নিম্নলিখিত কার্নেল কনফিগারেশন একটি অসফল মিলের উদাহরণ:

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

এসই নীতির সাথে মিলে যায়

SE নীতির নিম্নলিখিত মিলগুলির প্রয়োজন:

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

ডিভাইসে:

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

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

AVB সংস্করণে একটি MAJOR সংস্করণ এবং MINOR সংস্করণ রয়েছে, যার বিন্যাসটি MAJOR.MINOR (যেমন, 1.0, 2.1)। বিস্তারিত জানার জন্য, সংস্করণ এবং সামঞ্জস্যতা পড়ুন। AVB সংস্করণে নিম্নলিখিত সিস্টেম বৈশিষ্ট্য রয়েছে:

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

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

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

• ফ্রেমওয়ার্ক সামঞ্জস্যতা ম্যাট্রিক্স থেকে 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 সংস্করণ মেলে (/সিস্টেম হল 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 

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

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

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

1. অ্যান্ড্রয়েড 9 সোর্স ট্রিতে নিম্নলিখিত CLগুলিকে চেরি-পিক করুন:
   • সিএল 732261
   • সিএল 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>

উদাহরণ A একটি মিল, কারণ VNDK সংস্করণ 27 ফ্রেমওয়ার্ক ম্যানিফেস্টে রয়েছে এবং {libjpeg.so, libbase.so, libfoo.so} ⊇ {libjpeg.so, libbase.so}

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

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

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

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

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

উদাহরণ: সফল সিস্টেম SDK সংস্করণ মিল

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

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

তারপর, ফ্রেমওয়ার্ককে অবশ্যই সিস্টেম SDK সংস্করণ 26 এবং 27 মেলে দিতে হবে।

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

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

<!-- Framework Manifest Example B -->
<system-sdk>
    <version>26</version>
    <version>27</version>
    <version>28</version>
</system-sdk>

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

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

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