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

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

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

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

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

برای تطبیق مانیفست دستگاه با ماتریس سازگاری چارچوب، نسخه Shipping 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 دارند. اگر دو یا چند مورد مشخص شده باشد، فقط یکی از نسخه ها باید پیاده سازی شود. ( مثال 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

AND همچنین باید همه این موارد را پیاده سازی کند:

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 11 (به استثنای Android 11) از نسخه‌های AIDL HAL در VINTF پشتیبانی می‌کنند. قوانین تطبیق برای HAL های AIDL مشابه قوانین HIDL و HAL های بومی است، با این تفاوت که هیچ نسخه اصلی وجود ندارد و دقیقاً یک نسخه برای هر نمونه HAL وجود دارد (اگر نسخه نامشخص باشد، 1 ).

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

با شاخه های هسته مطابقت دهید

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

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

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

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

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

اگر دستگاه دارای FCM نسخه 4 (منتشر شده در Android 10) است، اما هسته را از شاخه 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 در درخت منبع Android ساخته شده اند.

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

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

5.4.42-android12-0-00544-ged21d463f856

سپس، شی VINTF نسخه اندروید را از نسخه هسته دریافت می کند و از آن برای تعیین نسخه FCM هسته استفاده می کند. در این مثال، android12 به معنای هسته FCM نسخه 6 (منتشر شده در اندروید 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 نسخه 1 دارای اطلاعات هسته زیر است:

<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 الزامات هسته را از ماتریس در FCM نسخه 2 می خواند.

سپس، نسخه هسته مطابقت داده می شود. اگر دستگاهی در 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> مناسب، برای هر آیتم <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

سیاست SE مطابقت دارد

خط مشی SE به موارد زیر نیاز دارد:

• <sepolicy-version> محدوده بسته ای از نسخه های فرعی را برای هر نسخه اصلی تعریف می کند. نسخه sepolicy گزارش شده توسط دستگاه باید در یکی از این محدوده ها قرار گیرد تا با چارچوب سازگار باشد. قوانین مسابقه مشابه نسخه های 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 با قالب MAJOR.MINOR (مثلاً 1.0، 2.1) است. برای جزئیات، به نسخه سازی و سازگاری مراجعه کنید. نسخه 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 مختلف):

شکل 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 در طول OTA مطابقت دهید

برای دستگاه‌هایی که با Android 9 یا پایین‌تر راه‌اندازی می‌شوند، هنگام به‌روزرسانی به Android 10، الزامات نسخه AVB در ماتریس سازگاری چارچوب با نسخه AVB فعلی دستگاه مطابقت دارد. اگر نسخه AVB دارای یک ارتقاء نسخه اصلی در طول OTA باشد (به عنوان مثال، از 0.0 به 1.0)، بررسی VINTF برای سازگاری در OTA سازگاری پس از OTA را منعکس نمی کند.

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

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

در مانیفست چارچوب، فقط ورودی با نسخه 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 مطابقت دارد، زیرا VNDK نسخه 27 در مانیفست چارچوب است و {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>

مثال B مطابقت ندارد. حتی اگر VNDK نسخه 27 در مانیفست چارچوب است، libjpeg.so توسط چارچوب موجود در آن عکس فوری پشتیبانی نمی‌شود. VNDK نسخه 26 نادیده گرفته شده است.

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

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

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

مثال: مطابقت موفق نسخه SDK سیستم

اگر ماتریس سازگاری دستگاه شرایط زیر را در System SDK بیان می‌کند:

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

سپس، چارچوب باید سیستم 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>

مثال B یک مسابقه است.

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

مثال C مطابقت ندارد، زیرا سیستم SDK نسخه 27 ارائه نشده است.

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

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

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

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

برای تطبیق مانیفست دستگاه با ماتریس سازگاری چارچوب، نسخه Shipping 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 دارند. اگر دو یا چند مورد مشخص شده باشد، فقط یکی از نسخه ها باید پیاده سازی شود. ( مثال 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

AND همچنین باید همه این موارد را پیاده سازی کند:

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 11 (به استثنای Android 11) از نسخه‌های AIDL HAL در VINTF پشتیبانی می‌کنند. قوانین تطبیق برای HAL های AIDL مشابه قوانین HIDL و HAL های بومی است، با این تفاوت که هیچ نسخه اصلی وجود ندارد و دقیقاً یک نسخه برای هر نمونه HAL وجود دارد (اگر نسخه نامشخص باشد، 1 ).

• Multiple <hal> elements are evaluated with a single AND relationship.
• <hal> elements can have <hal optional="true"> to mark them as not required.
• Multiple <instance> and <regex-instance> elements within the same <hal> are evaluated with a single AND relationship when the <hal> is required. (نگاه کنید به مثال ویبراتور در زیر.)

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

For a HAL at version 5, the match rule is as follows:

Example: Successful HAL match for multiple modules

The framework compatibility matrix states the following version information for vibrator and camera 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

مسابقات هسته

The <kernel> section of the framework compatibility matrix describes the framework's requirements of the Linux kernel on the device. This information is meant to be matched against the information about the kernel that gets reported by the device's VINTF object.

با شاخه های هسته مطابقت دهید

Each kernel branch suffix (for example, 5.4- r ) is mapped to a unique kernel FCM version (for example, 5). The mapping is the same as the mapping between release letters (for example, R) and FCM versions (for example, 5).

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

• The kernel FCM version is different from the target FCM version. For example, the aforementioned device has a target FCM version 4, and its kernel FCM version is 5 (kernel branch suffix r ).
• The kernel FCM version is greater than or equal to 5 (kernel branch suffix r ).

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

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

اگر دستگاه دارای FCM نسخه 4 (منتشر شده در Android 10) است، اما هسته را از شاخه 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 در درخت منبع Android ساخته شده اند.

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

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

5.4.42-android12-0-00544-ged21d463f856

سپس، شی VINTF نسخه اندروید را از نسخه هسته دریافت می کند و از آن برای تعیین نسخه FCM هسته استفاده می کند. در این مثال، android12 به معنای هسته FCM نسخه 6 (منتشر شده در اندروید 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 نسخه 1 دارای اطلاعات هسته زیر است:

<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 الزامات هسته را از ماتریس در FCM نسخه 2 می خواند.

سپس، نسخه هسته مطابقت داده می شود. اگر دستگاهی در 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> مناسب، برای هر آیتم <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

سیاست SE مطابقت دارد

خط مشی SE به موارد زیر نیاز دارد:

• <sepolicy-version> محدوده بسته ای از نسخه های فرعی را برای هر نسخه اصلی تعریف می کند. نسخه sepolicy گزارش شده توسط دستگاه باید در یکی از این محدوده ها قرار گیرد تا با چارچوب سازگار باشد. قوانین مسابقه مشابه نسخه های HAL هستند. اگر نسخه sepolicy بالاتر یا برابر با حداقل نسخه برای محدوده باشد، مطابقت دارد. حداکثر نسخه کاملاً اطلاعاتی است.
• <kernel-sepolicy-version> یعنی نسخه Policydb. Must be less than the security_policyvers() reported by the device.

مثال: مطابقت موفق خط مشی SE

The framework compatibility matrix states the following sepolicy information:

<sepolicy>
    <kernel-sepolicy-version>30</kernel-sepolicy-version>
    <sepolicy-version>25.0</sepolicy-version>
    <sepolicy-version>26.0-3</sepolicy-version>
</sepolicy>

روی دستگاه:

• The value returned by security_policyvers() must be greater than or equal to 30. Otherwise it isn't a match. به عنوان مثال:
  • اگر دستگاهی 29 را برگرداند، مطابقت ندارد.
  • اگر دستگاهی 31 را برگرداند، مطابقت دارد.
• SE Policy version must be one of 25.0-∞ or 26.0-∞. در غیر این صورت یک مسابقه نیست. (The " -3 " after " 26.0 " is purely informational.)

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

The AVB version contains a MAJOR version and MINOR version, with the format as MAJOR.MINOR (eg, 1.0, 2.1). For details, refer to Versioning and Compatibility . نسخه AVB دارای ویژگی های سیستم زیر است:

• ro.boot.vbmeta.avb_version is the libavb version in bootloader
• ro.boot.avb_version is the libavb version in Android OS ( init/fs_mgr )

The system property appears only when the corresponding libavb has been used to verify AVB metadata (and returns OK). It is absent if a verification failure occurred (or no verification occurred at all).

A compatibility match compares the following:

• sysprop ro.boot.vbmeta.avb_version with avb.vbmeta-version from framework compatibility matrix;
  • 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 with avb.vbmeta-version from framework compatibility matrix.
  • ro.boot.avb_version.MAJOR == avb.vbmeta-version.MAJOR
  • ro.boot.avb_version.MINOR >= avb.vbmeta-version.MINOR

سیستم عامل Bootloader یا Android ممکن است حاوی دو نسخه از کتابخانه های libavb باشد که هر یک نسخه اصلی متفاوت برای دستگاه های به روزرسانی و دستگاه های راه اندازی دارند. در این حالت ، همان تصویر سیستم بدون امضا می تواند به اشتراک گذاشته شود اما تصاویر سیستم امضا شده نهایی متفاوت هستند (با avb.vbmeta-version مختلف):

Figure 1. AVB version matches (/system is P, all other partitions are O).

Figure 2. AVB version matches (all partitions are P).

Example: Successful AVB version match

ماتریس سازگاری چارچوب اطلاعات 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 در ماتریس سازگاری Framework با نسخه AVB فعلی در دستگاه مطابقت دارد. اگر نسخه AVB در طی OTA (به عنوان مثال ، از 0.0 به 1.0) نسخه اصلی نسخه اصلی را داشته باشد ، بررسی VINTF برای سازگاری در OTA ، سازگاری پس از OTA را منعکس نمی کند.

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

1. Cherry CLS زیر را به درخت منبع Android 9 انتخاب کنید:
   • CL 732261
   • Cl 732262
2. BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE برای دستگاه تعریف کنید. Its value should equal the AVB version before the OTA, that is, the AVB version of the device when it was launched.
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 که توسط چارچوب در مانیفست چارچوب ارائه شده است ، جستجو می شود. اگر چنین ورودی وجود نداشته باشد ، هیچ مسابقه ای وجود ندارد.

اگر چنین ورودی وجود داشته باشد ، مجموعه ای از کتابخانه های ذکر شده در ماتریس سازگاری دستگاه باید زیر مجموعه ای از مجموعه کتابخانه ها باشد که در مانیفست چارچوب بیان شده است. otherwise, the entry isn't considered a match.

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

مثال: موفقیت آمیز نسخه 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 یک مسابقه است ، زیرا نسخه VNDK 27 در چارچوب مانیفست است ، و {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>

مثال B مطابقت ندارد. حتی اگر VNDK نسخه 27 در چارچوب آشکار باشد ، libjpeg.so توسط چارچوب در آن عکس فوری پشتیبانی نمی شود. نسخه VNDK 26 نادیده گرفته می شود.

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

Then, the framework must provide System SDK version 26 and 27 to match.

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

مثال A یک مسابقه است.

<!-- 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 مطابقت ندارد ، زیرا سیستم SDK نسخه 27 ارائه نشده است.

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

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

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

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

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

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

مسابقات هال

قانون Hal-Match نسخه های عناصر hal را در یک پرونده آشکار که توسط صاحب ماتریس سازگاری مربوطه پشتیبانی می شود ، مشخص می کند.

HIDL و HALS بومی

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

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

Example: Successful HAL match for a module

برای 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

All Android versions later than Android 11 (excluding Android 11) supports versions for AIDL HALs in VINTF. قوانین مسابقه برای Aidl HAL ها شبیه به HIDL و HAL های بومی است ، به جز این که نسخه اصلی وجود ندارد ، و دقیقاً یک نسخه در هر نمونه HAL وجود دارد ( 1 اگر نسخه نامشخص باشد).

• عناصر چندگانه <hal> با یک رابطه و یک رابطه ارزیابی می شوند.
• <hal> عناصر می توانند <hal optional="true"> را برای علامت گذاری آنها مطابق آنچه لازم نیست ، داشته باشند.
• عناصر چند <instance> و <regex-instance> در همان <hal> در صورت نیاز به <hal> با یک رابطه و رابطه ارزیابی می شوند. (نگاه کنید به ویبراتور مثال زیر.)

مثال: مسابقه HAL موفق برای یک ماژول

برای HAL در نسخه 5 ، قانون مسابقه به شرح زیر است:

مثال: مسابقه موفقیت آمیز HAL برای ماژول های متعدد

ماتریس سازگاری Framework اطلاعات نسخه زیر را برای ویبراتور و 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>

A vendor must implement all of these instances:

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 نسخه 4 است و نسخه هسته آن FCM 5 (پسوند شاخه هسته r ) است.
• نسخه هسته FCM بیشتر از یا برابر با 5 است (پسوند شاخه هسته r ).

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

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

اگر دستگاه دارای Target FCM نسخه 4 (منتشر شده در 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 ساخته شده است.

Example: Determine the kernel branch for GKI

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

5.4.42-android12-0-00544-ged21d463f856

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

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

اگر بخش <kernel> مطابقت داشته باشد ، این روند با تلاش برای مطابقت با عناصر config در برابر /proc/config.gz ادامه می یابد. برای هر عنصر پیکربندی در ماتریس سازگاری ، به نظر می رسد Up /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> matches 4096 or 0x1000 or 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 نسخه 1 اطلاعات هسته زیر را دارد:

<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 Objects نیازهای هسته را از ماتریس در نسخه FCM 2 می خواند.

سپس ، نسخه هسته مطابقت دارد. اگر دستگاهی در 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> مناسب ، برای هر مورد <config> با مقدار غیر از n ، انتظار داریم که ورودی مربوطه در /proc/config.gz حضور داشته باشد. for each <config> item with value n , we expect the corresponding entry to not be present in /proc/config.gz . ما انتظار داریم که محتوای <value> دقیقاً با متن پس از علامت برابر (از جمله نقل قول ها) ، تا شخصیت Newline یا # ، مطابقت داشته باشد.

پیکربندی هسته زیر نمونه ای از یک مسابقه موفق است:

# 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

مسابقات خط مشی

سیاست SE به مسابقات زیر نیاز دارد:

• <sepolicy-version> طیف بسته ای از نسخه های جزئی را برای هر نسخه اصلی تعریف می کند. نسخه Sepolicy گزارش شده توسط دستگاه باید در یکی از این محدوده ها قرار بگیرد تا با چارچوب سازگار باشد. قوانین مسابقه مشابه نسخه های HAL است. it is a match if the sepolicy version is higher or equal to the minimum version for the range. حداکثر نسخه کاملاً اطلاع رسانی است.
• <kernel-sepolicy-version> IE نسخه PolicyDB. باید کمتر از security_policyvers() گزارش شده توسط دستگاه باشد.

مثال: مسابقه موفقیت آمیز SE 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 یا برابر با 30 باشد. در غیر این صورت یک مسابقه نیست. به عنوان مثال:
  • اگر دستگاه 29 را برگرداند ، مسابقه نیست.
  • اگر دستگاه 31 بازگردد ، یک مسابقه است.
• نسخه خط مشی SE باید یکی از 25.0-∞ یا 26.0-∞ باشد. در غیر این صورت مسابقه نیست. (" -3 " پس از " 26.0 " صرفاً اطلاعاتی است.)

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

نسخه AVB حاوی نسخه اصلی و نسخه جزئی است ، با فرمت به عنوان major.minor (به عنوان مثال ، 1.0 ، 2.1). For details, refer to Versioning and Compatibility . نسخه AVB دارای ویژگی های سیستم زیر است:

• ro.boot.vbmeta.avb_version نسخه libavb در bootloader است
• 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

سیستم عامل Bootloader یا Android ممکن است حاوی دو نسخه از کتابخانه های libavb باشد که هر یک نسخه اصلی متفاوت برای دستگاه های به روزرسانی و دستگاه های راه اندازی دارند. در این حالت ، همان تصویر سیستم بدون امضا می تواند به اشتراک گذاشته شود اما تصاویر سیستم امضا شده نهایی متفاوت هستند (با avb.vbmeta-version مختلف):

شکل 1. مطابقت نسخه AVB (/سیستم 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 در طول OTA مطابقت داشته باشید

برای دستگاه های راه اندازی شده با Android 9 یا پایین ، هنگام بروزرسانی در Android 10 ، مورد نیاز نسخه AVB در ماتریس سازگاری Framework با نسخه AVB فعلی در دستگاه مطابقت دارد. اگر نسخه AVB در طی OTA (به عنوان مثال ، از 0.0 به 1.0) نسخه اصلی نسخه اصلی را داشته باشد ، بررسی VINTF برای سازگاری در OTA ، سازگاری پس از OTA را منعکس نمی کند.

To mitigate the issue, an OEM can place a fake AVB version in the OTA package ( compatibility.zip ) to pass the check. برای انجام این کار:

1. Cherry 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 در بسته OTA

این تغییرات بر سایر ماتریس های سازگاری چارچوب ، از جمله /system/etc/vintf/compatibility_matrix.xml تأثیر نمی گذارد. پس از OTA ، از مقدار جدید در /system/etc/vintf/compatibility_matrix.xml برای بررسی های سازگاری استفاده می شود.

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

ماتریس سازگاری دستگاه نسخه VNDK مورد نیاز را در compatibility-matrix.vendor-ndk.version اعلام می کند. If the device compatibility matrix doesn't have a <vendor-ndk> tag, no requirements are imposed, and hence it's always considered a match.

اگر ماتریس سازگاری دستگاه دارای یک برچسب <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 یک مسابقه است ، زیرا نسخه VNDK 27 در چارچوب مانیفست است ، و {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>

مثال B مطابقت ندارد. حتی اگر VNDK نسخه 27 در چارچوب آشکار باشد ، libjpeg.so توسط چارچوب در آن عکس فوری پشتیبانی نمی شود. نسخه VNDK 26 نادیده گرفته می شود.

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

The device compatibility matrix declares a set of required System SDK version in 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>

سپس ، چارچوب باید سیستم SDK نسخه 26 و 27 را برای مطابقت با آن فراهم کند.

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

مثال A یک مسابقه است.

<!-- 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 مطابقت ندارد ، زیرا سیستم SDK نسخه 27 ارائه نشده است.

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

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

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

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

برای مطابقت با یک دستگاه مانیفست با یک ماتریس سازگاری چارچوب ، نسخه حمل و نقل FCM مشخص شده توسط manifest.target-level باید دقیقاً برابر با نسخه FCM مشخص شده توسط compatibility-matrix.level باشد. Otherwise there's no match.

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

مسابقات هال

قانون Hal-Match نسخه های عناصر hal را در یک پرونده آشکار که توسط صاحب ماتریس سازگاری مربوطه پشتیبانی می شود ، مشخص می کند.

HIDL و HALS بومی

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

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

مثال: مسابقه 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 HAL ها شبیه به HIDL و HAL های بومی است ، به جز این که نسخه اصلی وجود ندارد ، و دقیقاً یک نسخه در هر نمونه HAL وجود دارد ( 1 اگر نسخه نامشخص باشد).

• عناصر چندگانه <hal> با یک رابطه و یک رابطه ارزیابی می شوند.
• <hal> elements can have <hal optional="true"> to mark them as not required.
• عناصر چند <instance> و <regex-instance> در همان <hal> در صورت نیاز به <hal> با یک رابطه و رابطه ارزیابی می شوند. (نگاه کنید به ویبراتور مثال زیر.)

مثال: مسابقه HAL موفق برای یک ماژول

برای HAL در نسخه 5 ، قانون مسابقه به شرح زیر است:

مثال: مسابقه موفقیت آمیز HAL برای ماژول های متعدد

ماتریس سازگاری Framework اطلاعات نسخه زیر را برای ویبراتور و 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> ماتریس سازگاری چارچوب ، نیازهای چارچوب هسته لینوکس را در دستگاه توصیف می کند. این اطلاعات به معنای مطابقت با اطلاعات مربوط به هسته است که توسط شیء VINTF دستگاه گزارش می شود.

شاخه های هسته

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

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

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

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

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

اگر دستگاه دارای Target FCM نسخه 4 (منتشر شده در 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 ساخته شده است.

Example: Determine the kernel branch for GKI

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

5.4.42-android12-0-00544-ged21d463f856

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

Match kernel configurations

If the <kernel> section does match, the process continues by attempting to match config elements against /proc/config.gz . For each config element in the compatibility matrix, it looks up /proc/config.gz to see if the config is present. When a config item is set to n in the compatibility matrix for the matching <kernel> section, it must be absent from /proc/config.gz . Finally, a config item not in the compatibility matrix might or might not be present in /proc/config.gz .

Example: Match kernel configurations

• <value type="string">bar</value> matches "bar" . Quotes are omitted in the compatibility matrix but present in /proc/config.gz .
• <value type="int">4096</value> matches 4096 or 0x1000 or 0X1000 .
• <value type="int">0x1000</value> matches 4096 or 0x1000 or 0X1000 .
• <value type="int">0X1000</value> matches 4096 or 0x1000 or 0X1000 .
• <value type="tristate">y</value> matches y .
• <value type="tristate">m</value> matches m .
• <value type="tristate">n</value> means the config item must NOT exist in /proc/config.gz .
• <value type="range">1-0x3</value> matches 1 , 2 , or 3 , or hexadecimal equivalent.

Example: Successful kernel match

A framework compatibility matrix with FCM version 1 has the following kernel information:

<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>

The kernel branch is matched first. The kernel branch is specified in the device manifest in manifest.kernel.target-level , which defaults to manifest.level if the former isn't specified. If the kernel branch in the device manifest:

• is 1, proceeds to the next step and checks kernel version.
• is 2, no match to matrix. VINTF objects reads kernel requirements from matrix at FCM version 2 instead.

Then, the kernel version is matched. If a device in uname() reports:

• 4.9.84 (no match to matrix unless there's a separate kernel section with <kernel version="4.9.x"> , where x <= 84 )
• 4.14.41 (no match to matrix, smaller than version )
• 4.14.42 (match to matrix)
• 4.14.43 (match to matrix)
• 4.1.22 (no match to matrix unless there's a separate kernel section with <kernel version="4.1.x"> where x <= 22 )

After the appropriate <kernel> section is selected, for each <config> item with value other than n , we expect the corresponding entry to be present in /proc/config.gz ; for each <config> item with value n , we expect the corresponding entry to not be present in /proc/config.gz . We expect the content of <value> to exactly match the text after the equal sign (including quotes), up to the newline character or # , with leading and trailing whitespace truncated.

The following kernel configuration is an example of a successful match:

# 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"

The following kernel configuration is an example of an unsuccessful match:

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 policy matches

SE policy requires the following matches:

• <sepolicy-version> defines a closed range of minor versions for every major version. The sepolicy version reported by the device must fall within one of these ranges to be compatible with the framework. Match rules are similar to HAL versions; it is a match if the sepolicy version is higher or equal to the minimum version for the range. The maximum version is purely informational.
• <kernel-sepolicy-version> ie policydb version. Must be less than the security_policyvers() reported by the device.

Example: Successful SE policy match

The framework compatibility matrix states the following sepolicy information:

<sepolicy>
    <kernel-sepolicy-version>30</kernel-sepolicy-version>
    <sepolicy-version>25.0</sepolicy-version>
    <sepolicy-version>26.0-3</sepolicy-version>
</sepolicy>

On the device:

• The value returned by security_policyvers() must be greater than or equal to 30. Otherwise it isn't a match. به عنوان مثال:
  • If a device returns 29, it isn't a match.
  • If a device returns 31, it is a match.
• SE Policy version must be one of 25.0-∞ or 26.0-∞. Otherwise it isn't a match. (The " -3 " after " 26.0 " is purely informational.)

AVB version matches

The AVB version contains a MAJOR version and MINOR version, with the format as MAJOR.MINOR (eg, 1.0, 2.1). For details, refer to Versioning and Compatibility . AVB version has the following system properties:

• ro.boot.vbmeta.avb_version is the libavb version in bootloader
• ro.boot.avb_version is the libavb version in Android OS ( init/fs_mgr )

The system property appears only when the corresponding libavb has been used to verify AVB metadata (and returns OK). It is absent if a verification failure occurred (or no verification occurred at all).

A compatibility match compares the following:

• sysprop ro.boot.vbmeta.avb_version with avb.vbmeta-version from framework compatibility matrix;
  • 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 with avb.vbmeta-version from framework compatibility matrix.
  • ro.boot.avb_version.MAJOR == avb.vbmeta-version.MAJOR
  • ro.boot.avb_version.MINOR >= avb.vbmeta-version.MINOR

The bootloader or Android OS might contain two copies of libavb libraries, each with a different MAJOR version for upgrade devices and launch devices. In this case, the same unsigned system image can be shared but the final signed system images are different (with different avb.vbmeta-version ):

Figure 1. AVB version matches (/system is P, all other partitions are O).

Figure 2. AVB version matches (all partitions are P).

Example: Successful AVB version match

The framework compatibility matrix states the following AVB information:

<avb>
    <vbmeta-version>2.1</vbmeta-version>
</avb>

On the device:

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 

Match AVB version during OTA

For devices launched with Android 9 or lower, when updating to Android 10, the AVB version requirements in the framework compatibility matrix are matched against the current AVB version on the device. If the AVB version has a major version upgrade during an OTA (for example, from 0.0 to 1.0), the VINTF check for compatibility in OTA doesn't reflect the compatibility after the OTA.

To mitigate the issue, an OEM can place a fake AVB version in the OTA package ( compatibility.zip ) to pass the check. برای انجام این کار:

1. Cherry-pick the following CLs to the Android 9 source tree:
   • CL 732261
   • CL 732262
2. Define BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE for the device. Its value should equal the AVB version before the OTA, that is, the AVB version of the device when it was launched.
3. Rebuild the OTA package.

These changes automatically place BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE as compatibility-matrix.avb.vbmeta-version in the following files:

• /system/compatibility_matrix.xml (which isn't used in Android 9) on the device
• system_matrix.xml in compatibility.zip in the OTA package

These changes don't affect other framework compatibility matrices, including /system/etc/vintf/compatibility_matrix.xml . After the OTA, the new value in /system/etc/vintf/compatibility_matrix.xml is used for compatibility checks instead.

VNDK version matches

The device compatibility matrix declares the required VNDK version in compatibility-matrix.vendor-ndk.version . If the device compatibility matrix doesn't have a <vendor-ndk> tag, no requirements are imposed, and hence it's always considered a match.

If the device compatibility matrix does have a <vendor-ndk> tag, a <vendor-ndk> entry with a matching <version> is looked up from the set of VNDK vendor snapshots that's provided by the framework in the framework manifest. If such an entry doesn't exist, there's no match.

If such an entry does exist, the set of libraries enumerated in the device compatibility matrix must be a subset of the set of libraries stated in the framework manifest; otherwise, the entry isn't considered a match.

• As a special case, if no libraries are enumerated in the device compatibility matrix, the entry is always considered a match, because empty set is a subset of any set.

Example: Successful VNDK version match

If the device compatibility matrix states the following requirement on VNDK:

<!-- Example Device Compatibility Matrix -->
<vendor-ndk>
    <version>27</version>
    <library>libjpeg.so</library>
    <library>libbase.so</library>
</vendor-ndk>

In the framework manifest, only the entry with version 27 is considered.

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

Example A is a match, because VNDK version 27 is in the framework manifest, and {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>

Example B isn't a match. Even though VNDK version 27 is in the framework manifest, libjpeg.so isn't supported by the framework in that snapshot. VNDK version 26 is ignored.

System SDK version matches

The device compatibility matrix declares a set of required System SDK version in compatibility-matrix.system-sdk.version . There's a match only if the set is a subset of provided System SDK versions as declared in manifest.system-sdk.version in the framework manifest.

• As a special case, if no System SDK versions are enumerated in the device compatibility matrix, it's always considered a match, because empty set is a subset of any set.

Example: Successful System SDK version match

If the device compatibility matrix states the following requirement on System SDK:

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

Then, the framework must provide System SDK version 26 and 27 to match.

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

Example A is a match.

<!-- Framework Manifest Example B -->
<system-sdk>
    <version>26</version>
    <version>27</version>
    <version>28</version>
</system-sdk>

Example B is a match.

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

Example C isn't a match, because System SDK version 27 isn't provided.