قواعد المطابقة

من المفترض أن يتم مطابقة هذين الزوجين من مصفوفات التوافق والملفات البيانية للتحقّق من أنّه يمكن استخدام الإطار الأساسي وتنفيذ المورّد معًا. يكون هذا التحقّق ناجحًا عند تطابق مصفوفة توافق الإطار مع بيان الجهاز، وكذلك بين بيان الإطار ومصفوفة توافق الجهاز.

يتم إجراء عملية التحقّق هذه في وقت الإنشاء، وعند تحديث OTA، ووقت إنشاء الحِزم، ووقت التشغيل، وفي اختبارات التوافق مع اختبارات الأمان في الجهاز.

توضّح الأقسام التالية بالتفصيل قواعد المطابقة التي تستخدمها المكوّنات المختلفة.

تطابق إصدارات مصفوفة التوافق مع الإطار

لمطابقة بيان جهاز مع مصفوفة توافق إطار العمل، يجب أن يكون إصدار FCM للإصدار العلني المحدَّد من قِبل manifest.target-level مساوًٍ تمامًا لإصدار FCM المحدَّد من قِبل compatibility-matrix.level. بخلاف ذلك، لن تتم المطابقة.

عند طلب الحصول على مصفوفة توافق الإطار باستخدام libvintf، تتم هذه المطابقة بنجاح دائمًا لأنّ libvintf يفتح بيان الجهاز ويسترجع إصدار FCM لإصدار الإصدار العلني، ويعرض مصفوفة توافق الإطار في إصدار FCM لإصدار الإصدار العلني هذا (بالإضافة إلى بعض HALs الاختيارية من مصفوفات التوافق في إصدارات FCM الأحدث).

مطابقات HAL

تحدِّد قاعدة مطابقة HAL إصدارات عناصر hal فيملف ملف الманиفيست الذي يُعتبر متوافقًا مع ملف ملف hal المتوافق.

HIDL وواجهات برمجة التطبيقات الأصلية لمستوى الحِزم

في ما يلي قواعد المطابقة لـ HIDL وواجهات HAL الأصلية.

• يتم تقييم عناصر <hal> المتعددة باستخدام علاقة و واحدة.
• يمكن أن تحتوي عناصر <hal> على <hal optional="true"> لوضع علامة عليها كثانيًا غير مطلوبة. تحذير: لم تعُد هذه الميزة optional متاحة بعد Android 15
• تتضمّن <hal> واحدة عدّة عناصر <version> ضمن <hal> نفسها، وتربطها ببعضها علاقة أو. إذا تم تحديد إصدارَين أو أكثر، يجب تنفيذ أحد الإصدارَين فقط. (اطّلِع على مثال إدارة الحقوق الرقمية أدناه).
• يتم تقييم عناصر <instance> و <regex-instance> المتعددة ضمن <hal> نفسه باستخدام علاقة AND واحدة عندما يكون <hal> مطلوبًا. (اطّلِع على <ahref="#drm">مثال على إدارة الحقوق الرقمية أدناه.)</ahref="#drm">

مثال: مطابقة HAL ناجحة لمكوّن

بالنسبة إلى HAL في الإصدار 2.5، تكون قاعدة المطابقة على النحو التالي:

مصفوفة	ملف البيان المطابق
2.5	‫2.5-2.∞. في مصفوفة التوافق، يشير الرمز 2.5 إلى 2.5-5.
2.5-7	‫2.5-2.∞: يشير إلى ما يلي: الإصدار 2.5 هو الحد الأدنى للإصدار المطلوب، ما يعني أنّ ملف البيان الذي يقدّم HAL 2.0-2.4 غير متوافق. 2.7 هو الحد الأقصى للإصدار الذي يمكن طلبه، ما يعني أنّ مالك مصفوفة التوافق (إطار العمل أو الجهاز) لن يطلب إصدارات أحدث من 2.7. سيظل بإمكان مالك البيان المطابق عرض الإصدار 2.10 (على سبيل المثال) عند طلب الإصدار 2.7. لا يعرف مالك مصفوفة التوافق سوى أنّ الخدمة المطلوبة متوافقة مع الإصدار 2.7 من واجهة برمجة التطبيقات. يُستخدم الرمز -7 لأغراض إعلامية فقط ولا يؤثر في عملية التحديث عبر OTA. وبالتالي، يظل الجهاز الذي يستخدم الإصدار 2.10 من HAL في ملف البيان متوافقًا مع إطار عمل يشير إلى 2.5-7 في مصفوفة التوافق.

