שני הצמדים של מטריצות תאימות ומניפסטים אמורים להתאמה כדי לאמת ה-framework וההטמעה של הספק יכולים לפעול זה עם זה. האימות הזה מצליחה תוך התאמה בין מטריצת התאימות של ה-framework קובץ המניפסט של המכשיר, וכן בין המניפסט של המסגרת לבין המכשיר מטריצת התאימות.
האימות הזה מתבצע בזמן ה-build, בעדכון OTA זמן יצירת חבילה, בזמן האתחול ובבדיקות תאימות של VTS.
בקטעים הבאים מפורטים כללי ההתאמה המשמשים את רכיבים שונים.
יש התאמות לגרסה של מטריצת התאימות של המסגרת
כדי להתאים בין מניפסט של מכשיר למטריצת תאימות של framework,
גרסת ה-FCM למשלוח שצוינה על ידי manifest.target-level
חייב להיות שווה בדיוק לגרסת FCM שצוינה באמצעות
compatibility-matrix.level
. אחרת, אין התאמה.
כשנשלחת בקשה למטריצת התאימות של framework עם libvintf
, ההתאמה הזו
תמיד מצליח כי libvintf
פותח את המניפסט של המכשיר, מאחזר את פרטי המשלוח
גרסת FCM, והחזרת מטריצת התאימות של framework אותה לגרסת FCM של המשלוח (בתוספת חלק
שיעורי HAL אופציונליים ממטריצות תאימות בגרסאות FCM גבוהות יותר).
משחקי HAL
כלל התאמה ל-HAL מזהה את הגרסאות של רכיבי hal
שנחשבים כנתמכים על ידי הבעלים של הקובץ
מטריצת התאימות.
HIDL ו-HALs מותאמים
כללי ההתאמה של HIDL ושל HALs מקוריים הם.
- מתבצעת הערכה של מספר רכיבי
<hal>
באמצעות פעולת AND יחידה קשר גומלין. - יכול להיות שרכיבי
<hal>
כוללים<hal optional="true">
כדי לסמן אותם בתור לא נדרש. - מספר רכיבי
<version>
בתוך אותו ל-<hal>
יש קשר או. אם ציינתם שניים או יותר, צריך להטמיע אחת מהגרסאות. (עיינו בדוגמה לניהול זכויות דיגיטליות (DRM) בהמשך.) - מרובים של
<instance>
וגם<regex-instance>
רכיבים בתוך אותו<hal>
מוערכות עם קשר AND יחיד כאשר השדה<hal>
הוא שדה חובה. (עיינו ב<ahref="#drm">דוגמה בנושא DRM בהמשך.)</ahref="#drm">
דוגמה: התאמת HAL מוצלחת למודול
ל-HAL בגרסה 2.5, כלל ההתאמה הוא כך:
טבלה | מניפסט תואם |
---|---|
2.5 |
2.5-2.TCF. במטריצת התאימות, 2.5 הוא הקיצור של
2.5-5 . |
2.5-7 |
2.5-2.TCF. מציין את הדברים הבאים:
2.5-7 במטריצת התאימות שלו. |
דוגמה: התאמת HAL מוצלחת למודול DRM
במטריצת התאימות של framework מצוין פרטי הגרסה הבאים עבור 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 שקודמות ל-Android 11 (לא כולל Android)
11) תמיכה בגרסאות של AIDL HAL ב-VINTF.
כללי ההתאמה של AIDL HAL דומים לכללי ההתאמה של HIDL ושל HALs מקוריים,
אין גרסאות ראשיות, ויש בדיוק גרסה אחת לכל מופע HAL (1
אם
לא צוינה גרסה).
- מתבצעת הערכה של מספר רכיבי
<hal>
באמצעות פעולת AND יחידה קשר גומלין. - יכול להיות שרכיבי
<hal>
כוללים<hal optional="true">
כדי לסמן אותם בתור לא נדרש. - מרובים של
<instance>
וגם<regex-instance>
רכיבים בתוך אותו<hal>
מוערכות עם קשר AND יחיד כאשר השדה<hal>
הוא שדה חובה. (ניתן לעיין <ahref="#vibrator">בדוגמה לרטט למטה.)</ahref="#vibrator">
דוגמה: התאמת HAL מוצלחת למודול
עבור HAL בגרסה 5, כלל ההתאמה הוא כך:
טבלה | מניפסט תואם |
---|---|
5 |
5- ⌘. במטריצת התאימות, 5 הוא הקיצור של
5-5 . |
5-7 |
5- ⌘. מציין את הדברים הבאים:
5-7 במטריצת התאימות שלו. |
דוגמה: התאמת HAL מוצלחת למספר מודולים
במטריצת התאימות של framework מצוין פרטי הגרסה הבאים ל- ויברטור ולמצלמה 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>
במטריצת התאימות של 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 או שווה לה במניפסט המכשיר.
דוגמה: קביעת הסתעפות הליבה
אם למכשיר מוגדר יעד של FCM בגרסה 4 (שהופצה ב-Android 10), אבל
שרץ בליבה (kernel) מההסתעפות 4.19-r
, במניפסט המכשיר צריך לציין את הפרטים הבאים:
<manifest version="2.0" type="device" target-level="4"> <kernel target-level="5" /> </manifest>
אובייקט ה-VINTF בודק את תאימות הליבה (kernel) מול הדרישות בליבה (kernel) של 4.19-r
הסתעפות, שצוינה ב-FCM בגרסה 5. הדרישות האלה מבוססות על
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)
מטריצה יכולה לכלול כמה קטעים של <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 | אין התאמה (ללא הסתעפות ליבה (kernel) של 4.19-p ) |
3 (P) | 4 (ר) | 4.19.42 | 4.19-q |
4 (ר) | לא צוין | 4.4.107 | אין התאמה (ללא הסתעפות ליבה (kernel) של 4.4-q ) |
4 (ר) | לא צוין | 4.9.165 | 4.9-q |
4 (ר) | לא צוין | 5.4.41 | 5.4-r (יש לעיין בהערה בהמשך) |
4 (Q) | 4 (Q) | 4.9.165 | 4.9-q |
4 (Q) | 4 (Q) | 5.4.41 | אין התאמה (ללא הסתעפות ליבה (kernel) של 5.4-q ) |
4 (Q) | 5 (R) | 4.14.105 | 4.14-r |
4 (Q) | 5 (R) | 5.4.41 | 5.4-r |
5 (R) | לא צוין | כל | VTS נכשל (חובה לציין את גרסת הליבה של FCM לגרסת היעד 5 של FCM) |
5 (R) | 4 (Q) | כל | VTS נכשל (גרסת FCM ליבה < גרסת יעד של FCM) |
5 (R) | 5 (R) | 4.14.180 | 4.14-r |
התאמה של הגדרות הליבה
אם הפרטים בקטע <kernel>
תואמים, התהליך ממשיך
על ידי ניסיון להתאים רכיבים של config
/proc/config.gz
. לכל רכיב config של התאימות
מתבצע חיפוש של /proc/config.gz
כדי לראות אם ההגדרה
כיום. כשפריט config מוגדר לערך n
במסגרת התאימות
מטריצה עבור הקטע <kernel>
התואם, חייבת להיות חסרה
מ-/proc/config.gz
. לבסוף, פריט config שלא נמצא
מטריצת התאימות עשויה להיות קיימת או לא קיימת ב-/proc/config.gz
.
דוגמה: התאמה להגדרות ליבה (kernel)
<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
, או שווה ערך הקסדצימלי.
דוגמה: התאמת ליבה מוצלחת
מטריצת תאימות של framework עם 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>
מגדיר טווח סגור של קטינים לכל גרסה ראשית. גרסת התוכנה שדווחה על ידי המכשיר חייבים להיות באחד מהטווחים האלה כדי שתהיה תאימות ל-framework. התאמה הכללים דומים לגרסאות HAL, יש התאמה אם הגרסה המדיניות שווה לגרסה המינימלית של הטווח, או גבוהה ממנה. הגרסה המקסימלית היא למטרות מידע בלבד.<kernel-sepolicy-version>
, כלומר גרסת Policydb. חובה יהיו פחות מהערךsecurity_policyvers()
שדווח על ידי המכשיר.
דוגמה: התאמת מדיניות SE מוצלחת
במטריצת התאימות של framework מצוין המידע הבא לגבי המדיניות:
<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
בתוכנת האתחולro.boot.avb_version
היא הגרסהlibavb
ב- Android OS (init/fs_mgr
)
מאפיין המערכת מופיע רק כאשר נעשה שימוש ב-libavb התואם כדי לאמת מטא-נתונים של AVB (ולהחזיר את הערך OK). הוא חסר אם האימות נכשל לא בוצע אימות (או שלא בוצע אימות בכלל).
בדיקת תאימות משווה את הנתונים הבאים:
- syspro עם
ro.boot.vbmeta.avb_version
עםavb.vbmeta-version
ממטריצת התאימות של framework;ro.boot.vbmeta.avb_version.MAJOR == avb.vbmeta-version.MAJOR
ro.boot.vbmeta.avb_version.MINOR >= avb.vbmeta-version.MINOR
- syspro עם
ro.boot.avb_version
עםavb.vbmeta-version
ממטריצת התאימות של framework.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 הצליחה
במטריצת התאימות של framework מפורטים הפרטים הבאים של 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.
כדי לפתור את הבעיה, יצרן ציוד מקורי יכול להכניס גרסת AVB מזויפת לחבילת OTA
(compatibility.zip
) כדי לעבור את הבדיקה. לשם כך:
- חשוב לבחור את השינויים הבאים בעץ המקור של Android 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
(שלא נעשה בו שימוש ב-Android 9) במכשירsystem_matrix.xml
ב-compatibility.zip
בחבילת OTA
השינויים האלה לא משפיעים על מטריצות של תאימות ל-framework, כולל
/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
שמסופק על ידי ה-framework במניפסט של framework. אם רשומה כזו לא
אין התאמה.
אם קיים רשומה כזו, קבוצת הספריות ששמורות במכשיר מטריצת התאימות חייבת להיות קבוצת משנה של קבוצת הספריות מניפסט של framework; אחרת, הרשומה לא תיחשב כהתאמה.
- מקרה מיוחד, אם לא רשומות ספריות במכשיר מטריצת תאימות, הרשומה תמיד נחשבת התאמה, כי היא ריקה היא קבוצת משנה של כל קבוצה.
דוגמה: התאמת גרסה של VNDK מוצלחת
אם מטריצת התאימות של המכשירים מציינת את הדרישה הבאה ב-VNDK:
<!-- Example Device Compatibility Matrix --> <vendor-ndk> <version>27</version> <library>libjpeg.so</library> <library>libbase.so</library> </vendor-ndk>
במניפסט של framework, המערכת מביאה בחשבון רק את הרשומה עם גרסה 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>
דוגמה ב' לא התאמה. למרות שגרסה 27 של VNDK נמצאת במסגרת
libjpeg.so
אינו נתמך על ידי ה-framework
קובץ snapshot. המערכת מתעלמת מ-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>
לאחר מכן, ה-framework צריך לספק את גרסת ה-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>
דוגמה ג' לא תואמת כי לא סופקה גרסה 27 של ה-System SDK.