กฎการจับคู่

เมทริกซ์ความเข้ากันได้สองคู่และรายการมีขึ้นเพื่อกระทบยอดเพื่อตรวจสอบว่ากรอบงานและการใช้งานผู้ขายสามารถทำงานร่วมกันได้ การตรวจสอบนี้จะสำเร็จเมื่อจับคู่ระหว่างเมทริกซ์ความเข้ากันได้ของเฟรมเวิร์กกับรายการอุปกรณ์ รวมถึงระหว่างไฟล์รายการเฟรมเวิร์กกับเมทริกซ์ความเข้ากันได้ของอุปกรณ์

การตรวจสอบนี้เสร็จสิ้นในเวลาบิลด์ เวลาสร้างแพ็คเกจการอัปเดต OTA เวลาบูต และในการทดสอบความเข้ากันได้ของ VTS

ส่วนต่อไปนี้ให้รายละเอียดกฎการจับคู่ที่ใช้โดยส่วนประกอบต่างๆ

การจับคู่เวอร์ชันเมทริกซ์ความเข้ากันได้ของกรอบงาน

ในการจับคู่รายการอุปกรณ์กับเมทริกซ์ความเข้ากันได้ของเฟรมเวิร์ก เวอร์ชัน Shipping FCM ที่ระบุโดย manifest.target-level จะต้องเท่ากับเวอร์ชัน FCM ที่ระบุโดย compatibility-matrix.level ทุกประการ มิฉะนั้นจะไม่มีการแข่งขัน

เมื่อมีการร้องขอเมทริกซ์ความเข้ากันได้ของเฟรมเวิร์กกับ libvintf การจับคู่นี้จะสำเร็จเสมอเพราะ libvintf เปิดรายการอุปกรณ์ ดึงเวอร์ชัน Shipping FCM และส่งคืนเมทริกซ์ความเข้ากันได้ของเฟรมเวิร์กที่เวอร์ชัน Shipping FCM นั้น (รวมถึง HAL ที่เป็นตัวเลือกบางส่วนจากเมทริกซ์ความเข้ากันได้ที่ FCM ที่สูงกว่า รุ่น)

การแข่งขัน HAL

กฎการจับคู่ HAL ระบุเวอร์ชันขององค์ประกอบ hal ในไฟล์รายการที่ได้รับการพิจารณาว่าได้รับการสนับสนุนโดยเจ้าของเมทริกซ์ความเข้ากันได้ที่สอดคล้องกัน

HIDL และ HAL ดั้งเดิม

กฎการจับคู่สำหรับ HIDL และ HAL ดั้งเดิมมีดังนี้

• องค์ประกอบ <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

Android เวอร์ชันที่ใหม่กว่า Android 11 ทั้งหมด (ยกเว้น Android 11) รองรับเวอร์ชันสำหรับ AIDL HAL ใน VINTF กฎการจับคู่สำหรับ AIDL HAL นั้นคล้ายกับของ 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> ของเมทริกซ์ความเข้ากันได้ของเฟรมเวิร์กจะอธิบายข้อกำหนดของเฟรมเวิร์กของเคอร์เนล 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) แต่เรียกใช้เคอร์เนลจากสาขา 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 /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 ร่วมกัน:

จับคู่การกำหนดค่าเคอร์เนล

หากส่วน <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 อ่านข้อกำหนดเคอร์เนลจากเมทริกซ์ที่ 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> กำหนดช่วงปิดของเวอร์ชันรองสำหรับเวอร์ชันหลักทุกเวอร์ชัน เวอร์ชัน 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 มิฉะนั้น ค่าจะไม่ตรงกัน ตัวอย่างเช่น:
  • หากอุปกรณ์ส่งคืน 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 ใน 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 OS อาจมีไลบรารี 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

สำหรับอุปกรณ์ที่เปิดตัวด้วย Android 9 หรือต่ำกว่า เมื่ออัปเดตเป็น Android 10 ข้อกำหนดเวอร์ชัน AVB ในเมทริกซ์ความเข้ากันได้ของเฟรมเวิร์กจะตรงกับเวอร์ชัน AVB ปัจจุบันบนอุปกรณ์ หากเวอร์ชัน AVB มีการอัปเกรดเวอร์ชันหลักระหว่าง OTA (เช่น จาก 0.0 เป็น 1.0) การตรวจสอบความเข้ากันได้ของ VINTF ใน OTA จะไม่สะท้อนถึงความเข้ากันได้หลังจาก OTA

เพื่อลดปัญหา OEM สามารถวางเวอร์ชัน AVB ปลอมในแพ็คเกจ OTA ( compatibility.zip ) เพื่อผ่านการตรวจสอบ โดยทำดังนี้

1. Cherry-เลือก CLs ต่อไปนี้ไปยังแผนผังต้นทางของ Android 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 (ซึ่งไม่ได้ใช้ใน 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> รายการ <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>

ตัวอย่าง A คือการจับคู่ เนื่องจาก VNDK เวอร์ชัน 27 อยู่ในรายการเฟรมเวิร์ก และ {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>

ตัวอย่าง B ไม่ตรงกัน แม้ว่า VNDK เวอร์ชัน 27 จะอยู่ในรายการเฟรมเวิร์ก แต่ libjpeg.so ไม่ได้รับการสนับสนุนโดยเฟรมเวิร์กในสแน็ปช็อตนั้น VNDK เวอร์ชัน 26 จะถูกละเว้น

เวอร์ชัน SDK ของระบบตรงกัน

เมทริกซ์ความเข้ากันได้ของอุปกรณ์ประกาศชุดของเวอร์ชัน System SDK ที่จำเป็นใน compatibility-matrix.system-sdk.version จะตรงกันก็ต่อเมื่อชุดนั้นเป็นชุดย่อยของเวอร์ชัน 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>

ตัวอย่าง A คือการจับคู่

<!-- Framework Manifest Example B -->
<system-sdk>
    <version>26</version>
    <version>27</version>
    <version>28</version>
</system-sdk>

ตัวอย่าง B คือการจับคู่

<!-- Framework Manifest Example C -->
<system-sdk>
    <version>26</version>
</system-sdk>

ตัวอย่าง C ไม่ตรงกัน เนื่องจากไม่ได้ระบุ System SDK เวอร์ชัน 27