مثال: مطابقة 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

تتوافق جميع إصدارات Android الأحدث من Android 11 (باستثناء Android 11) مع إصدارات واجهات برمجة التطبيقات لـ AIDL HAL في VINTF. تشبه قواعد المطابقة لحِزم HAL المستندة إلى واجهة برمجة التطبيقات AIDL قواعد حِزم HAL المستندة إلى واجهة برمجة التطبيقات HIDL والحِزم الأصلية، باستثناء أنّه لا تتوفّر إصدارات رئيسية، وهناك إصدار واحد بالضبط لكل مثيل من حِزم HAL (1 إذا لم يتم تحديد الإصدار).

• يتم تقييم عناصر <hal> المتعددة باستخدام علاقة و واحدة.
• يمكن أن تحتوي عناصر <hal> على <hal optional="true"> لتمييزها على أنّها غير مطلوبة. تحذير: لم تعُد هذه الميزة optional متاحة بعد الإصدار 15 من Android.
• يتم تقييم عناصر <instance> و <regex-instance> المتعددة ضمن <hal> نفسه باستخدام علاقة AND واحدة عندما يكون <hal> مطلوبًا. (اطّلِع على مثال <ahref="#vibrator">الهزّاز أدناه.)</ahref="#vibrator">

مثال: مطابقة HAL ناجحة لمكوّن

بالنسبة إلى HAL في الإصدار 5، تكون قاعدة المطابقة على النحو التالي:

مصفوفة	ملف البيان المطابق
5	من 5 إلى ما لا نهاية: في مصفوفة التوافق، يشير الرمز 5 إلى اختصار 5-5.
5-7	‫5-∞: يشير إلى ما يلي: 5 هو الحد الأدنى للإصدار المطلوب، ما يعني أنّ البيان الذي يقدّم HAL من الإصدار 1 إلى 4 غير متوافق. يُعدّ الإصدار 7 هو الحد الأقصى للإصدار الذي يمكن طلبه، ما يعني أنّ مالك مصفوفة التوافق (إطار العمل أو الجهاز) لن يطلب إصدارات أعلى من 7. سيظل بإمكان مالك البيان المطابق عرض الإصدار 10 (على سبيل المثال) عند طلب الإصدار 7. لا يعرف مالك مصفوفة التوافق سوى أنّ الخدمة المطلوبة متوافقة مع الإصدار 7 من واجهة برمجة التطبيقات. يُستخدم الرمز -7 لأغراض إعلامية فقط ولا يؤثر في عملية التحديث عبر OTA. وبالتالي، يظل الجهاز الذي يستخدم الإصدار 10 من HAL في ملف البيان متوافقًا مع إطار عمل يشير إلى 5-7 في مصفوفة التوافق.

مثال: مطابقة 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 للجهاز.

مطابقة فروع النواة

يتم ربط كل إضافة لفرع kernel (مثل 5.4-r) بإصدار فريدة لنظام FCM في kernel (مثل 5). يكون التعيين مطابقًا للتعيين بين أحرف الإصدار (مثل R) وإصدارات FCM (مثل 5).

تفرض اختبارات VTS أن يحدِّد الجهاز صراحةً إصدار FCM للنواة فيملف بيان الجهاز/vendor/etc/vintf/manifest.xml، إذا كان أحد الشروط التالية صحيحًا:

• يختلف إصدار FCM للنواة عن إصدار FCM المستهدَف. على سبيل المثال، يحتوي الجهاز المذكور أعلاه على الإصدار 4 من حزمة FCM المستهدفة، وإصدار حزمة FCM لنظام التشغيل هو 5 (لاحقة الفرع للنواة هي r).
• إصدار FCM للنواة أكبر من أو يساوي 5 (لاحقة فرع النواة r).

ملاحظة: إذا كان إصدار FCM في النواة يساوي إصدار FCM المستهدَف وكانا أكبر من 5 أو مساوياً له، لا يحتاج ملف مصدر بيان الجهاز الذي يحدّده DEVICE_MANIFEST_FILE إلى تحديد إصدار FCM في النواة. assemble_vintf يستنتج تلقائيًا إصدار FCM للنواة من إصدار FCM المستهدَف إذا كان إصدار FCM المستهدَف أكبر من أو يساوي 5.

