כללי התאמה

קל לארגן דפים בעזרת אוספים אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.

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

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

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

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

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

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

התאמות HAL

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

HIDL ו-HAL מקומיים

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

• הערך של כמה רכיבי <hal> מחושב באמצעות קשר AND יחיד.
• אפשר להוסיף את המאפיין <hal optional="true"> לרכיבי <hal> כדי לסמן אותם כרכיבים לא נדרשים. אזהרה: אין יותר תמיכה ב-optional בגרסה 15 ואילך של Android
• לרכיבי <version> מרובים באותו <hal> יש את הקשר OR. אם מציינים שתי גרסאות או יותר, צריך להטמיע רק אחת מהן. (ראו דוגמה ל-DRM בהמשך).
• אם יש כמה רכיבי <instance> ו-<regex-instance> באותו <hal>, המערכת מבצעת הערכה שלהם באמצעות קשר AND יחיד כשהיא זקוקה ל-<hal>. (ראו <ahref="#drm">דוגמה ל-DRM בהמשך).</ahref="#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

ממשקי HAL של AIDL

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

• הערך של כמה רכיבי <hal> מחושב באמצעות קשר AND יחיד.
• אפשר להוסיף את המאפיין <hal optional="true"> לרכיבי <hal> כדי לסמן אותם כלא נדרשים. אזהרה: אין יותר תמיכה ב-optional בגרסה 15 ואילך של Android
• אם יש כמה רכיבי <instance> ו-<regex-instance> באותו <hal>, המערכת מבצעת הערכה שלהם באמצעות קשר AND יחיד כשהיא זקוקה ל-<hal>. (ראו <ahref="#vibrator">דוגמה למכשיר ויברטור בהמשך.)</ahref="#vibrator">

דוגמה להתאמה מוצלחת של 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> של מטריצת התאימות של המסגרת מתוארות הדרישות של המסגרת לגרעין 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, שצוינה ב-FCM בגרסה 5. הדרישות האלה נוצרות מ- kernel/configs/r/android-4.19 בעץ המקור של Android.

דוגמה: איך קובעים את ההסתעפות של הליבה ל-GKI

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

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

# 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. יש התאמה אם גרסת המדיניות של הרשאות הגישה היא גרסה גבוהה יותר או שווה לגרסה המינימלית בטווח. הגרסה המקסימלית היא למטרות מידע בלבד.
• <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 (למשל, 1.0, 2.1). פרטים נוספים זמינים במאמר ניהול גרסאות ותאימות. לגרסה של AVB יש את מאפייני המערכת הבאים:

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

מאפיין המערכת מופיע רק כשנעשה שימוש ב-libav המתאים כדי לאמת את המטא-נתונים של 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

מערך האתחול או מערכת ההפעלה של Android עשויים להכיל שתי עותקים של ספריות 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.

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

1. מוסיפים את ה-CLs הבאים לעץ המקור של Android 9:
   • CL 732261
   • CL 732262
2. מגדירים את BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE למכשיר. הערך שלו צריך להיות שווה לגרסה של AVB לפני העדכון האווירי, כלומר גרסת ה-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. אחרי העדכון האווירי, הערך החדש ב-/system/etc/vintf/compatibility_matrix.xml משמש לבדיקות התאימות במקום זאת.

התאמות של גרסאות VNDK

הגרסה הנדרשת של VNDK מופיעה ב-compatibility-matrix.vendor-ndk.version במטריצה של תאימות המכשירים. אם לא מוגדר תג <vendor-ndk> במטריצה של תאימות המכשירים, לא חלות דרישות ולכן המכשיר תמיד נחשב כמתאים.

אם למטריצה של תאימות המכשירים יש תג <vendor-ndk>, מתבצע חיפוש של רשומה <vendor-ndk> עם <version> תואם מתוך קבוצת קובצי snapshot של ספקי 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 נמצאת ב-manifest של המסגרת, וגם {libjpeg.so, libbase.so, libfoo.so} ⊇ {libjpeg.so, libbase.so}.

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

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

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

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

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

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

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

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

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

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