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

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

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

নিম্নলিখিত বিভাগগুলিতে বিভিন্ন উপাদান দ্বারা ব্যবহৃত মিলের নিয়মগুলি বিস্তারিতভাবে বর্ণনা করা হয়েছে।

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

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

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

HAL ম্যাচ

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

HIDL এবং স্থানীয় HAL গুলি

HIDL এবং নেটিভ HAL-এর জন্য ম্যাচের নিয়মগুলি নিম্নরূপ:

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

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

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

ম্যাট্রিক্স ম্যাচিং ম্যানিফেস্ট
2.5 2.5-2.∞। সামঞ্জস্য ম্যাট্রিক্সে, 2.5 হল 2.5-5 এর সংক্ষিপ্ত রূপ।
2.5-7 2.5-2.∞. নিম্নলিখিতগুলি নির্দেশ করে:
  • 2.5 হল সর্বনিম্ন প্রয়োজনীয় সংস্করণ, যার অর্থ HAL 2.0-2.4 প্রদানকারী একটি ম্যানিফেস্ট সামঞ্জস্যপূর্ণ নয়।
  • ২.৭ হল সর্বাধিক সংস্করণ যা অনুরোধ করা যেতে পারে, অর্থাৎ সামঞ্জস্যতা ম্যাট্রিক্সের মালিক (ফ্রেমওয়ার্ক বা ডিভাইস) ২.৭ এর বেশি সংস্করণের জন্য অনুরোধ করতে পারবেন না। মিলিত ম্যানিফেস্টের মালিক ২.৭ অনুরোধ করা হলেও (উদাহরণস্বরূপ) সংস্করণ ২.১০ পরিবেশন করতে পারবেন। সামঞ্জস্যতা-ম্যাট্রিক্সের মালিক কেবল জানেন যে অনুরোধ করা পরিষেবাটি API সংস্করণ ২.৭ এর সাথে সামঞ্জস্যপূর্ণ।
  • -7 শুধুমাত্র তথ্যবহুল এবং OTA আপডেট প্রক্রিয়াকে প্রভাবিত করে না।
সুতরাং, একটি ডিভাইস যার ম্যানিফেস্ট ফাইলে 2.10 সংস্করণে HAL আছে, সেটি এমন একটি ফ্রেমওয়ার্কের সাথে সামঞ্জস্যপূর্ণ থাকে যা তার সামঞ্জস্য ম্যাট্রিক্সে 2.5-7 উল্লেখ করে।

উদাহরণ: 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 HALs সম্পর্কে

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

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

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

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

ম্যাট্রিক্স ম্যাচিং ম্যানিফেস্ট
5 5-∞। সামঞ্জস্য ম্যাট্রিক্সে, 5 হল 5-5 এর সংক্ষিপ্ত রূপ।
5-7 5-∞। নিম্নলিখিতগুলি নির্দেশ করে:
  • ৫ হল সর্বনিম্ন প্রয়োজনীয় সংস্করণ, যার অর্থ HAL ১-৪ প্রদানকারী একটি ম্যানিফেস্ট সামঞ্জস্যপূর্ণ নয়।
  • ৭ হল সর্বাধিক সংস্করণ যা অনুরোধ করা যেতে পারে, অর্থাৎ সামঞ্জস্যতা ম্যাট্রিক্সের মালিক (ফ্রেমওয়ার্ক বা ডিভাইস) ৭ এর বেশি সংস্করণের জন্য অনুরোধ করবেন না। মিলিত ম্যানিফেস্টের মালিক এখনও সংস্করণ ১০ (উদাহরণস্বরূপ) পরিবেশন করতে পারেন যখন ৭ অনুরোধ করা হয়। সামঞ্জস্যতা-ম্যাট্রিক্সের মালিক কেবল জানেন যে অনুরোধ করা পরিষেবাটি API সংস্করণ ৭ এর সাথে সামঞ্জস্যপূর্ণ।
  • -7 শুধুমাত্র তথ্যবহুল এবং OTA আপডেট প্রক্রিয়াকে প্রভাবিত করে না।