تفرض اختبارات VTS أن يكون إصدار FCM في النواة، في حال تحديده، أكبر من أو يساوي إصدار FCM المستهدَف في بيان الجهاز.

مثال: تحديد فرع kernel

إذا كان الجهاز يحتوي على الإصدار 4 من خدمة "المراسلة عبر السحابة الإلكترونية من Firebase" المستهدَف (الذي تم إصداره في Android 10)، ولكنه يشغّل نواة من الفرع 4.19-r، يجب أن يحدِّد بيان الجهاز ما يلي:

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

يتحقّق عنصر VINTF من توافق النواة مع المتطلبات في 4.19-r kernel branch، المحدّدة في الإصدار 5 من FCM. تم إنشاء هذه المتطلبات من kernel/configs/r/android-4.19 في شجرة مصدر Android.

مثال: تحديد فرع kernel لـ GKI

إذا كان الجهاز يستخدم صورة Kernel Generic Image (GKI)، وكانت سلسلة إصدار kernel من /proc/version هي كما يلي:

5.4.42-android12-0-00544-ged21d463f856

بعد ذلك، يحصل عنصر VINTF على إصدار Android من إصدار kernel، ويستخدمه لتحديد إصدار FCM لنظام التشغيل kernel. في هذا المثال، يشير android12 إلى الإصدار 6 من FCM لنظام التشغيل kernel (تم إصداره في Android 12).

لمعرفة التفاصيل حول كيفية تحليل سلسلة إصدار kernel، يُرجى الاطّلاع على إصدار GKI.

مطابقة إصدارات النواة

يمكن أن تتضمّن المصفوفة أقسام <kernel> متعددة، ولكل منها سمة version مختلفة باستخدام التنسيق:

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

لا يأخذ عنصر VINTF في الاعتبار سوى قسم <kernel> من FCM الذي يتطابق مع إصدار FCM الذي يتضمّن ${ver} و${major_rev} نفسهما مثل نواة الجهاز (أي version="${ver}.${major_rev}.${matrix_minor_rev}")، ويتم تجاهل الأقسام الأخرى. بالإضافة إلى ذلك، يجب أن تكون النسخة الثانوية من kernel قيمة من مصفوفة التوافق (${kernel_minor_rev} >= ${matrix_minor_rev};). إذا لم يستوفِ أي قسم من <kernel> هذه المتطلبات، يعني ذلك أنّه لا يتطابق.

مثال: اختيار متطلبات المطابقة

نوضّح في ما يلي الحالة الافتراضية التالية التي تُعلن فيها رسائل FCM في /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 -->

يختار الإصدار المستهدَف من واجهة المراسلة عبر السحابة الإلكترونية من Firebase وإصدار واجهة المراسلة عبر السحابة الإلكترونية من Firebase الخاص بالنواة وإصدار النواة معًا متطلبات النواة من واجهات المراسلة عبر السحابة الإلكترونية من Firebase:

إصدار "مراسلة Firebase السحابية" المستهدَف	إصدار Kernel FCM	إصدار النواة	مطابقة مع
3 (P)	غير محدّد	4.4.106	لا تتطابق (عدم تطابق الإصدار الثانوي)
3 (P)	غير محدّد	4.4.107	4.4-p
3 (P)	غير محدّد	4.19.42	4.19-q (راجِع الملاحظة أدناه)
3 (P)	غير محدّد	5.4.41	5.4-r (راجِع الملاحظة أدناه)
3 (P)	3 (P)	4.4.107	4.4-p
3 (P)	3 (P)	4.19.42	لا تتوفّر مطابقة (لا يتوفّر فرع 4.19-p للنواة)
3 (P)	4 (س)	4.19.42	4.19-q
4 (س)	غير محدّد	4.4.107	لا تتوفّر مطابقة (لا يتوفّر فرع 4.4-q للنواة)
4 (س)	غير محدّد	4.9.165	4.9-q
4 (س)	غير محدّد	5.4.41	5.4-r (راجِع الملاحظة أدناه)
4 (س)	4 (س)	4.9.165	4.9-q
4 (س)	4 (س)	5.4.41	لا تتوفّر مطابقة (لا يتوفّر فرع 5.4-q للنواة)
4 (س)	5 (R)	4.14.105	4.14-r
4 (س)	5 (R)	5.4.41	5.4-r
5 (R)	غير محدّد	أي واحد	تعذُّر اجتياز اختبار VTS (يجب تحديد إصدار FCM للنواة لإصدار FCM المستهدف 5)
5 (R)	4 (س)	أي واحد	تعذُّر اختبار VTS (إصدار FCM للنواة أقل من إصدار FCM المستهدَف)
5 (R)	5 (R)	4.14.180	4.14-r

