เมทริกซ์ความเข้ากันได้สองคู่และรายการมีขึ้นเพื่อกระทบยอดเพื่อตรวจสอบว่ากรอบงานและการใช้งานผู้ขายสามารถทำงานร่วมกันได้ การตรวจสอบนี้จะสำเร็จเมื่อจับคู่ระหว่างเมทริกซ์ความเข้ากันได้ของเฟรมเวิร์กกับรายการอุปกรณ์ รวมถึงระหว่างไฟล์รายการเฟรมเวิร์กกับเมทริกซ์ความเข้ากันได้ของอุปกรณ์
การตรวจสอบนี้เสร็จสิ้นในเวลาบิลด์ เวลาสร้างแพ็คเกจการอัปเดต 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 กฎการจับคู่จะเป็นดังนี้:
เมทริกซ์ | รายการจับคู่ |
---|---|
2.5 | 2.5-2.∞ ในเมทริกซ์ความเข้ากันได้ 2.5 คือชวเลขสำหรับ 2.5-5 |
2.5-7 | 2.5-2.∞ บ่งบอกถึงสิ่งต่อไปนี้:
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
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 กฎการจับคู่จะเป็นดังนี้:
เมทริกซ์ | รายการจับคู่ |
---|---|
5 | 5-∞. ในเมทริกซ์ความเข้ากันได้ 5 คือชวเลขสำหรับ 5-5 |
5-7 | 5-∞. บ่งบอกถึงสิ่งต่อไปนี้:
5-7 ในเมทริกซ์ความเข้ากันได้ |
ตัวอย่าง: การจับคู่ 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 ร่วมกัน:
เวอร์ชัน FCM เป้าหมาย | เวอร์ชันเคอร์เนล FCM | เวอร์ชันเคอร์เนล | เข้าคู่กับ |
---|---|---|---|
3 (ป) | ไม่ระบุ | 4.4.106 | ไม่ตรงกัน (รุ่นรองไม่ตรงกัน) |
3 (ป) | ไม่ระบุ | 4.4.107 | 4.4-p |
3 (ป) | ไม่ระบุ | 4.19.42 | 4.19-q (ดูหมายเหตุด้านล่าง) |
3 (ป) | ไม่ระบุ | 5.4.41 | 5.4-r (ดูหมายเหตุด้านล่าง) |
3 (ป) | 3 (ป) | 4.4.107 | 4.4-p |
3 (ป) | 3 (ป) | 4.19.42 | ไม่ตรงกัน (ไม่มีสาขาเคอร์เนล 4.19-p ) |
3 (ป) | 4 (คิว) | 4.19.42 | 4.19-q |
4 (คิว) | ไม่ระบุ | 4.4.107 | ไม่ตรงกัน (ไม่มีสาขาเคอร์เนล 4.4-q ) |
4 (คิว) | ไม่ระบุ | 4.9.165 | 4.9-q |
4 (คิว) | ไม่ระบุ | 5.4.41 | 5.4-r (ดูหมายเหตุด้านล่าง) |
4 (คิว) | 4 (คิว) | 4.9.165 | 4.9-q |
4 (คิว) | 4 (คิว) | 5.4.41 | ไม่ตรงกัน (ไม่มีสาขาเคอร์เนล 5.4-q ) |
4 (คิว) | 5 (อาร์) | 4.14.105 | 4.14-r |
4 (คิว) | 5 (อาร์) | 5.4.41 | 5.4-r |
5 (อาร์) | ไม่ระบุ | ใดๆ | VTS ล้มเหลว (ต้องระบุเวอร์ชันเคอร์เนล FCM สำหรับเป้าหมาย FCM เวอร์ชัน 5) |
5 (อาร์) | 4 (คิว) | ใดๆ | VTS ล้มเหลว (เวอร์ชันเคอร์เนล FCM <เวอร์ชัน FCM เป้าหมาย) |
5 (อาร์) | 5 (อาร์) | 4.14.180 | 4.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 อ่านข้อกำหนดเคอร์เนลจากเมทริกซ์ที่ 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
แตกต่างกัน):

/system
คือ P พาร์ติชั่นอื่นทั้งหมดคือ O)
ตัวอย่าง: การจับคู่เวอร์ชัน 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
) เพื่อผ่านการตรวจสอบ โดยทำดังนี้
- Cherry-เลือก CLs ต่อไปนี้ไปยังแผนผังต้นทางของ Android 9:
- กำหนด
BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE
สำหรับอุปกรณ์ มูลค่าควรเท่ากับเวอร์ชัน AVB ก่อน OTA นั่นคือเวอร์ชัน AVB ของอุปกรณ์เมื่อเปิดตัว - สร้างแพ็คเกจ 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