সুতরাং, একটি ডিভাইস যার ম্যানিফেস্ট ফাইলে সংস্করণ ১০-এ HAL আছে, সেগুলি এমন একটি ফ্রেমওয়ার্কের সাথে সামঞ্জস্যপূর্ণ থাকে যা তার সামঞ্জস্য ম্যাট্রিক্সে 5-7 উল্লেখ করে।

উদাহরণ: একাধিক মডিউলের জন্য সফল 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> অংশটি ডিভাইসের লিনাক্স কার্নেলের ফ্রেমওয়ার্কের প্রয়োজনীয়তা বর্ণনা করে। এই তথ্যটি ডিভাইসের VINTF অবজেক্ট দ্বারা রিপোর্ট করা কার্নেল সম্পর্কিত তথ্যের সাথে মেলানোর জন্য তৈরি।

কার্নেল শাখাগুলি মেলান

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

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

  • কার্নেল FCM সংস্করণটি লক্ষ্য FCM সংস্করণ থেকে আলাদা। উদাহরণস্বরূপ, উপরে উল্লিখিত ডিভাইসটির একটি লক্ষ্য FCM সংস্করণ 4 রয়েছে এবং এর কার্নেল FCM সংস্করণটি 5 (কার্নেল শাখা প্রত্যয় r )।
  • কার্নেল FCM সংস্করণটি 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 এ নির্দিষ্ট করা আছে। এই প্রয়োজনীয়তাগুলি অ্যান্ড্রয়েড সোর্স ট্রিতে 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 অবজেক্ট শুধুমাত্র FCM থেকে <kernel> অংশটি বিবেচনা করে যার FCM সংস্করণটি ${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 থেকে কার্নেলের প্রয়োজনীয়তা নির্বাচন করে:

টার্গেট এফসিএম সংস্করণ কার্নেল এফসিএম সংস্করণ কার্নেল সংস্করণ এর সাথে মিল করুন
৩ (পি) অনির্দিষ্ট 4.4.106 কোনও মিল নেই (সংস্করণে সামান্য মিল নেই)
৩ (পি) অনির্দিষ্ট 4.4.107 4.4-p
৩ (পি) অনির্দিষ্ট 4.19.42 4.19-q (টেবিলের পরবর্তী নোট দেখুন)
৩ (পি) অনির্দিষ্ট 5.4.41 5.4-r (টেবিলের পরবর্তী নোট দেখুন)
৩ (পি) ৩ (পি) 4.4.107 4.4-p
৩ (পি) ৩ (পি) 4.19.42 কোনও মিল নেই ( 4.19-p কার্নেল শাখা নেই)
৩ (পি) ৪ (প্রশ্ন) 4.19.42 4.19-q
৪ (প্রশ্ন) অনির্দিষ্ট 4.4.107 কোনও মিল নেই ( 4.4-q কার্নেল শাখা নেই)
৪ (প্রশ্ন) অনির্দিষ্ট 4.9.165 4.9-q
৪ (প্রশ্ন) অনির্দিষ্ট 5.4.41 5.4-r (টেবিলের পরবর্তী নোট দেখুন)
৪ (প্রশ্ন) ৪ (প্রশ্ন) 4.9.165 4.9-q
৪ (প্রশ্ন) ৪ (প্রশ্ন) 5.4.41 কোনও মিল নেই (কোনও 5.4-q কার্নেল শাখা নেই)
৪ (প্রশ্ন) ৫ (আর) 4.14.105 4.14-r
৪ (প্রশ্ন) ৫ (আর) 5.4.41 5.4-r
৫ (আর) অনির্দিষ্ট যেকোনো VTS ব্যর্থ হয়েছে (লক্ষ্য FCM সংস্করণ 5 এর জন্য কার্নেল FCM সংস্করণ নির্দিষ্ট করতে হবে)
৫ (আর) ৪ (প্রশ্ন) যেকোনো VTS ব্যর্থ হয়েছে (কার্নেল FCM সংস্করণ <টার্গেট FCM সংস্করণ)
৫ (আর) ৫ (আর) 4.14.180 4.14-r

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

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

<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 )
  • ৪.১৪.৪১ (ম্যাট্রিক্সের সাথে কোন মিল নেই, version চেয়ে ছোট)
  • ৪.১৪.৪২ (ম্যাট্রিক্সের সাথে মিল)
  • ৪.১৪.৪৩ (ম্যাট্রিক্সের সাথে মিল)
  • 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 সংস্করণটি ফ্রেমওয়ার্কের সাথে সামঞ্জস্যপূর্ণ হওয়ার জন্য এই পরিসরগুলির মধ্যে একটির মধ্যে পড়তে হবে। মিলের নিয়মগুলি HAL সংস্করণের মতো; যদি SEPolicy সংস্করণটি পরিসরের জন্য সর্বনিম্ন সংস্করণের চেয়ে বেশি বা সমান হয় তবে এটি একটি মিল। সর্বাধিক সংস্করণটি সম্পূর্ণরূপে তথ্যবহুল।
  • <kernel-sepolicy-version> , অর্থাৎ, পলিসি ডিবি সংস্করণটি ডিভাইস দ্বারা রিপোর্ট করা 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() দ্বারা প্রদত্ত মান অবশ্যই 30 এর চেয়ে বেশি বা সমান হতে হবে। অন্যথায় এটি মিলবে না। উদাহরণস্বরূপ:
    • যদি কোনও ডিভাইস 29 প্রদান করে, তবে এটি কোনও মিল নয়।
    • যদি কোনও ডিভাইস 31 প্রদান করে, তবে এটি একটি মিল।
  • SEPolicy সংস্করণটি অবশ্যই 25.0-∞ অথবা 26.0-∞ এর মধ্যে একটি হতে হবে। অন্যথায় এটি কোনও মিল নয়। ( 26.0 এর পরে -3 সম্পূর্ণ তথ্যবহুল।)

