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

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

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

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

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

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

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

HAL matches

تحدّد قاعدة المطابقة مع HAL إصدارات عناصر hal في ملف بيان التي يعتبرها مالك مصفوفة التوافق المقابلة متوافقة.

HIDL وواجهات HAL الأصلية

في ما يلي قواعد المطابقة الخاصة بطبقات HAL الأصلية وHIDL:

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

مثال: تطابق ناجح في طبقة تجريد الأجهزة (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 HAL

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

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

مثال: تطابق ناجح في طبقة تجريد الأجهزة (HAL) لأحد الوحدات

بالنسبة إلى طبقة تجريد الأجهزة (HAL) الإصدار 5، تكون قاعدة المطابقة كما يلي:

مثال: تطابق ناجح لطبقة تجريد الأجهزة (HAL) مع وحدات متعددة

توضّح مصفوفة توافق إطار العمل معلومات الإصدار التالية لأجهزة HAL الخاصة بالمهزاز والكاميرا:

<hal>
    <name>android.hardware.vibrator
    <version>1-2</version>
    <interface>
        <name>IVibrator</name>
        <instance>default</instance>
        <instance>specific</instance>
    </interface>
</hal>
<hal>
    <name>android.hardware.camera
    <version>5</version>
    <interface>
        <name>ICamera</name>
        <instance>default</instance>
        <regex-instance>[a-z]+/[0-9]+</regex-instance>
    </interface>
</hal>

على المورّد تنفيذ جميع الحالات التالية:

android.hardware.vibrator.IVibrator/default     // version >= 1
android.hardware.vibrator.IVibrator/specific    // version >= 1
android.hardware.camera.ICamera/default         // version >= 5
android.hardware.camera.ICamera/${INSTANCE}
            // with version >= 5, where ${INSTANCE} matches [a-z]+/[0-9]+
            // e.g. legacy/0

نتائج مطابقة النواة

يوضّح القسم <kernel> من مصفوفة التوافق مع إطار العمل متطلبات إطار العمل لنواة Linux على الجهاز. من المفترض أن تتم مطابقة هذه المعلومات مع المعلومات المتعلقة بالنواة التي يتم الإبلاغ عنها من خلال عنصر VINTF الخاص بالجهاز.

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

يتم ربط كل لاحقة لفرع النواة (مثل 5.4-r) بإصدار فريد من النواة في FCM (مثل 5). تكون عملية الربط هي نفسها عملية الربط بين الحروف الدالة على الإصدار (مثل R) وإصدارات FCM (مثل 5).

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

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

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

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

إذا كان الجهاز يتضمّن الإصدار 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 من FCM. تم إنشاء هذه المتطلبات من kernel/configs/r/android-4.19 في شجرة مصدر Android.

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

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

5.4.42-android12-0-00544-ged21d463f856

بعد ذلك، يحصل عنصر VINTF على إصدار Android من إصدار النواة، ويستخدمه لتحديد إصدار FCM للنواة. في هذا المثال، يعني android12 الإصدار 6 من FCM لنواة النظام (الذي تم إصداره في 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_minor_rev} >= ${matrix_minor_rev}). وإذا لم يستوفِ أي قسم <kernel> هذه المتطلبات، لن يتم العثور على تطابق.

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

لنفترض الحالة الافتراضية التالية حيث تعلن منصات إدارة الموافقة في /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 -->

يتم تحديد متطلبات النواة من خلال إصدار FCM المستهدف وإصدار FCM للنواة وإصدار النواة معًا، وذلك على النحو التالي:

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

إذا تطابق القسم <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 من 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 إلى متطلبات النواة من المصفوفة في الإصدار 2 من FCM بدلاً من ذلك.

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

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

بعد اختيار القسم <kernel> المناسب، يجب أن يكون الإدخال المقابل متوفّرًا في /proc/config.gz لكل عنصر <config> بقيمة غير n، ويجب ألا يكون الإدخال المقابل متوفّرًا في /proc/config.gz لكل عنصر <config> بقيمة n. يجب أن يتطابق محتوى <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 matches

تتطلّب سياسة 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-∞، وإلا لن يكون متوافقًا. (إنّ -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 (ويتم عرض OK). لا يكون هذا الحقل متوفّرًا في حال تعذُّر إثبات الملكية (أو في حال عدم إجراء عملية إثبات الملكية على الإطلاق).

تقارن المطابقة مع الأجهزة المتوافقة ما يلي:

• ‫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 أثناء التحديث عبر الأثير (OTA) (على سبيل المثال، من 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 في حزمة التحديث عبر اتصال لاسلكي

لا تؤثر هذه التغييرات في مصفوفات توافق الأُطر الأخرى، بما في ذلك /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>

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

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

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

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

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

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

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