เมทริกซ์และรายการความเข้ากันได้สองคู่มีจุดมุ่งหมายเพื่อให้กระทบยอดเพื่อตรวจสอบว่ากรอบงานและการใช้งานผู้จัดจำหน่ายสามารถทำงานร่วมกันได้ การตรวจสอบนี้จะสำเร็จเมื่อการจับคู่ระหว่างเมทริกซ์ความเข้ากันได้ของเฟรมเวิร์กและรายการอุปกรณ์ รวมถึงระหว่างรายการเฟรมเวิร์กและเมทริกซ์ความเข้ากันได้ของอุปกรณ์
การตรวจสอบนี้เสร็จสิ้น ณ เวลาสร้าง เวลาสร้างแพ็คเกจการอัปเดต OTA เวลาบูต และในการทดสอบความเข้ากันได้ของ VTS
ส่วนต่อไปนี้จะอธิบายรายละเอียดกฎการจับคู่ที่ใช้โดยส่วนประกอบต่างๆ
เวอร์ชันเมทริกซ์ความเข้ากันได้ของเฟรมเวิร์กตรงกัน
หากต้องการจับคู่รายการอุปกรณ์กับเมทริกซ์ความเข้ากันได้ของเฟรมเวิร์ก เวอร์ชัน Shipping FCM ที่ระบุโดย manifest.target-level
จะต้องเท่ากับเวอร์ชัน FCM ที่ระบุโดย compatibility-matrix.level
ทุกประการ ไม่อย่างนั้นก็เข้ากันไม่ได้
เมื่อมีการร้องขอเมทริกซ์ความเข้ากันได้ของเฟรมเวิร์กด้วย libvintf
การจับคู่นี้จะสำเร็จเสมอเนื่องจาก libvintf
เปิดรายการอุปกรณ์ ดึงเวอร์ชัน Shipping FCM และส่งคืนเมทริกซ์ความเข้ากันได้ของเฟรมเวิร์กที่เวอร์ชัน Shipping FCM นั้น (บวกกับ HAL เสริมบางตัวจากเมทริกซ์ความเข้ากันได้ที่ FCM ที่สูงกว่า เวอร์ชัน)
การแข่งขัน HAL
กฎการจับคู่ HAL ระบุเวอร์ชันขององค์ประกอบ hal
ในไฟล์ Manifest ที่ถือว่าได้รับการสนับสนุนโดยเจ้าของเมทริกซ์ความเข้ากันได้ที่เกี่ยวข้อง
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 HAL
Android เวอร์ชันใหม่กว่า Android 11 (ยกเว้น Android 11) รองรับเวอร์ชันสำหรับ AIDL HALs ใน 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
ในแผนผังต้นทางของ 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 ล้มเหลว (เวอร์ชัน Kernel 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 ต่อไปนี้:
<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 (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 อาจมีสำเนาไลบรารี 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
) เพื่อผ่านการตรวจสอบ โดยทำดังนี้:
- เชอร์รี่เลือก CL ต่อไปนี้ไปยังแผนผังซอร์ส 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>
ที่มี <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 อยู่ใน framework 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>
ตัวอย่าง B ไม่ตรงกัน แม้ว่า VNDK เวอร์ชัน 27 จะอยู่ในรายการเฟรมเวิร์ก แต่เฟรมเวิร์กในสแน็ปช็อตนั้นไม่รองรับ libjpeg.so
VNDK เวอร์ชัน 26 จะถูกละเว้น
เวอร์ชันของระบบ SDK ตรงกัน
เมทริกซ์ความเข้ากันได้ของอุปกรณ์ประกาศชุดของเวอร์ชัน System SDK ที่จำเป็นใน compatibility-matrix.system-sdk.version
มีการจับคู่เฉพาะในกรณีที่ชุดเป็นชุดย่อยของเวอร์ชัน System SDK ที่ระบุตามที่ประกาศไว้ใน manifest.system-sdk.version
ในรายการเฟรมเวิร์ก
- ในกรณีพิเศษ ถ้าไม่มีการแจกแจงเวอร์ชัน System SDK ในเมทริกซ์ความเข้ากันได้ของอุปกรณ์ จะถือว่าตรงกันเสมอ เนื่องจากชุดว่างคือชุดย่อยของชุดใดๆ
ตัวอย่าง: การจับคู่เวอร์ชัน System 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