قوانین مطابقت

دو جفت ماتریس سازگاری و مانیفست برای تطبیق دادن و تأیید اینکه پیاده‌سازی چارچوب و فروشنده می‌توانند با یکدیگر کار کنند درنظر گرفته شده‌اند. این درستی‌سنجی درصورت مطابقت بین ماتریس سازگاری چارچوب و مانیفست دستگاه، و همچنین بین مانیفست چارچوب و ماتریس سازگاری دستگاه موفقیت‌آمیز است.

این درستی‌سنجی در زمان ساخت، در زمان تولید بسته به‌روزرسانی ازطریق هوا، در زمان راه‌اندازی، و در آزمایش‌های سازگاری VTS انجام می‌شود.

بخش‌های زیر قوانین مطابقت مورد استفاده توسط اجزای مختلف را به‌تفصیل شرح می‌دهند.

نسخه ماتریس سازگاری چارچوب مطابقت دارد

برای مطابقت دادن مانیفست دستگاه با ماتریس سازگاری چارچوب، نسخه FCM ارسال مشخص‌شده توسط manifest.target-level باید دقیقاً با نسخه FCM مشخص‌شده توسط compatibility-matrix.level برابر باشد. درغیراین‌صورت، هیچ تطابقی وجود ندارد.

وقتی ماتریس سازگاری چارچوب با libvintf درخواست می‌شود، این مطابقت همیشه موفقیت‌آمیز است زیرا libvintf مانیفست دستگاه را باز می‌کند، نسخه FCM ارسال را بازیابی می‌کند، و ماتریس سازگاری چارچوب را در آن نسخه FCM ارسال برمی‌گرداند (به‌علاوه برخی‌از HALهای اختیاری از ماتریس‌های سازگاری در نسخه‌های بالاتر FCM).

تطابق‌های HAL

قانون تطابق HAL نسخه‌های عناصر hal را در فایل مانیفست که مالک ماتریس سازگاری مربوطه آن‌ها را پشتیبانی‌شده می‌داند شناسایی می‌کند.

‫HIDL و HAL بومی

قوانین مطابقت برای HIDL و HAL بومی به شرح زیر است:

• چندین عنصر <hal> با یک رابطه AND ارزیابی می‌شوند.
• عناصر <hal> می‌توانند <hal optional="true"> داشته باشند تا به‌عنوان غیرالزامی علامت‌گذاری شوند.
• چندین عنصر <version> در یک عنصر <hal> رابطه یا دارند. اگر دو یا چند نسخه مشخص شده باشد، فقط یکی از نسخه‌ها باید پیاده‌سازی شود. (به مطابقت موفقیت‌آمیز HAL برای واحد DRM مراجعه کنید.)
• چندین عنصر <instance> و <regex-instance> در یک عنصر <hal> با رابطه و واحد ارزیابی می‌شوند، درصورتی‌که <hal> الزامی باشد. (به مطابقت موفق HAL برای واحد DRM مراجعه کنید.)

مثال: مطابقت موفق HAL برای یک ماژول

برای HAL در نسخه ۲.۵، قانون مطابقت به‌صورت زیر است:

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

‫HALهای AIDL

Android و نسخه‌های بالاتر از نسخه‌های AIDL HAL در VINTF پشتیبانی می‌کنند. قوانین مطابقت برای AIDL HAL شبیه به قوانین HIDL و HAL بومی است، با این تفاوت که نسخه‌های اصلی وجود ندارد و دقیقاً یک نسخه برای هر نمونه HAL وجود دارد (1 اگر نسخه مشخص نشده باشد):

• چندین عنصر <hal> با یک رابطه AND ارزیابی می‌شوند.
• ‫<hal> عنصر می‌تواند <hal optional="true"> داشته باشد تا به‌عنوان غیرالزامی علامت‌گذاری شود.
• چندین عنصر <instance> و <regex-instance> در یک <hal> با رابطه و واحدی ارزیابی می‌شوند، درصورتی‌که <hal> الزامی باشد. (مطابقت موفق HAL برای چند مدول را ببینید.)

مثال: مطابقت موفقیت‌آمیز HAL برای یک واحد

برای 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 هسته یکتا (برای نمونه، ۵) نگاشت می‌شود. این نگاشت همانند نگاشت بین حروف نسخه پخش (برای مثال، R) و نسخه‌های FCM (برای مثال، ۵) است.

