כללי התאמה

מטרת שתי קבוצות המטריצות והמניפסטים היא לבדוק שהמסגרת וההטמעה של הספק יכולות לעבוד יחד. האימות הזה מצליח אם יש התאמה בין מטריצת התאימות של המסגרת לבין מניפסט המכשיר, וגם בין מניפסט המסגרת לבין מטריצת התאימות של המכשיר.

האימות הזה מתבצע בזמן ה-build, בזמן יצירת חבילת עדכון OTA, בזמן האתחול ובבדיקות התאימות של VTS.

בקטעים הבאים מפורטים כללי ההתאמה שבהם נעשה שימוש ברכיבים שונים.

התאמות בין גרסאות של מטריצות תאימות

כדי להתאים מניפסט של מכשיר למטריצת תאימות של מסגרת, גרסת ה-FCM למשלוח שצוינה על ידי manifest.target-level צריכה להיות זהה בדיוק לגרסת ה-FCM שצוינה על ידי compatibility-matrix.level. אחרת לא תהיה התאמה.

כשמבקשים את מטריצת התאימות של המסגרת עם libvintf, ההתאמה הזו תמיד מצליחה כי libvintf פותח את מניפסט המכשיר, מאחזר את גרסת ה-FCM של המשלוח ומחזיר את מטריצת התאימות של המסגרת בגרסת ה-FCM של המשלוח (בתוספת כמה HAL אופציונליים ממטריצות תאימות בגרסאות FCM גבוהות יותר).

התאמות ל-HAL

כלל התאמה ל-HAL מזהה את הגרסאות של רכיבי hal בקובץ מניפסט שנחשבות כנתמכות על ידי הבעלים של מטריצת התאימות המתאימה.

‫HIDL ו-HALs מקוריים

כללי ההתאמה ל-HIDL ול-HALs מקוריים הם:

• ההערכה של כמה רכיבי <hal> מתבצעת באמצעות קשר AND יחיד.
• רכיבי <hal> יכולים לכלול את המאפיין <hal optional="true"> כדי לציין שהם לא נדרשים.
• לכמה רכיבי <version> באותו רכיב <hal> יש קשר OR. אם מציינים שתי גרסאות או יותר, צריך להטמיע רק אחת מהן. (ראו התאמה מוצלחת של HAL למודול DRM).
• אם יש כמה רכיבי <instance> ו-<regex-instance> באותו רכיב <hal>, והרכיב <hal> הוא חובה, המערכת תבדוק את הרכיבים האלה באמצעות קשר AND יחיד. (ראו התאמה מוצלחת של HAL למודול DRM).

דוגמה: התאמה מוצלחת של HAL למודול

עבור HAL בגרסה 2.5, כלל ההתאמה הוא כדלקמן:

דוגמה: התאמה מוצלחת של HAL למודול DRM

בטבלת התאימות של המסגרת מפורט מידע הגרסה הבא לגבי DRM HAL:

<hal>
    <name>android.hardware.drm
    <version>1.0</version>
    <version>3.1-2</version>
    <interface>
        <name>IDrmFactory</name>
        <instance>default</instance>
        <instance>specific</instance>
    </interface>
</hal>
<hal>
    <name>android.hardware.drm
    <version>2.0</version>
    <interface>
        <name>ICryptoFactory</name>
        <instance>default</instance>
        <regex-instance>[a-z]+/[0-9]+</regex-instance>
    </interface>
</hal>

ספק יכול להטמיע כל אחד מהמקרים הבאים:

android.hardware.drm@1.x::IDrmFactory/default          // where x >= 0
android.hardware.drm@1.x::IDrmFactory/specific         // where x >= 0
android.hardware.drm@3.y::IDrmFactory/default          // where y >= 1
android.hardware.drm@3.y::IDrmFactory/specific         // where y >= 1
android.hardware.drm@2.z::ICryptoFactory/default       // where z >= 0
android.hardware.drm@2.z::ICryptoFactory/${INSTANCE}
            // where z >= 0 and ${INSTANCE} matches [a-z]+/[0-9]+
            // e.g. legacy/0

