שני הזוגות של מטריצות תאימות ומניפסטים נועדו להתאחות כדי לוודא שהמסגרת והיישום של הספק יכולים לעבוד זה עם זה. אימות זה מצליח לאחר התאמה בין מטריצת תאימות המסגרת למניפסט המכשיר, כמו גם בין מניפסט המסגרת למטריצת תאימות המכשיר.
אימות זה נעשה בזמן הבנייה, בזמן יצירת חבילת עדכון OTA , בזמן האתחול ובמבחני תאימות VTS.
הסעיפים הבאים מפרטים כללי התאמה המשמשים רכיבים שונים.
התאמת גרסת מטריצת תאימות למסגרת
כדי להתאים מניפסט מכשיר למטריצת תאימות מסגרת, גרסת ה-FCM של משלוח שצוינה על ידי manifest.target-level
חייבת להיות שווה בדיוק לגרסת ה-FCM שצוינה על ידי compatibility-matrix.level
. אחרת אין התאמה.
כאשר מתבקשת מטריצת תאימות המסגרת עם libvintf
, התאמה זו תמיד מוצלחת מכיוון libvintf
פותח את המניפסט של המכשיר, מאחזר את גרסת משלוח FCM ומחזיר את מטריצת תאימות המסגרת באותה גרסת משלוח FCM (בתוספת כמה HALs אופציונליים ממטריצות תאימות ב-FCM גבוהות יותר גרסאות).
משחקי HAL
כלל ההתאמה של HAL מזהה את הגירסאות של רכיבי hal
בקובץ מניפסט הנחשבות לנתמכות על ידי הבעלים של מטריצת התאימות המתאימה.
HIDL ו-HALs מקוריים
כללי ההתאמה עבור HIDL ו-HALs מקוריים הם כדלקמן.
- רכיבי
<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-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
וחייבים גם ליישם את כל המקרים האלה:
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
כל גרסאות אנדרואיד מאוחרות יותר מאנדרואיד 11 (למעט אנדרואיד 11) תומכות בגרסאות עבור AIDL HALs ב-VINTF. כללי ההתאמה עבור AIDL HALs דומים לאלו של 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-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. לדוגמה, למכשיר הנ"ל יש גרסה 4 של יעד FCM, וגרסת FCM הליבה שלו היא 5 (סיומת ענף ליבה
r
). - גרסת ה-FCM של הליבה גדולה או שווה ל-5 (סיומת ענף ליבה
r
).
בדיקות VTS אוכפות שאם מפורטת גרסת ה-FCM של הליבה, גרסת ה-FCM של הליבה גדולה או שווה לגרסת היעד של FCM במניפסט המכשיר.
דוגמה: קבע את ענף הגרעין
אם למכשיר יש יעד FCM גרסה 4 (ששוחררה באנדרואיד 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
בעץ המקור של אנדרואיד.
דוגמה: קבע את ענף הליבה עבור 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>
לא עומד בדרישות אלו, זו אי התאמה.
דוגמה: בחר דרישות להתאמה
שקול את המקרה ההיפותטי הבא שבו 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:
גרסת יעד 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 של הליבה עבור גירסת FCM היעד 5) |
5 (R) | 4 (ש) | כל | VTS נכשל (גרסת FCM ליבה < גרסת FCM יעד) |
5 (R) | 5 (R) | 4.14.180 | 4.14-r |
התאם תצורות ליבה
אם הקטע <kernel>
אכן תואם, התהליך ממשיך על ידי ניסיון להתאים רכיבי config
מול /proc/config.gz
. עבור כל רכיב תצורה במטריצת התאימות, הוא מחפש את /proc/config.gz
כדי לראות אם התצורה קיימת. כאשר פריט תצורה מוגדר ל- n
במטריצת התאימות עבור הקטע התואם <kernel>
, עליו להיעדר ב- /proc/config.gz
. לבסוף, פריט תצורה שאינו במטריצת התאימות עשוי להיות קיים ב-/proc/ /proc/config.gz
או לא.
דוגמה: התאם תצורות ליבה
-
<value type="string">bar</value>
תואם"bar"
. מרכאות מושמטות במטריצת התאימות אך קיימות ב-/proc//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//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/ /proc/config.gz
; עבור כל פריט <config>
עם הערך n
, אנו מצפים שהערך המתאים לא יהיה קיים ב-/proc/ /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 או שווה ל-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
ב-bootloader -
ro.boot.avb_version
היא גרסתlibavb
במערכת ההפעלה אנדרואיד (init/fs_mgr
)
מאפיין המערכת מופיע רק כאשר נעשה שימוש ב-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
):

/system
הוא P, כל המחיצות האחרות הן O).
דוגמה: התאמת גרסת 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
עבור מכשירים שהושקו עם אנדרואיד 9 ומטה, בעת עדכון לאנדרואיד 10, דרישות גרסת AVB במטריצת תאימות המסגרת מותאמות לגרסת AVB הנוכחית במכשיר. אם לגרסת AVB יש שדרוג גרסה גדול במהלך OTA (לדוגמה, מ-0.0 ל-1.0), בדיקת VINTF לתאימות ב-OTA אינה משקפת את התאימות לאחר ה-OTA.
כדי להקל על הבעיה, יצרן OEM יכול להציב גרסת AVB מזויפת בחבילת OTA ( compatibility.zip
) כדי לעבור את הבדיקה. כדי לעשות זאת:
- בחר את ה-CLs הבאות לעץ המקור של אנדרואיד 9:
- הגדר
BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE
עבור המכשיר. הערך שלו צריך להיות שווה לגרסת ה-AVB לפני ה-OTA, כלומר לגרסת ה-AVB של המכשיר בעת השקתו. - בנה מחדש את חבילת OTA.
שינויים אלה ממקמים באופן אוטומטי BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE
בתור compatibility-matrix.avb.vbmeta-version
בקבצים הבאים:
-
/system/compatibility_matrix.xml
(שאינו בשימוש באנדרואיד 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>
דוגמה א' היא התאמה, מכיוון שגרסה 27 של VNDK נמצאת במניפסט המסגרת, ו- {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
אינו נתמך על ידי המסגרת בתמונת המצב הזו. מתעלמים מגרסה 26 של VNDK.
תואמת גרסת 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>
דוגמה C אינה התאמה, כי מערכת SDK גרסה 27 אינה מסופקת.