כללי התאמה

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

האימות הזה מתבצע בזמן ה-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, כלל ההתאמה הוא:

טבלה	מניפסט תואם
2.5	2.5-2.∞. במטריצה של התאימות, 2.5 הוא קיצור הדרך של 2.5-5.
2.5-7	2.5-2.∞. המשמעות היא: 2.5 היא הגרסה המינימלית הנדרשת, כלומר מניפסט שמספק HAL 2.0-2.4 לא תואם. 2.7 היא הגרסה המקסימלית שאפשר לבקש, כלומר הבעלים של מטריית התאימות (ה-framework או המכשיר) לא יבקשו גרסאות מעבר ל-2.7. הבעלים של המניפסט התואם עדיין יכול להציג את הגרסה 2.10 (לדוגמה) כשמתבצעת בקשה לגרסה 2.7. הבעלים של מטריצת התאימות יודע רק שהשירות המבוקש תואם ל-API בגרסה 2.7. הערך -7 הוא לצורכי מידע בלבד, והוא לא משפיע על תהליך העדכון של OTA. לכן, מכשיר עם HAL בגרסה 2.10 בקובץ המניפסט שלו יישאר תואם למסגרת שמציינת את הערך 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. כללי ההתאמה של ממשקי 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, כלל ההתאמה הוא:

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

הערה: אם גרסת FCM של הליבה שווה לגרסת FCM של היעד והן גדולות מ-5 או שוות לה, קובץ המקור של המניפסט של המכשיר שצוין על ידי DEVICE_MANIFEST_FILE לא חייב לציין את גרסת FCM של הליבה. assemble_vintf מסיק באופן אוטומטי את גרסת FCM של הליבה מגרסת היעד של FCM, אם גרסת היעד של FCM גדולה מ-5 או שווה לה.

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

הערה: במכשירים עם גרסת יעד של FCM נמוכה מ-5 (R) וגרסת FCM של ליבה לא מצוינות, אובייקט VINTF בוחר את ההסתעפות של הליבה עם הסיומת הנמוכה ביותר שגדולה מגרסת היעד של FCM עם גרסת הליבה התואמת. בדוגמה שלמעלה, מכשיר עם גרסה יעד של FCM‏ 3 (P) משתמש בהסתעפות הליבה 4.19-q כי ל-4.19-q יש הסיומת הנמוכה ביותר מבין כל ההסתעפויות של הליבה 4.19-*, [4.19-q, 4.19-r, 4.19-s]. התנהגות הבחירה של הדרישות הזו אסורה במכשירים עם גרסת יעד של FCM בגרסה 5 (R) ואילך, כי צריך לציין את גרסת 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 11.

במכשירים שהושקו עם 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.