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

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

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

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

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

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

توضِّح مصفوفة توافق إطار العمل معلومات الإصدار التالية لـ 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 مع قواعد حِزم HIDL وحِزم HAL الأصلية، باستثناء أنّه لا تتوفّر إصدارات رئيسية، وهناك إصدار واحد بالضبط لكل مثيل من حِزم HAL (1 إذا لم يتم تحديد الإصدار).

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

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

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

مصفوفة	ملف البيان المطابق
5	من 5 إلى ما لا نهاية: في مصفوفة التوافق، يشير الرمز 5 إلى اختصار 5-5.
5-7	‫5-∞: يشير إلى ما يلي: والرقم 5 هو الحد الأدنى من النسخة المطلوبة، ما يعني أنّ البيان الذي يقدّم المستوى 1 إلى 4 من HAL غير متوافق. يُعدّ الإصدار 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 من خدمة المراسلة عبر السحابة الإلكترونية من Firebase المستهدف، وإصدار kernel FCM هو 5 (لاحقة فرع النواة r).
• إصدار FCM للنواة أكبر من أو يساوي 5 (لاحقة فرع النواة r).

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

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

مثال: تحديد فرع النواة

إذا كان الجهاز مزوّدًا بالإصدار 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 المحدّد في الإصدار 5 من "المراسلة عبر السحابة الإلكترونية من Firebase". تم إنشاء هذه المتطلبات من kernel/configs/r/android-4.19 في شجرة مصدر Android.

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

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

5.4.42-android12-0-00544-ged21d463f856

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

لمعرفة تفاصيل حول كيفية تحليل سلسلة إصدار النواة، يمكنك الاطّلاع على تحديد إصدارات 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" المستهدَف وإصدار kernel FCM وإصدار النواة معًا يحدّد متطلبات النواة من منصات المراسلة عبر السحابة الإلكترونية من Firebase:

إصدار المراسلة عبر السحابة الإلكترونية من Firebase المستهدف	إصدار المراسلة عبر السحابة الإلكترونية من Firebase لنظام التشغيل Kernel	إصدار النواة	مطابقة مع
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 (م)	4.4.107	4.4-p
3 (م)	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)	غير محدّد	أي واحد	تعذُّر اختبار صحة الإصدار (يجب تحديد إصدار FCM للنواة لإصدار FCM المستهدف 5)
5 (R)	4 (Q)	أي واحد	تعذُّر اختبار 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="range">1-0x3</value> مع 1 أو 2 أو 3 أو ما يعادله من الأرقام السداسية العشرية.

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

تحتوي مصفوفة توافق إطار العمل مع الإصدار 1 من ميزة "المراسلة عبر السحابة الإلكترونية من Firebase" على معلومات النواة التالية:

<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 من خدمة "المراسلة عبر السحابة الإلكترونية من Firebase" بدلاً من ذلك.

بعد ذلك، تتم مطابقة إصدار النواة. إذا أبلغ جهاز في 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>

يتطابق المثال A، لأنّ الإصدار 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) للنظام

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

• وفي حالة خاصة، إذا لم يتم تعداد أي إصدارات من System 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) للنظام.