آزمایش‌های VTS اعمال می‌کنند که دستگاه به‌طور صریح نسخه FCM هسته را در مانیفست دستگاه، /vendor/etc/vintf/manifest.xml، مشخص کند، اگر یکی از موارد زیر درست باشد:

• نسخه FCM هسته با نسخه FCM هدف متفاوت است. برای مثال، دستگاه مذکور دارای FCM هدف نسخه ۴ است و FCM هسته آن نسخه ۵ است (پسوند شاخه هسته r).
• نسخه FCM هسته بزرگ‌تر یا مساوی ۵ است (پسوند شاخه هسته r).

آزمایش‌های VTS اعمال می‌کنند که اگر نسخه FCM هسته مشخص شده باشد، نسخه FCM هسته بزرگ‌تر یا مساوی با نسخه FCM هدف در مانیفست دستگاه باشد.

مثال: تعیین شاخه هسته

اگر دستگاه دارای FCM هدف نسخه ۴ (منتشرشده در Android 10) باشد، اما هسته را از شاخه 4.19-r اجرا کند، مانیفست دستگاه باید موارد زیر را مشخص کند:

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

شیء VINTF سازگاری هسته را دربرابر الزامات شاخه هسته 4.19-r که در نسخه ۵ FCM مشخص شده است بررسی می‌کند. این الزامات از kernel/configs/r/android-4.19 در درخت منبع Android ساخته شده است.

مثال: تعیین شاخه هسته برای GKI

اگر دستگاه از «تصویر هسته عمومی» (GKI) استفاده می‌کند و رشته نسخه هسته از /proc/version به‌صورت زیر است:

5.4.42-android12-0-00544-ged21d463f856

سپس، شیء VINTF نسخه Android را از نسخه هسته دریافت می‌کند و از آن برای تعیین نسخه FCM هسته استفاده می‌کند. در این مثال، android12 به‌معنای نسخه ۶ 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> این الزامات را برآورده نکند، مطابقت پیدا نمی‌کند.

مثال: انتخاب الزامات برای مطابقت

مورد فرضی زیر را درنظر بگیرید که در آن 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 -->

نسخه FCM هدف، نسخه FCM هسته، و نسخه هسته با هم الزامات هسته را از FCMها انتخاب می‌کنند:

پیکربندی‌های هسته منطبق

اگر بخش <kernel> مطابقت داشته باشد، فرایند با تلاش برای مطابقت دادن عناصر config با /proc/config.gz ادامه می‌یابد. برای هر عنصر پیکربندی در ماتریس سازگاری، /proc/config.gz را جستجو می‌کند تا ببیند پیکربندی وجود دارد یا نه. وقتی یک عنصر پیکربندی در ماتریس سازگاری برای بخش <kernel> منطبق روی n تنظیم می‌شود، باید در /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، یا معادل شانزده‌شانزدهی.

مثال: مطابقت موفق هسته

ماتریس سازگاری چارچوب با 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 استفاده می‌شود:

• اگر شاخه هسته در مانیفست دستگاه ۱ باشد، فرایند به مرحله بعدی می‌رود و نسخه هسته را بررسی می‌کند.
• اگر شاخه هسته در مانیفست دستگاه ۲ باشد، هیچ تطابقی با ماتریس وجود ندارد. اشیاء VINTF به‌جای آن، الزامات هسته را از ماتریس در نسخه ۲ FCM می‌خوانند.

سپس نسخه هسته مطابقت داده می‌شود. اگر دستگاهی در uname() گزارش دهد:

• ‫4.9.84 (با ماتریس مطابقت ندارد، مگراینکه بخش هسته جداگانه‌ای با <kernel version="4.9.x"> وجود داشته باشد، که در آن x <= 84)
• ‫۴.۱۴.۴۱ (با ماتریس مطابقت ندارد، کوچک‌تر از version)
• ‫۴.۱۴.۴۲ (مطابقت با ماتریس)
• ‫۴.۱۴.۴۳ (مطابقت با ماتریس)
• ‫4.1.22 (با ماتریس مطابقت ندارد، مگراینکه بخش هسته جداگانه‌ای با <kernel version="4.1.x"> وجود داشته باشد، که در آن x <= 22)

پس‌از انتخاب بخش <kernel> مناسب، برای هر عنصر <config> با مقداری غیر از n، ورودی مربوطه باید در /proc/config.gz وجود داشته باشد؛ برای هر عنصر <config> با مقدار n، ورودی مربوطه نباید در /proc/config.gz وجود داشته باشد. محتوای <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