AIDL HALs

‫Android מגרסה 10 ואילך תומך בגרסאות של AIDL HAL ב-VINTF. כללי ההתאמה של AIDL HAL דומים לאלה של HIDL ו-native HAL, אבל אין גרסאות ראשיות, ויש בדיוק גרסה אחת לכל מופע HAL ‏ (1 אם הגרסה לא צוינה):

• ההערכה של כמה רכיבי <hal> מתבצעת באמצעות קשר AND יחיד.
• ברכיבי <hal> יכול להיות מאפיין <hal optional="true"> כדי לסמן אותם כלא חובה.
• כשיש כמה רכיבי <instance> ו-<regex-instance> באותו רכיב <hal>, והרכיב <hal> הוא חובה, המערכת בודקת אותם באמצעות קשר AND יחיד. (ראו התאמה מוצלחת של HAL למספר מודולים).

דוגמה: התאמה מוצלחת של HAL למודול

ב-HAL בגרסה 5, כלל ההתאמה הוא כדלקמן:

דוגמה: התאמה מוצלחת של HAL למודולים מרובים

בטבלת התאימות של מסגרת העבודה מפורט מידע על הגרסאות הבאות של HALs של מצלמה ושל רכיב הרטט:

<hal>
    <name>android.hardware.vibrator
    <version>1-2</version>
    <interface>
        <name>IVibrator</name>
        <instance>default</instance>
        <instance>specific</instance>
    </interface>
</hal>
<hal>
    <name>android.hardware.camera
    <version>5</version>
    <interface>
        <name>ICamera</name>
        <instance>default</instance>
        <regex-instance>[a-z]+/[0-9]+</regex-instance>
    </interface>
</hal>

ספק יכול להטמיע כל אחד מהמקרים האלה:

android.hardware.vibrator.IVibrator/default     // version >= 1
android.hardware.vibrator.IVibrator/specific    // version >= 1
android.hardware.camera.ICamera/default         // version >= 5
android.hardware.camera.ICamera/${INSTANCE}
            // with version >= 5, where ${INSTANCE} matches [a-z]+/[0-9]+
            // e.g. legacy/0

התאמות של ליבה

בקטע <kernel> של מטריצת התאימות של ה-framework מפורטות הדרישות של ה-framework לגבי ליבת Linux במכשיר. המידע הזה אמור להיות תואם למידע על ליבת המערכת שמדווח על ידי אובייקט ה-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 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.

דוגמה: קביעת ענף הליבה של 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> לא עומד בדרישות האלה, לא נמצאה התאמה.

דוגמה: בחירת דרישות להתאמה

נניח שיש לנו מקרה היפותטי שבו FCMs ב-/system/etc/vintf מצהירים על הדרישות הבאות (התגים של הכותרת והתחתונה מושמטים):

<!-- compatibility_matrix.3.xml -->
<kernel version="4.4.107" level="3"/>
<!-- See kernel/configs/p/android-4.4/ for 4.4-p requirements -->
<kernel version="4.9.84" level="3"/>
<!-- See kernel/configs/p/android-4.9/ for 4.9-p requirements -->
<kernel version="4.14.42" level="3"/>
<!-- See kernel/configs/p/android-4.14/ for 4.14-p requirements -->

<!-- compatibility_matrix.4.xml -->
<kernel version="4.9.165" level="4"/>
<!-- See kernel/configs/q/android-4.9/ for 4.9-q requirements -->
<kernel version="4.14.105" level="4"/>
<!-- See kernel/configs/q/android-4.14/ for 4.14-q requirements -->
<kernel version="4.19.42" level="4"/>
<!-- See kernel/configs/q/android-4.19/ for 4.19-q requirements -->

<!-- compatibility_matrix.5.xml -->
<kernel version="4.14.180" level="5"/>
<!-- See kernel/configs/r/android-4.14/ for 4.14-r requirements -->
<kernel version="4.19.123" level="5"/>
<!-- See kernel/configs/r/android-4.19/ for 4.19-r requirements -->
<kernel version="5.4.41" level="5"/>
<!-- See kernel/configs/r/android-5.4/ for 5.4-r requirements -->

