כללי התאמה

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

האימות הזה מתבצע בזמן ה-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> יכולים לכלול <hal optional="true"> כדי לסמן שהם לא נדרשים.
  • למספר רכיבי <version> בתוך אותו <hal> יש קשר OR. אם מציינים שתי גרסאות או יותר, צריך להטמיע רק אחת מהגרסאות. (ראו דוגמה ל-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.∞. המשמעות היא:
  • 2.5 היא הגרסה המינימלית הנדרשת, כלומר מניפסט שמספק HAL 2.0-2.4 לא תואם.
  • 2.7 היא הגרסה המקסימלית שאפשר לבקש. כלומר, הבעלים של מטריצת התאימות (מסגרת או מכשיר) לא יבקש גרסאות מעבר ל-2.7. הבעלים של המניפסט התואם עדיין יכול להציג את הגרסה 2.10 (לדוגמה) כשמתבצעת בקשה לגרסה 2.7. הבעלים של מטריצת התאימות יודע רק שהשירות המבוקש תואם ל-API בגרסה 2.7.
  • הערך -7 הוא לצורכי מידע בלבד, והוא לא משפיע על תהליך העדכון של OTA.
לכן, מכשיר עם HAL בגרסה 2.10 בקובץ המניפסט ממשיך להיות תואם ל-framework שמציין את 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

ממשקי HAL של AIDL

כל הגרסאות של Android שמתחילות ב-Android 12 (לא כולל Android 11) תומכות בגרסאות של HAL ל-AIDL ב-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 היא הגרסה המינימלית הנדרשת, כלומר מניפסט שמספק HAL‏ 1-4 לא תואם.
  • 7 היא הגרסה המקסימלית שאפשר לבקש, כלומר הבעלים של מטריית התאימות (המסגרת או המכשיר) לא יבקשו גרסאות מעבר ל-7. הבעלים של המניפסט התואם עדיין יכול להציג את הגרסה 10 (לדוגמה) כשמבקשים את הגרסה 7. הבעלים של מטריצת התאימות יודע רק שהשירות המבוקש תואם ל-API בגרסה 7.
  • הערך -7 הוא לצורכי מידע בלבד, והוא לא משפיע על תהליך העדכון של OTA.
לכן, מכשיר עם HAL בגרסה 10 בקובץ המניפסט שלו יישאר תואם למסגרת שמציינת את הערך 5-7 במטריצת התאימות שלה.

דוגמה: התאמת 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 של 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:

גרסת היעד של 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 (Q) 4.19.42 4.19-q
4 (ר)לא צוין4.4.107 אין התאמה (אין הסתעפות ליבה של 4.4-q)
4 (Q)לא צוין4.9.165 4.9-q
4 (Q)לא צוין5.4.41 5.4-r (ראו הערה בהמשך)
4 (Q)4 (ר) 4.9.165 4.9-q
4 (Q)4 (Q) 5.4.41 אין התאמה (אין הסתעפות ליבה של 5.4-q)
4 (Q)5 (R) 4.14.1054.14-r
4 (Q)5 (R) 5.4.41 5.4-r
5 (R)לא צויןכל בדיקת VTS נכשלת (צריך לציין את גרסת FCM של הליבה לגרסת היעד FCM 5)
5 (R)4 (Q) כל בדיקת VTS נכשלת (גרסת FCM של הליבה קטנה מגרסת היעד של FCM)
5 (R)5 (R) 4.14.1804.14-r

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

אם הקטע <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)

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

התאמת תאימות מבוססת על השוואה בין הפרטים הבאים:

  • 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

bootloader או מערכת ההפעלה של 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.

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

  1. מוסיפים את השינויים הבאים לעץ המקור של Android 9:
  2. מגדירים את BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE למכשיר. הערך שלו צריך להיות שווה לגרסת ה-AVB לפני ה-OTA, כלומר גרסת ה-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. אחרי ה-OTA, הערך החדש ב-/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.