כללי התאמה

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

האימות הזה מתבצע בזמן ה-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. כללי ההתאמה ל-HAL של AIDL דומים לאלה של HIDL ו-HAL מקורי, אלא שאין גרסאות ראשיות, ויש בדיוק גרסה אחת לכל מופע HAL ‏ (1 אם הגרסה לא צוינה):

• הערכה של כמה רכיבי <hal> מתבצעת באמצעות קשר גומלין יחיד מסוג AND.
• ברכיבי <hal> יכול להיות מאפיין <hal optional="true"> כדי לסמן אותם כלא חובה.
• אם יש כמה רכיבי <instance> ו-<regex-instance> באותו רכיב <hal>, והרכיב <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> של מטריצת התאימות של המסגרת מתוארות הדרישות של המסגרת לגבי ליבת 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 של FCM (שיצאה ב-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> שעומד בדרישות האלה, לא נמצאה התאמה.

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

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

לאחר מכן, המסגרת צריכה לספק את גרסאות המערכת 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>

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

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

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