تطابق‌های «خط‌مشی امنیتی Android»

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() باید بزرگ‌تر یا مساوی با ۳۰ باشد. درغیراین‌صورت، مطابقت ندارد. برای مثال:
  • اگر دستگاهی ۲۹ را برگرداند، مطابقت ندارد.
  • اگر دستگاه عدد ۳۱ را برگرداند، یعنی مطابقت دارد.
• نسخه SEPolicy باید یکی از 25.0-∞ یا 26.0-∞ باشد. درغیراین‌صورت مطابقت ندارد. (-3 بعداز 26.0 صرفاً اطلاعاتی است.)

نسخه AVB مطابقت دارد

نسخه AVB شامل نسخه اصلی و نسخه فرعی است، با قالب اصلی.فرعی (برای مثال، ۱.۰، ۲.۱). برای جزئیات، به نسخه‌بندی و سازگاری مراجعه کنید. نسخه 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 باشد که هرکدام نسخه MAJOR متفاوتی برای دستگاه‌های ارتقایافته و دستگاه‌های راه‌اندازی‌شده دارند. در این حالت، تصویر سیستم امضانشده یکسان می‌تواند هم‌رسانی شود اما تصاویر سیستم امضاشده نهایی متفاوت هستند (با avb.vbmeta-version متفاوت):

شکل ۱. نسخه AVB مطابقت دارد (/system‏ P است، همه پارتیشن‌های دیگر O هستند).

شکل ۲. نسخه 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 درطول OTA

برای دستگاه‌هایی که با Android نسخه ۹ یا پایین‌تر عرضه شده‌اند، هنگام به‌روزرسانی به Android نسخه ۱۰، الزامات نسخه AVB در ماتریس سازگاری چارچوب با نسخه فعلی AVB در دستگاه مطابقت داده می‌شود. اگر نسخه AVB درطول OTA ارتقای نسخه اصلی داشته باشد (برای مثال، از ۰.۰ به ۱.۰)، بررسی VINTF برای سازگاری در OTA سازگاری پس‌از OTA را منعکس نمی‌کند.

برای کاهش مشکل، سازنده اصلی محصول می‌تواند نسخه جعلی AVB را در بسته OTA قرار دهد (compatibility.zip) تا بررسی را بگذراند. برای انجام این کار:

1. CLهای زیر را برای درخت منبع 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 در بسته OTA

این تغییرات بر دیگر ماتریس‌های سازگاری چارچوب، ازجمله /system/etc/vintf/compatibility_matrix.xml، تأثیر نمی‌گذارد. پس‌از OTA، مقدار جدید در /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>

در مانیفست چارچوب، فقط ورودی با نسخه ۲۷ درنظر گرفته می‌شود.

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

مثال A مطابقت دارد، زیرا نسخه ۲۷ از 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 در مانیفست چارچوب وجود دارد، libjpeg.so در آن نمونه فوری توسط چارچوب پشتیبانی نمی‌شود. VNDK نسخه ۲۶ نادیده گرفته می‌شود.

نسخه «کیت توسعه نرم‌افزار سیستم» مطابقت دارد

ماتریس سازگاری دستگاه مجموعه‌ای از نسخه کیت توسعه نرم‌افزار سیستم موردنیاز را در compatibility-matrix.system-sdk.version اعلام می‌کند. فقط درصورتی مطابقت وجود دارد که مجموعه زیرمجموعه‌ای از نسخه‌های کیت توسعه نرم‌افزار سیستم ارائه‌شده باشد، همان‌طور که در manifest.system-sdk.version در مانیفست چارچوب اعلام شده است.

• به‌عنوان یک مورد خاص، اگر هیچ نسخه SDK سیستمی در ماتریس سازگاری دستگاه فهرست نشده باشد، همیشه به‌عنوان مطابقت درنظر گرفته می‌شود، زیرا مجموعه خالی زیرمجموعه هر مجموعه‌ای است.

مثال: مطابقت موفق نسخه کیت توسعه نرم‌افزار سیستم

اگر ماتریس سازگاری دستگاه الزام زیر را در «کیت توسعه نرم‌افزار سیستم» ذکر کرده باشد:

<!-- Example Device Compatibility Matrix -->
<system-sdk>
    <version>26</version>
    <version>27</version>
</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>

«مثال B» مطابقت دارد:

<!-- Framework Manifest Example C -->
<system-sdk>
    <version>26</version>
</system-sdk>

«مثال C» مطابقت ندارد، زیرا نسخه ۲۷ کیت توسعه نرم‌افزار سیستم ارائه نشده است.