כללים תואמים

שני הצמדים של מטריצות תאימות ומניפסטים אמורים להתאמה כדי לאמת ה-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 היא הגרסה המינימלית הנדרשת. כלומר, מניפסט שמספק HAL הגרסאות 2.0-2.4 לא תואמות.
  • 2.7 הוא הגרסה המקסימלית שאפשר לבקש, כלומר הבעלים של מטריצת התאימות (מסגרת או מכשיר) לא תבקש גרסאות מעבר ל-2.7. הבעלים של המניפסט התואם עדיין יכול להציג את גרסה 2.10 (כדוגמה) כשנשלחת בקשה ל-2.7. הבעלים של מטריצת התאימות יודע רק שהשירות המבוקש תואם לגרסת API 2.7.
  • -7 למטרות מידע בלבד ולא משפיע על תהליך העדכון של OTA.
כך, מכשיר עם HAL בגרסה 2.10 בקובץ המניפסט שלו נשאר תואמים למסגרת 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 הוא הגרסה המינימלית הנדרשת. כלומר, מניפסט שמספק HAL הערכים 1-4 לא תואמים.
  • 7 הוא הגרסה המקסימלית שאפשר לבקש, כלומר הבעלים של מטריצת התאימות (מסגרת או מכשיר) לא תבקש גרסאות מעבר ל-7. הבעלים של המניפסט התואם עדיין יכול להציג את גרסה 10 (כדוגמה) כשמופיעה בקשה ל-7. הבעלים של מטריצת התאימות יודע רק שהשירות המבוקש תואם לגרסה 7 של ממשק ה-API.
  • -7 למטרות מידע בלבד ולא משפיע על תהליך העדכון של OTA.
כך, מכשיר עם HAL בגרסה 10 בקובץ המניפסט שלו נשאר תואמים למסגרת 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.1054.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.1804.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) כדי לעבור את הבדיקה. לשם כך:

  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

השינויים האלה לא משפיעים על מטריצות של תאימות ל-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.