גרסת היעד של FCM, גרסת הליבה של FCM וגרסת הליבה ביחד בוחרות את דרישות הליבה מ-FCM:

התאמה להגדרות הליבה

אם הקטע <kernel> תואם, התהליך ממשיך בניסיון להתאים את הרכיבים config ל-/proc/config.gz. לכל רכיב הגדרה במטריצת התאימות, המערכת מחפשת את /proc/config.gz כדי לבדוק אם ההגדרה קיימת. אם פריט הגדרה מוגדר כ-n במטריצת התאימות בקטע <kernel> התואם, הוא לא יכול להופיע ב-/proc/config.gz. לבסוף, יכול להיות שפריט הגדרה שלא מופיע במטריצת התאימות יופיע ב-/proc/config.gz, ויכול להיות שלא.

דוגמה: התאמה של הגדרות ליבה

• <value type="string">bar</value> matches "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> matches y.
• <value type="tristate">m</value> matches 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 במקום זאת, קוראים את הדרישות של ליבת המערכת מהמטריצה בגרסה 2 של FCM.

לאחר מכן, מתבצעת התאמה של גרסת הליבה. אם מכשיר ב-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> צריך להיות זהה בדיוק לטקסט שאחרי סימן השוויון (כולל המירכאות), עד לתו של השורה החדשה או עד <value>, כשהרווחים הלבנים בתחילת הטקסט ובסופו נחתכים.#

הדוגמה הבאה של הגדרת ליבה היא דוגמה להתאמה מוצלחת:

# comments don't matter
CONFIG_TRI=y
# CONFIG_NOEXIST shouldn't exist
CONFIG_DEC = 4096 # trailing comments and whitespaces are fine
CONFIG_HEX=57005  # 0XDEAD == 57005
CONFIG_STR="str"
CONFIG_EMPTY=""   # empty string must have quotes
CONFIG_EXTRA="extra config items are fine too"

ההגדרה הבאה של ליבת המערכת היא דוגמה להתאמה לא מוצלחת:

CONFIG_TRI="y"   # mismatch: quotes
CONFIG_NOEXIST=y # mismatch: CONFIG_NOEXIST exists
CONFIG_HEX=0x0   # mismatch; value doesn't match
CONFIG_DEC=""    # mismatch; type mismatch (expect int)
CONFIG_EMPTY=1   # mismatch; expects ""
# mismatch: CONFIG_STR is missing

התאמות למדיניות SEPolicy

מדיניות SEPolicy דורשת את ההתאמות הבאות:

• ב-<sepolicy-version>, מוגדר טווח סגור של גרסאות משניות לכל גרסה ראשית. גרסת SEPolicy שמדווחת על ידי המכשיר צריכה להיות בטווחים האלה כדי להיות תואמת למסגרת. כללי ההתאמה דומים לגרסאות HAL. ההתאמה מתבצעת אם גרסת SEPolicy גבוהה או שווה לגרסת המינימום בטווח. הגרסה המקסימלית היא רק מידע.
• ‫<kernel-sepolicy-version>, כלומר גרסת מסד הנתונים של המדיניות, צריכה להיות קטנה מ-security_policyvers() שדווח על ידי המכשיר.

דוגמה: התאמה מוצלחת של SEPolicy

מטריצת התאימות של המסגרת מציינת את פרטי SEPolicy הבאים:

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

במכשיר:

• הערך שמוחזר על ידי security_policyvers() צריך להיות גדול מ-30 או שווה לו. אחרת, אין התאמה. לדוגמה:
  • אם המכשיר מחזיר 29, הוא לא תואם.
  • אם המכשיר מחזיר 31, יש התאמה.
• גרסת SEPolicy חייבת להיות אחת מהגרסאות 25.0-∞ או 26.0-∞. אחרת, היא לא תהיה תואמת. (המידע -3 אחרי 26.0 הוא רק לצורך ידע כללי).