AVB ভার্সন মিলছে

AVB ভার্সনে একটি MAJOR ভার্সন এবং একটি MINOR ভার্সন রয়েছে, যার ফর্ম্যাট MAJOR.MINOR (উদাহরণস্বরূপ, 1.0, 2.1)। বিস্তারিত জানার জন্য, Versioning and Compatibility দেখুন। AVB ভার্সনে নিম্নলিখিত সিস্টেম বৈশিষ্ট্য রয়েছে:

  • ro.boot.vbmeta.avb_version হল বুটলোডারের libavb সংস্করণ।
  • ro.boot.avb_version হল অ্যান্ড্রয়েড অপারেটিং সিস্টেমের 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 লাইব্রেরির দুটি কপি থাকতে পারে, প্রতিটি আপগ্রেড ডিভাইস এবং লঞ্চ ডিভাইসের জন্য আলাদা MAJOR সংস্করণ সহ। এই ক্ষেত্রে, একই স্বাক্ষরিত সিস্টেম চিত্র ভাগ করা যেতে পারে তবে চূড়ান্ত স্বাক্ষরিত সিস্টেম চিত্রগুলি আলাদা (ভিন্ন avb.vbmeta-version সহ):

চিত্র ১. AVB সংস্করণটি মিলেছে (/সিস্টেম হল 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 ভার্সনটি মেলান

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

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

  1. অ্যান্ড্রয়েড ৯ সোর্স ট্রিতে নিম্নলিখিত CL গুলি চেরি-বাছুন:
  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 (যা অ্যান্ড্রয়েড ৯ এ ব্যবহৃত হয় না)
  • 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>

উদাহরণ 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 প্রদান করা হয়নি।