חוקי התאמה

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

אימות זה נעשה בזמן הבנייה, בזמן יצירת חבילת עדכון 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, כלל ההתאמה הוא כדלקמן:

דוגמה: התאמת 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, כלל ההתאמה הוא כדלקמן:

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

התאם תצורות ליבה

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

דוגמה: התאמת גרסת 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 ) כדי לעבור את הבדיקה. כדי לעשות זאת:

1. בחר את ה-CLs הבאות לעץ המקור של אנדרואיד 9:
   • CL 732261
   • CL 732262
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 (שאינו בשימוש באנדרואיד 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 אינה מסופקת.