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

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

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

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

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

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

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

مباريات HAL

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

HIDL و HALs الأصلية

قواعد المطابقة لـ HIDL و HALs الأصلية هي كما يلي.

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

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

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

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

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

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

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

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

مثال: مطابقة HAL الناجحة لوحدات نمطية متعددة

تنص مصفوفة توافق إطار العمل على معلومات الإصدار التالية لـ HALs الهزاز والكاميرا:

<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

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

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

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

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

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

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

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

إذا كان الجهاز يستهدف الإصدار 4 من FCM (تم إصداره في Android 10) ، ولكنه يقوم بتشغيل kernel من الفرع 4.19-r ، فيجب أن يحدد بيان الجهاز ما يلي:

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

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

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

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

5.4.42-android12-0-00544-ged21d463f856

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

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

تطابق إصدارات kernel

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

مثال: حدد متطلبات المطابقة

ضع في اعتبارك الحالة الافتراضية التالية حيث تعلن FCMs في /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 المستهدف وإصدار kernel FCM وإصدار kernel معًا متطلبات kernel من نماذج FCM:

تطابق تكوينات النواة

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

مثال: تطابق تكوينات kernel

• <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 أو ما يعادله سداسي عشري.

مثال: تطابق kernel ناجح

تحتوي مصفوفة توافق الإطار مع الإصدار 1 من FCM على معلومات kernel التالية:

<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 أولاً. يتم تحديد فرع kernel في بيان الجهاز في manifest.kernel.target-level ، والذي يتم تعيينه افتراضيًا على مستوى manifest.level إذا لم يتم تحديد السابق. إذا كان فرع النواة في بيان الجهاز:

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

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

• 4.9.84 (لا يوجد تطابق مع المصفوفة ما لم يكن هناك قسم kernel منفصل مع <kernel version="4.9.x"> ، حيث x <= 84 )
• 4.14.41 (لا يوجد تطابق مع المصفوفة ، أصغر من version )
• 4.14.42 (تطابق المصفوفة)
• 4.14.43 (تطابق المصفوفة)
• 4.1.22 (لا يوجد تطابق مع المصفوفة ما لم يكن هناك قسم kernel منفصل مع <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 ؛ إنها مطابقة إذا كان إصدار sepolicy أعلى أو يساوي الحد الأدنى لإصدار النطاق. النسخة القصوى إعلامية بحتة.
• <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 (على سبيل المثال ، 1.0 ، 2.1). للحصول على تفاصيل ، راجع الإصدار والتوافق . يحتوي إصدار AVB على خصائص النظام التالية:

• ro.boot.vbmeta.avb_version هي نسخة libavb في أداة تحميل التشغيل
• ro.boot.avb_version هو إصدار libavb في نظام التشغيل Android OS ( 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 مختلف):

مثال: تطابق إصدار 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 أثناء OTA

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

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

1. قم باختيار CLs التالية لشجرة مصدر Android 9:
   • CL 732261
   • CL 732262
2. حدد BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE للجهاز. يجب أن تساوي قيمته إصدار AVB قبل OTA ، أي إصدار 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 .zip في حزمة OTA

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

مباريات إصدار VNDK

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

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

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

يطابق إصدار System SDK

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

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

مثال: تطابق إصدار System SDK الناجح

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

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

بعد ذلك ، يجب أن يوفر إطار العمل System SDK الإصدار 26 و 27 للمطابقة.

<!-- 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 من System SDK.