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

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

این تأیید در زمان ساخت، در زمان تولید بسته به‌روزرسانی 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، قانون مسابقه به شرح زیر است:

ماتریس مانیفست تطبیق
2.5 2.5-2.∞. در ماتریس سازگاری، 2.5 مخفف 2.5-5 است.
2.5-7 2.5-2.∞. موارد زیر را نشان می دهد:
  • 2.5 حداقل نسخه مورد نیاز است، به این معنی که مانیفست ارائه HAL 2.0-2.4 سازگار نیست.
  • 2.7 حداکثر نسخه ای است که می توان درخواست کرد، به این معنی که صاحب ماتریس سازگاری (فریم ورک یا دستگاه) نسخه های بالاتر از 2.7 را درخواست نخواهد کرد. مالک مانیفست منطبق همچنان می تواند نسخه 2.10 (به عنوان مثال) را در صورت درخواست 2.7 ارائه دهد. مالک ماتریس سازگاری فقط می داند که سرویس درخواستی با API نسخه 2.7 سازگار است.
  • -7 فقط اطلاعاتی است و بر روند به‌روزرسانی OTA تأثیری ندارد.
بنابراین، دستگاهی با HAL در نسخه 2.10 در فایل مانیفست خود با چارچوبی که در ماتریس سازگاری آن 2.5-7 بیان می کند، سازگار باقی می ماند.

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

ماتریس مانیفست تطبیق
5 5-∞. در ماتریس سازگاری، 5 مختصر 5-5 است.
5-7 5-∞. موارد زیر را نشان می دهد:
  • 5 حداقل نسخه مورد نیاز است، به این معنی که مانیفست ارائه HAL 1-4 سازگار نیست.
  • 7 حداکثر نسخه ای است که می توان درخواست کرد، به این معنی که مالک ماتریس سازگاری (فریم ورک یا دستگاه) نسخه های بیش از 7 را درخواست نمی کند. مالک مانیفست منطبق همچنان می تواند نسخه 10 (به عنوان مثال) را در صورت درخواست 7 ارائه کند. . مالک ماتریس سازگاری فقط می داند که سرویس درخواستی با API نسخه 7 سازگار است.
  • -7 فقط اطلاعاتی است و بر روند به‌روزرسانی OTA تأثیری ندارد.
بنابراین، دستگاهی با HAL در نسخه 10 در فایل مانیفست خود با چارچوبی که 5-7 در ماتریس سازگاری آن بیان می‌شود، سازگار باقی می‌ماند.

مثال: تطابق موفق 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 ها انتخاب می کنند:

نسخه FCM هدف نسخه FCM کرنل نسخه کرنل مطابقت با
3 (P) نامشخص 4.4.106 بدون تطابق (تناسب جزئی نسخه)
3 (P) نامشخص 4.4.107 4.4-p
3 (P) نامشخص 4.19.42 4.19-q (به یادداشت زیر مراجعه کنید)
3 (P) نامشخص 5.4.41 5.4-r (به یادداشت زیر مراجعه کنید)
3 (P) 3 (P) 4.4.107 4.4-p
3 (P) 3 (P) 4.19.42 بدون تطابق (بدون شاخه هسته 4.19-p )
3 (P) 4 (س) 4.19.42 4.19-q
4 (س) نامشخص 4.4.107 بدون تطابق (بدون شاخه هسته 4.4-q )
4 (س) نامشخص 4.9.165 4.9-q
4 (س) نامشخص 5.4.41 5.4-r (به یادداشت زیر مراجعه کنید)
4 (س) 4 (س) 4.9.165 4.9-q
4 (س) 4 (س) 5.4.41 بدون تطابق (بدون شاخه هسته 5.4-q )
4 (س) 5 (R) 4.14.105 4.14-r
4 (س) 5 (R) 5.4.41 5.4-r
5 (R) نامشخص هر VTS شکست می خورد (باید نسخه FCM هسته را برای نسخه 5 FCM هدف مشخص کنید)
5 (R) 4 (س) هر VTS با شکست مواجه شد (نسخه FCM هسته < نسخه FCM هدف)
5 (R) 5 (R) 4.14.180 4.14-r

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

اگر بخش <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 انتخاب کنید:
  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، قانون مسابقه به شرح زیر است:

ماتریس مانیفست تطبیق
2.5 2.5-2.∞. در ماتریس سازگاری، 2.5 مخفف 2.5-5 است.
2.5-7 2.5-2.∞. موارد زیر را نشان می دهد:
  • 2.5 حداقل نسخه مورد نیاز است، به این معنی که مانیفست ارائه HAL 2.0-2.4 سازگار نیست.
  • 2.7 حداکثر نسخه ای است که می توان درخواست کرد، به این معنی که صاحب ماتریس سازگاری (فریم ورک یا دستگاه) نسخه های بالاتر از 2.7 را درخواست نخواهد کرد. مالک مانیفست منطبق همچنان می تواند نسخه 2.10 (به عنوان مثال) را در صورت درخواست 2.7 ارائه دهد. مالک ماتریس سازگاری فقط می داند که سرویس درخواستی با API نسخه 2.7 سازگار است.
  • -7 فقط اطلاعاتی است و بر روند به‌روزرسانی OTA تأثیری ندارد.
بنابراین، دستگاهی با HAL در نسخه 2.10 در فایل مانیفست خود با چارچوبی که در ماتریس سازگاری آن 2.5-7 بیان می کند، سازگار باقی می ماند.

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

ماتریس مانیفست تطبیق
5 5-∞. در ماتریس سازگاری، 5 مختصر 5-5 است.
5-7 5-∞. موارد زیر را نشان می دهد:
  • 5 حداقل نسخه مورد نیاز است، به این معنی که مانیفست ارائه HAL 1-4 سازگار نیست.
  • 7 حداکثر نسخه ای است که می توان درخواست کرد، به این معنی که مالک ماتریس سازگاری (فریم ورک یا دستگاه) نسخه های بیش از 7 را درخواست نمی کند. مالک مانیفست منطبق همچنان می تواند نسخه 10 (به عنوان مثال) را در صورت درخواست 7 ارائه کند. . مالک ماتریس سازگاری فقط می داند که سرویس درخواستی با API نسخه 7 سازگار است.
  • -7 فقط اطلاعاتی است و بر روند به‌روزرسانی OTA تأثیری ندارد.
بنابراین، دستگاهی با HAL در نسخه 10 در فایل مانیفست خود با چارچوبی که 5-7 در ماتریس سازگاری آن بیان می‌شود، سازگار باقی می‌ماند.

مثال: تطابق موفق 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 ها انتخاب می کنند:

نسخه FCM هدف نسخه FCM کرنل نسخه کرنل مطابقت با
3 (P) نامشخص 4.4.106 بدون تطابق (تناسب جزئی نسخه)
3 (P) نامشخص 4.4.107 4.4-p
3 (P) نامشخص 4.19.42 4.19-q (به یادداشت زیر مراجعه کنید)
3 (P) نامشخص 5.4.41 5.4-r (به یادداشت زیر مراجعه کنید)
3 (P) 3 (P) 4.4.107 4.4-p
3 (P) 3 (P) 4.19.42 بدون تطابق (بدون شاخه هسته 4.19-p )
3 (P) 4 (س) 4.19.42 4.19-q
4 (س) نامشخص 4.4.107 بدون تطابق (بدون شاخه هسته 4.4-q )
4 (س) نامشخص 4.9.165 4.9-q
4 (س) نامشخص 5.4.41 5.4-r (به یادداشت زیر مراجعه کنید)
4 (س) 4 (س) 4.9.165 4.9-q
4 (س) 4 (س) 5.4.41 بدون تطابق (بدون شاخه هسته 5.4-q )
4 (س) 5 (R) 4.14.105 4.14-r
4 (س) 5 (R) 5.4.41 5.4-r
5 (R) نامشخص هر VTS شکست می خورد (باید نسخه FCM هسته را برای نسخه 5 FCM هدف مشخص کنید)
5 (R) 4 (س) هر VTS با شکست مواجه شد (نسخه FCM هسته < نسخه FCM هدف)
5 (R) 5 (R) 4.14.180 4.14-r

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

اگر بخش <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

سیستم عامل 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 را منعکس نمی کند.

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

  1. Cherry CLS زیر را به درخت منبع Android 9 انتخاب کنید:
  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 اعلام می کند. فقط در صورتی که مجموعه زیر مجموعه ای از نسخه های 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 ارائه نشده است.