התאמות לגרסת AVB

גרסת ה-AVB מכילה גרסה ראשית וגרסה משנית, בפורמט MAJOR.MINOR (לדוגמה, 1.0, ‏ 2.1). פרטים נוספים זמינים במאמר בנושא ניהול גרסאות ותאימות. לגרסת AVB יש את מאפייני המערכת הבאים:

• ‫ro.boot.vbmeta.avb_version היא גרסת libavb בתוכנת האתחול.
• ‫ro.boot.avb_version היא גרסת libavb ב-Android OS‏ (init/fs_mgr).

מאפיין המערכת מופיע רק כשמשתמשים ב-libavb המתאים כדי לאמת מטא-נתונים של AVB (ומחזיר OK). הוא לא מופיע אם האימות נכשל (או אם לא בוצע אימות בכלל).

התאמה לצורך תאימות משווה בין:

• ‫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 OS יש שני עותקים של libavbספריות, שלכל אחד מהם יש גרסה ראשית שונה למכשירי שדרוג ולמכשירי השקה. במקרה כזה, אפשר לשתף את אותה תמונת מערכת לא חתומה, אבל תמונות המערכת החתומות הסופיות שונות (עם 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.

כדי לפתור את הבעיה, יצרן ציוד מקורי יכול להוסיף גרסה מזויפת של AVB לחבילת ה-OTA ‏(compatibility.zip) כדי לעבור את הבדיקה. לשם כך:

1. צריך לבחור את רשימות השינויים הבאות כדי להוסיף אותן לעץ המקור של Android 9:
   • CL 732261
   • CL 732262
2. מגדירים את BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE למכשיר. הערך שלו צריך להיות שווה לגרסת ה-AVB לפני ה-OTA, כלומר גרסת ה-AVB של המכשיר כשהוא הושק.
3. יוצרים מחדש את חבילת ה-OTA.

השינויים האלה יתבצעו באופן אוטומטי בקבצים הבאים:BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDEcompatibility-matrix.avb.vbmeta-version

• /system/compatibility_matrix.xml (שלא נמצא בשימוש ב-Android 9) במכשיר
• ‫system_matrix.xml ב-compatibility.zip בחבילת ה-OTA

השינויים האלה לא משפיעים על מטריצות תאימות אחרות של מסגרות, כולל /system/etc/vintf/compatibility_matrix.xml. אחרי העדכון, הערך החדש ב-/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>

דוגמה א' היא התאמה, כי 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>

דוגמה ב' לא תואמת. למרות שגרסה 27 של VNDK מופיעה במניפסט של ה-framework, ‏ libjpeg.so לא נתמך על ידי ה-framework בתמונת המצב הזו. המערכת מתעלמת מגרסה 26 של VNDK.

התאמות של גרסת SDK של המערכת

במטריצת התאימות של המכשיר מוגדרת קבוצה של גרסאות SDK נדרשות של המערכת ב-compatibility-matrix.system-sdk.version. יש התאמה רק אם הקבוצה היא קבוצת משנה של גרסאות ה-SDK של המערכת שסופקו, כפי שהוצהרו ב-manifest.system-sdk.version במניפסט של המסגרת.

• במקרה מיוחד, אם לא מפורטות גרסאות SDK של המערכת במטריצת התאימות של המכשיר, תמיד נחשב שיש התאמה, כי קבוצה ריקה היא תת-קבוצה של כל קבוצה.

דוגמה: התאמה מוצלחת של גרסת ה-SDK של המערכת

אם במטריצת התאימות של המכשיר מצוינת הדרישה הבאה לגבי System SDK:

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

לאחר מכן, המסגרת צריכה לספק את גרסאות 26 ו-27 של SDK המערכת כדי להתאים:

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

דוגמה א' היא התאמה:

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

דוגמה ב' היא התאמה:

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

דוגמה ג' לא תואמת, כי לא צוינה גרסה 27 של ה-SDK של המערכת.