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

تنظيم صفحاتك في مجموعات يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.

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

يتم إجراء عملية التحقّق هذه في وقت الإنشاء، وعند تحديث 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>، وتربطها ببعضها علاقة أو. إذا تم تحديد إصدارَين أو أكثر، يجب تنفيذ أحد الإصدارَين فقط. (اطّلِع على مثال إدارة الحقوق الرقمية أدناه).
• يتم تقييم عناصر <instance> و <regex-instance> المتعددة ضمن <hal> نفسه باستخدام علاقة AND واحدة عندما يكون <hal> مطلوبًا. (اطّلِع على <ahref="#drm">مثال على إدارة الحقوق الرقمية أدناه.)</ahref="#drm">

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

بالنسبة إلى 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

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

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

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

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

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

تفرض اختبارات 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 ، والذي تم تحديده في الإصدار 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:

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

إذا تطابق قسم <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> تحدِّد نطاقًا مغلقًا من الإصدارات الثانوية لكل إصدار رئيسي. يجب أن يقع إصدار sepolicy الذي يُبلغ عنه الجهاز ضمن أحد النطاقَين التاليَين لكي يكون متوافقًا مع إطار العمل. تتشابه قواعد المطابقة مع إصدارات 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 أثناء التحديث عبر الهواء

بالنسبة إلى الأجهزة التي تم إطلاقها مع الإصدار 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 من حزمة System 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) للنظام.