ملاحظة: بالنسبة إلى الأجهزة التي تستخدم إصدارًا مستهدَفًا من حزمة FCM أقل من 5 (R) وإصدارًا غير محدّد من حزمة FCM للنواة، يختار عنصر VIOLTF فرع النواة الذي يحتوي على اللاحقة الأدنى التي تكون أكبر من الإصدار المستهدَف من حزمة FCM مع إصدار النواة المطابق. في المثال أعلاه، يستخدم الجهاز الذي يعمل بالإصدار المستهدَف من حزمة FCM الذي يبلغ 3 (P) فرع 4.19-q من نواة النظام لأنّ 4.19-q يحتوي على اللاحقة الأقل يليًا من بين جميع فروع 4.19-* من نواة النظام، [4.19-q, 4.19-r, 4.19-s]. لا يُسمح بسلوك اختيار المتطلّبات هذا للأجهزة التي تعمل بالإصدار 5 (R) من إطار عمل Firebase للرسائل أو إصدارًا متعاقباً، لأنّه يجب تحديد إصدار إطار عمل Firebase للرسائل في kernel.

مطابقة إعدادات النواة

إذا تطابق قسم <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> يعني أنّه يجب ألّا يكون /proc/config.gz يحتوي على <value type="tristate">n</value>.
• يتطابق <value type="range">1-0x3</value> مع 1 أو 2 أو 3 أو ما يعادله من الأرقام السداسية العشرية.

مثال على مطابقة نواة ناجحة

تحتوي مصفوفة توافق الإطار مع الإصدار 1 من "نظام إدارة إشعارات Google" على معلومات النواة التالية:

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

تتم مطابقة فرع النواة أولاً. يتم تحديد فرع kernel في ملف بيان الجهاز في manifest.kernel.target-level، والذي يتم ضبطه تلقائيًا على manifest.level في حال عدم تحديد الأول. إذا كان فرع kernel في ملف بيان الجهاز:

• هو 1، ينتقل إلى الخطوة التالية ويتحقّق من إصدار kernel.
• هو 2، ما مِن مطابقة مع المصفوفة. تقرأ كائنات VINTF متطلبات النواة من المصفوفة في الإصدار 2 من إطار عمل إدارة الموافقة بدلاً من ذلك.

بعد ذلك، تتم مطابقة إصدار النواة. إذا أبلغ جهاز في uname() عن:

• 4.9.84 (لا تتطابق مع المصفوفة ما لم يكن هناك قسم نواة منفصل يحتوي على <kernel version="4.9.x">، حيث x <= 84)
• 4.14.41 (لا تتطابق مع المصفوفة، أصغر من version)
• ‎4.14.42 (match to matrix)
• ‎4.14.43 (match to matrix)
• 4.1.22 (لا تتطابق مع المصفوفة ما لم يكن هناك قسم نواة منفصل مع <kernel version="4.1.x"> حيث x <= 22)

بعد اختيار قسم <kernel> المناسب، بالنسبة إلى كل <config> له قيمة غير n، نتوقع أن يكون الإدخال المقابل متوفّرًا في /proc/config.gz. بالنسبة إلى كل <config> له قيمة n، نتوقع أن لا يكون الإدخال المقابل متوفّرًا في /proc/config.gz. نتوقع أن يتطابق محتوى <value> تمامًا مع النص بعد علامة التساوي (بما في ذلك علامات الاقتباس)، حتى حرف سطر جديد أو #، مع اقتطاع المسافات البيضاء البادئة واللاحقة.

إعدادات kernel التالية هي مثال على مطابقة ناجحة:

# 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"

إعدادات kernel التالية هي مثال على عدم نجاح المطابقة:

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

تتطلّب سياسة SE المطابقات التالية:

