قوانین مسابقه

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

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

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

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

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

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

مسابقات HAL

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

HIDL و HAL های بومی

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

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

هال‌های AIDL

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

• چندین عنصر <hal> با یک رابطه AND ارزیابی می‌شوند.
• عناصر <hal> می‌توانند دارای <hal optional="true"> باشند تا آنها را به عنوان غیر ضروری علامت‌گذاری کنند.
• چندین عنصر <instance> و <regex-instance> درون یک <hal> در صورت نیاز به <hal> با یک رابطه AND ارزیابی می‌شوند. ( برای چندین ماژول به بخش «تطبیق موفقیت‌آمیز 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> در ماتریس سازگاری چارچوب، الزامات چارچوب برای هسته لینوکس روی دستگاه را شرح می‌دهد. این اطلاعات قرار است با اطلاعات مربوط به هسته که توسط شیء VINTF دستگاه گزارش می‌شود، مطابقت داده شود.

شاخه‌های هسته را تطبیق دهید

هر پسوند شاخه هسته (برای مثال، 5.4- r ) به یک نسخه منحصر به فرد FCM هسته (برای مثال، 5) نگاشت می‌شود. این نگاشت همانند نگاشت بین حروف انتشار (برای مثال، R) و نسخه‌های FCM (برای مثال، 5) است.

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

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

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

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

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

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

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

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

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

5.4.42-android12-0-00544-ged21d463f856

سپس، شیء VINTF نسخه اندروید را از نسخه هسته دریافت می‌کند و از آن برای تعیین نسخه FCM هسته استفاده می‌کند. در این مثال، android12 به معنای نسخه 6 FCM هسته (منتشر شده در اندروید 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 دستگاه در manifest.kernel.target-level مشخص شده است، که اگر مورد اول مشخص نشده باشد، به طور پیش‌فرض manifest.level است:

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

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

• ۴.۹.۸۴ (هیچ تطابقی با ماتریس وجود ندارد، مگر اینکه یک بخش هسته جداگانه با <kernel version="4.9.x"> وجود داشته باشد، که در آن x <= 84 )
• ۴.۱۴.۴۱ (با ماتریس مطابقت ندارد، کوچکتر از version است)
• ۴.۱۴.۴۲ (مطابقت با ماتریس)
• ۴.۱۴.۴۳ (مطابقت با ماتریس)
• ۴.۱.۲۲ (هیچ تطابقی با ماتریس وجود ندارد، مگر اینکه یک بخش هسته جداگانه با <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

مسابقات SEPolicy

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

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

نسخه AVB شامل یک نسخه MAJOR و یک نسخه MINOR است که فرمت آن MAJOR.MINOR است (برای مثال، ۱.۰، ۲.۱). برای جزئیات بیشتر، به بخش «نسخه‌بندی و سازگاری» مراجعه کنید. نسخه AVB دارای ویژگی‌های سیستمی زیر است:

• ro.boot.vbmeta.avb_version نسخه libavb در بوت لودر است.
• ro.boot.avb_version نسخه libavb در سیستم عامل اندروید ( init/fs_mgr ) است.

ویژگی system فقط زمانی ظاهر می‌شود که 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

بوت لودر یا سیستم عامل اندروید ممکن است شامل دو کپی از کتابخانه‌های 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 مطابقت دهید

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

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

1. CL های زیر را به صورت گزینشی به درخت سورس اندروید ۹ اضافه کنید:
   • سی ال ۷۳۲۲۶۱
   • سی ال ۷۳۲۲۶۲
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 (که در اندروید ۹ استفاده نمی‌شود) روی دستگاه
• 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>

مثال الف منطبق است، زیرا 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 نادیده گرفته می‌شود.

نسخه 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>

سپس، چارچوب باید 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 مطابقت ندارد، زیرا SDK سیستم نسخه ۲۷ ارائه نشده است.