• <sepolicy-version> تحدِّد نطاقًا مغلقًا من الإصدارات الثانوية لكل إصدار رئيسي. يجب أن يقع إصدار سياسة الأمان الذي يُبلغ عنه الجهاز ضمن أحد النطاقَين التاليَين لكي يكون متوافقًا مع إطار العمل. تتشابه قواعد المطابقة مع إصدارات HAL، ويكون هناك تطابق إذا كان إصدار سياسة الأمان أعلى من الحد الأدنى للإصدار أو يساويه. يكون الإصدار الأقصى معلوماتيًا فقط.
• <kernel-sepolicy-version> أي إصدار policydb يجب أن تكون أقل من 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 إلى ما لا نهاية. وإلا لن يكون هناك مطابقة. (الرمز "-3" بعد "26.0" هو رمز إعلامي بحت).

تطابق إصدار AVB

يحتوي إصدار AVB على إصدار MAJOR وإصدار MINOR، بالتنسيق MAJOR.MINOR (مثل 1.0 و2.1). لمعرفة التفاصيل، يُرجى الاطّلاع على مقالة إدارة الإصدارات والتوافق. يتضمّن إصدار AVB خصائص النظام التالية:

• ro.boot.vbmeta.avb_version هو إصدار libavb في برنامج الإقلاع
• ‫ro.boot.avb_version هو الإصدار libavb من نظام التشغيل Android (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
• ‫sysprop ro.boot.avb_version مع avb.vbmeta-version من مصفوفة توافق الإطار
  • ro.boot.avb_version.MAJOR == avb.vbmeta-version.MAJOR
  • ro.boot.avb_version.MINOR >= avb.vbmeta-version.MINOR

قد يحتوي مشغّل الإقلاع أو نظام التشغيل Android على نسختَين من libavb المكتبات، ولكل منهما إصدار رئيسي مختلف للأجهزة التي يتم ترقيتها وأجهزة الإطلاق. في هذه الحالة، يمكن مشاركة صورة النظام غير الموقَّعة نفسها، ولكن تختلف صور النظام الموقَّعة النهائية (باختلاف avb.vbmeta-version):

الشكل 1: تطابق إصدار AVB (/system هو P، وجميع الأقسام الأخرى هي O).

الشكل 2: تطابق إصدار AVB (جميع الأقسام هي P).

مثال: مطابقة ناجحة لإصدار بروتوكول AVB

توضِّح مصفوفة التوافق مع إطار العمل معلومات AVB التالية:

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

على الجهاز:

ro.boot.avb_version              == 1.0 &&
ro.boot.vbmeta.avb_version       == 2.1  mismatch 

ro.boot.avb_version              == 2.1 &&
ro.boot.vbmeta.avb_version       == 3.0  mismatch 

ro.boot.avb_version              == 2.1 &&
ro.boot.vbmeta.avb_version       == 2.3  match 

ro.boot.avb_version              == 2.3 &&
ro.boot.vbmeta.avb_version       == 2.1  match 

مطابقة إصدار AVB أثناء التحديث عبر الهواء

ملاحظة: لا ينطبق هذا القسم على الأجهزة التي يتم تحديثها إلى Android 11.

بالنسبة إلى الأجهزة التي تم إطلاقها مع الإصدار 9 من نظام التشغيل Android أو إصدار أقدم، عند التحديث إلى الإصدار 10 من نظام التشغيل Android، تتم مطابقة متطلبات إصدار AVB في مصفوفة توافق الإطار مع الإصدار الحالي من AVB على الجهاز. إذا تم ترقية إصدار AVB إلى إصدار رئيسي أثناء تحديث عبر الهواء (على سبيل المثال، من 0.0 إلى 1.0)، لا يعكس فحص VINTF للتوافق في التحديث عبر الهواء مدى التوافق بعد التحديث عبر الهواء.

للحدّ من هذه المشكلة، يمكن لمصنّع المعدّات الأصلية وضع إصدار AVB مزيّف في حزمة OTA (compatibility.zip) لاجتياز عملية التحقّق. لإجراء ذلك:

1. اختَر الطلبات التالية من "طلبات التعديل" وأدرِجها في شجرة مصدر Android 9:
   • CL 732261
   • CL 732262
2. حدِّد BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE للجهاز. يجب أن تساوي قيمته إصدار AVB قبل التحديث عبر الهواء، أي إصدار AVB للجهاز عند إطلاقه.
3. أعِد إنشاء حزمة OTA.

تؤدي هذه التغييرات تلقائيًا إلى وضع BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE كملف compatibility-matrix.avb.vbmeta-version في الملفات التالية:

• /system/compatibility_matrix.xml (الذي لا يتم استخدامه في Android 9) على الجهاز
• system_matrix.xml في compatibility.zip في حزمة OTA

لا تؤثّر هذه التغييرات في مصفوفات التوافق الأخرى مع إطار العمل، بما في ذلك /system/etc/vintf/compatibility_matrix.xml. بعد تحديث الجهاز عبر الهواء، يتم استخدام القيمة الجديدة في /system/etc/vintf/compatibility_matrix.xml لإجراء عمليات التحقّق من التوافق بدلاً من ذلك.

تطابق إصدار مجموعة تطوير البرامج الأصلية للمورّدين (VNDK)

توضِّح مصفوفة توافق الأجهزة إصدار VNDK المطلوب في compatibility-matrix.vendor-ndk.version. إذا لم تتضمّن ملف تعريف التوافق الخاص بالجهاز علامة <vendor-ndk>، لن يتم فرض أي متطلبات، وبالتالي يُعتبَر مطابقًا دائمًا.

إذا كانت مصفوفة توافق الأجهزة تحتوي على علامة <vendor-ndk> ، يتم البحث عن إدخال <vendor-ndk> يتضمّن <version> مطابقًا من مجموعة لقطات المصنّعين لـ VNDK التي يوفّرها إطار العمل في بيان إطار العمل. إذا لم يكن هناك إدخال مماثل، لن تتم المطابقة.

وفي حال توفّر مثل هذا الإدخال، يجب أن تكون مجموعة المكتبات التي تم تعدادها في مصفوفة توافق الأجهزة مجموعة فرعية من مجموعة المكتبات المذكورة في بيان إطار العمل، وإلا لا يُعتبر الإدخال مطابقًا.

• في حال عدم إدراج أي مكتبات في مصفوفة توافق الجهاز، يُعتبر الإدخال مطابقًا دائمًا، لأنّ المجموعة الفارغة هي مجموعة فرعية من أي مجموعة.

مثال: مطابقة ناجحة لإصدار VNDK

إذا كانت مصفوفة توافق الأجهزة تشير إلى الشرط التالي بشأن حزمة VNDK:

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

في بيان الإطار، لا يتمّ اعتبار سوى الإدخال الذي يتضمّن الإصدار 27.

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

يتطابق المثال "أ"، لأنّ الإصدار 27 من VNDK متوفر في بيان إطار العمل، و{libjpeg.so, libbase.so, libfoo.so} ⊇ {libjpeg.so, libbase.so}.

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

المثال (ب) غير مطابق. على الرغم من أنّ إصدار VNDK 27 متوفر في بيان إطار العمل، لا يتيح إطار العمل استخدام libjpeg.so في لقطة الشاشة هذه. يتم تجاهل الإصدار 26 من حزمة VNDK.

تطابق إصدار حزمة تطوير البرامج (SDK) للنظام

توضِّح مصفوفة توافق الأجهزة مجموعة من إصدارات حِزم تطوير البرامج (SDK) المطلوبة لنظام التشغيل في compatibility-matrix.system-sdk.version. لا يحدث مطابقة إلا إذا كانت المجموعة هي مجموعة فرعية من إصدارات حزمة تطوير البرامج (SDK) للنظام المقدَّمة كما هو موضّح في manifest.system-sdk.version في بيان إطار العمل.

• في حال عدم إدراج أي إصدارات من حِزم تطوير البرامج (SDK) للنظام في مصفوفة توافق الأجهزة، يتم دائمًا اعتبارها مطابقة، لأنّ مجموعة الفارغة هي مجموعة فرعية من أي مجموعة.

مثال: مطابقة ناجحة لإصدار حزمة SDK للنظام

إذا كانت مصفوفة توافق الأجهزة تشير إلى الشرط التالي في System SDK:

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

بعد ذلك، يجب أن يقدّم إطار العمل الإصدارَين 26 و27 من حزمة 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>

لا يتطابق المثال "ج"، لأنّه لا يتضمّن الإصدار 27 من حزمة تطوير البرامج (SDK) للنظام.