เมทริกซ์ความเข้ากันได้ 2 คู่และไฟล์ Manifest มีไว้เพื่อ ปรับยอดเพื่อยืนยันว่า กรอบความคิดและการดำเนินงาน ของผู้ให้บริการจะสามารถทำงานด้วยกันได้ การยืนยันนี้ จะประสบความสำเร็จหรือไม่เมื่อมีการจับคู่เมทริกซ์ความเข้ากันได้ของเฟรมเวิร์กกับ ไฟล์ Manifest ของอุปกรณ์ รวมถึงระหว่างไฟล์ Manifest ของเฟรมเวิร์กกับอุปกรณ์ เมทริกซ์ความเข้ากันได้
การยืนยันนี้เสร็จสิ้นในเวลาบิลด์ โดยจะอัปเดต OTA เวลาที่สร้างแพ็กเกจ ขณะเปิดเครื่อง และในการทดสอบความเข้ากันได้ของ VTS
ส่วนต่อไปนี้แสดงรายละเอียดของกฎการจับคู่ที่ใช้โดย องค์ประกอบที่หลากหลาย
เวอร์ชันเมทริกซ์ความเข้ากันได้ของเฟรมเวิร์กตรงกัน
หากต้องการจับคู่ไฟล์ Manifest ของอุปกรณ์กับเมทริกซ์ความเข้ากันได้ของเฟรมเวิร์ก
เวอร์ชัน FCM การจัดส่งที่ระบุโดย manifest.target-level
ต้องเท่ากับเวอร์ชัน FCM ที่ระบุโดย
compatibility-matrix.level
หากไม่มีข้อมูลที่ตรงกัน
เมื่อมีการขอเมทริกซ์ความเข้ากันได้ของเฟรมเวิร์กด้วย libvintf
การจับคู่นี้จะเป็น
ประสบความสำเร็จเสมอเนื่องจาก libvintf
เปิดไฟล์ Manifest ของอุปกรณ์ และดึงข้อมูลการจัดส่ง
เวอร์ชัน FCM และแสดงเมทริกซ์ความเข้ากันได้ของเฟรมเวิร์กในเวอร์ชัน FCM สำหรับการจัดส่งดังกล่าว (รวมบางส่วนด้วย
HAL ที่ไม่บังคับจากเมทริกซ์ความเข้ากันได้ในเวอร์ชัน FCM สูงกว่า)
การแข่งขัน HAL
กฎการจับคู่ HAL จะระบุเวอร์ชันขององค์ประกอบ hal
ใน
ไฟล์ Manifest ที่เจ้าของ
เมทริกซ์ความเข้ากันได้
HIDL และ HAL แบบเนทีฟ
กฎการจับคู่สำหรับ HIDL และ HAL แบบดั้งเดิมมีดังนี้
- องค์ประกอบ
<hal>
หลายรายการจะได้รับการประเมินด้วย AND เพียงครั้งเดียว ความสัมพันธ์ - องค์ประกอบ
<hal>
อาจมี<hal optional="true">
เพื่อทำเครื่องหมายว่าเป็น ไม่จำเป็น - องค์ประกอบ
<version>
หลายรายการภายในองค์ประกอบเดียวกัน<hal>
มี OR หากระบุ 2 รายการขึ้นไป ต้องมีการติดตั้งใช้งานเวอร์ชันใดเวอร์ชันหนึ่ง (ดูตัวอย่าง DRM ด้านล่าง) <instance>
และหลายรายการ<regex-instance>
องค์ประกอบภายในองค์ประกอบเดียวกัน<hal>
จะได้รับการประเมินด้วยความสัมพันธ์แบบ AND เดียวเมื่อ ต้องระบุ<hal>
(ดู<ahref="#drm">ตัวอย่าง DRM ด้านล่าง)</ahref="#drm">
ตัวอย่าง: การจับคู่ HAL ที่สำเร็จสำหรับโมดูล
สำหรับ HAL ในเวอร์ชัน 2.5 กฎการจับคู่จะเป็นดังนี้
เมทริกซ์ | ไฟล์ Manifest ที่ตรงกัน |
---|---|
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
HAL ของ AIDL
Android ทุกเวอร์ชันที่ใหม่กว่า Android 11 (ไม่รวม Android
11) รองรับเวอร์ชันสำหรับ AIDL HAL ใน VINTF
กฎการจับคู่สำหรับ AIDL HAL คล้ายกับ HIDL และ HAL แบบเนทีฟ เว้นแต่ว่า
ไม่มีเวอร์ชันหลัก และมีเวอร์ชัน 1 เวอร์ชันต่ออินสแตนซ์ HAL เท่านั้น (1
หาก
ไม่ได้ระบุเวอร์ชัน)
- องค์ประกอบ
<hal>
หลายรายการจะได้รับการประเมินด้วย AND เพียงครั้งเดียว ความสัมพันธ์ - องค์ประกอบ
<hal>
อาจมี<hal optional="true">
เพื่อทำเครื่องหมายว่าเป็น ไม่จำเป็น <instance>
และหลายรายการ<regex-instance>
องค์ประกอบภายในองค์ประกอบเดียวกัน<hal>
จะได้รับการประเมินด้วยความสัมพันธ์แบบ AND เดียวเมื่อ ต้องระบุ<hal>
(ดู<ahref="#vibrator">ตัวอย่างการสั่นด้านล่าง)</ahref="#vibrator">
ตัวอย่าง: การจับคู่ HAL ที่สำเร็จสำหรับโมดูล
สำหรับ HAL ในเวอร์ชัน 5 กฎการจับคู่จะเป็นดังนี้
เมทริกซ์ | ไฟล์ Manifest ที่ตรงกัน |
---|---|
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 ของอุปกรณ์
จับคู่ Branch ของเคอร์เนล
คำต่อท้ายของ Branch ของเคอร์เนลแต่ละรายการ (เช่น 5.4-r
) จะแมปกับค่า
เวอร์ชัน FCM ของเคอร์เนล (เช่น 5) การแมปจะเหมือนกับการแมประหว่างตัวอักษรแสดง
(เช่น เวอร์ชัน R) และเวอร์ชัน FCM (เช่น 5)
การทดสอบ VTS จะบังคับให้อุปกรณ์ระบุเวอร์ชัน FCM ของเคอร์เนลอย่างชัดเจนใน
ไฟล์ Manifest ของอุปกรณ์ /vendor/etc/vintf/manifest.xml
หากข้อใดข้อหนึ่งต่อไปนี้เป็นจริง
-
เวอร์ชัน FCM ของเคอร์เนลแตกต่างจากเวอร์ชัน FCM เป้าหมาย ตัวอย่างเช่น พารามิเตอร์
อุปกรณ์ข้างต้นมี FCM เป้าหมายเวอร์ชัน 4 และเคอร์เนลเวอร์ชัน FCM คือ 5 (เคอร์เนล
คำต่อท้ายสาขา
r
) -
เวอร์ชัน FCM ของเคอร์เนลมากกว่าหรือเท่ากับ 5 (คำต่อท้ายของสาขาเคอร์เนล
r
)
การทดสอบ VTS จะบังคับใช้ว่า หากระบุเวอร์ชันเคอร์เนล FCM เวอร์ชัน FCM ของเคอร์เนลจะเป็น มากกว่าหรือเท่ากับเวอร์ชัน FCM เป้าหมายในไฟล์ Manifest ของอุปกรณ์
ตัวอย่าง: ระบุ Branch ของเคอร์เนล
หากอุปกรณ์มี FCM เป้าหมายเวอร์ชัน 4 (เปิดตัวใน Android 10) แต่
เรียกใช้เคอร์เนลจาก Branch 4.19-r
ไฟล์ Manifest ของอุปกรณ์ควรระบุข้อมูลต่อไปนี้
<manifest version="2.0" type="device" target-level="4"> <kernel target-level="5" /> </manifest>
ออบเจ็กต์ VINTF จะตรวจสอบความเข้ากันได้ของเคอร์เนลกับข้อกำหนดในเคอร์เนล 4.19-r
Branch ซึ่งระบุใน FCM เวอร์ชัน 5 ข้อกำหนดเหล่านี้สร้างขึ้นจาก
kernel/configs/r/android-4.19
ในแผนผังแหล่งที่มาของ Android
ตัวอย่าง: กำหนดสาขาเคอร์เนลสำหรับ GKI
หากอุปกรณ์ใช้อิมเมจเคอร์เนลทั่วไป (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 เป้าหมาย | เวอร์ชันของ Kernel 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>
ระบบจะจับคู่สาขาเคอร์เนลก่อน มีการระบุ Branch ของเคอร์เนลในไฟล์ Manifest ของอุปกรณ์
ใน manifest.kernel.target-level
ซึ่งมีค่าเริ่มต้นเป็น manifest.level
หากไม่ได้ระบุ หากสาขาเคอร์เนลในไฟล์ Manifest ของอุปกรณ์
- คือ 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
ใน Bootloaderro.boot.avb_version
คือเวอร์ชันlibavb
ใน ระบบปฏิบัติการ Android (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
Bootloader หรือระบบปฏิบัติการ Android อาจมี libavb
อยู่ 2 สำเนา
ไลบรารี โดยแต่ละไลบรารีจะมีเวอร์ชัน MAJOR แตกต่างกันสำหรับอัปเกรดอุปกรณ์และเปิดตัว
อุปกรณ์ ในกรณีนี้ ให้แชร์อิมเมจระบบที่ไม่ได้รับการรับรองเดียวกัน แต่
อิมเมจระบบ Signed สุดท้ายนั้นแตกต่างกัน (ที่มี
avb.vbmeta-version
)
รูปที่ 1 เวอร์ชัน AVB ตรงกัน (/ระบบคือ 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 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
ที่ได้จากเฟรมเวิร์กในไฟล์ Manifest ของเฟรมเวิร์ก หากรายการนั้นไม่
อยู่ ไม่พบรายการที่ตรงกัน
หากมีรายการดังกล่าวอยู่ ชุดไลบรารีที่แจกแจงในอุปกรณ์ เมทริกซ์ความเข้ากันได้ต้องเป็นชุดย่อยของชุดไลบรารีที่ระบุไว้ใน ไฟล์ Manifest ของเฟรมเวิร์ก มิฉะนั้น รายการจะถือว่าตรงกัน
- นี่เป็นกรณีพิเศษ ถ้าไม่ได้แจกแจงไลบรารีในอุปกรณ์ เมทริกซ์ความเข้ากันได้ รายการจะถือว่าเป็นคู่กันเสมอ เนื่องจากว่างเปล่า เซ็ตคือเซ็ตย่อยของเซต
ตัวอย่าง: การจับคู่เวอร์ชัน VNDK สำเร็จ
หากเมทริกซ์ความเข้ากันได้ของอุปกรณ์ระบุข้อกำหนดต่อไปนี้สำหรับ VNDK
<!-- Example Device Compatibility Matrix --> <vendor-ndk> <version>27</version> <library>libjpeg.so</library> <library>libbase.so</library> </vendor-ndk>
ในไฟล์ Manifest ของเฟรมเวิร์กจะมีการพิจารณาเฉพาะรายการที่มีเวอร์ชัน 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 อยู่ในไฟล์ 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 จะอยู่ในกรอบการทำงาน
ไฟล์ Manifest libjpeg.so
ใช้ไม่ได้กับเฟรมเวิร์กในส่วนนั้น
ระบบจะไม่พิจารณา VNDK เวอร์ชัน 26
เวอร์ชัน SDK ของระบบตรงกัน
เมทริกซ์ความเข้ากันได้ของอุปกรณ์จะประกาศชุด System SDK ที่จำเป็น
ใน compatibility-matrix.system-sdk.version
มี
จับคู่เฉพาะในกรณีที่ชุดเป็นชุดย่อยของเวอร์ชัน System SDK ที่ระบุตามที่ประกาศไว้
ใน manifest.system-sdk.version
ในไฟล์ Manifest ของเฟรมเวิร์ก
- ในกรณีพิเศษนี้ หากไม่ได้ระบุเวอร์ชันของ System SDK ในอุปกรณ์ เมทริกซ์ความเข้ากันได้ จะถือว่าเป็นคู่ที่ตรงกันเสมอ เนื่องจากว่างเปล่า เซ็ตคือเซ็ตย่อยของเซต
ตัวอย่าง: การจับคู่เวอร์ชัน SDK ของระบบสำเร็จ
หากเมทริกซ์ความเข้ากันได้ของอุปกรณ์ระบุข้อกำหนดต่อไปนี้ในระบบ SDK
<!-- Example Device Compatibility Matrix --> <system-sdk> <version>26</version> <version>27</version> </system-sdk>
จากนั้นเฟรมเวิร์กต้องมี 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 ไม่ตรงกันเนื่องจากไม่มี SDK ระบบเวอร์ชัน 27 ระบุไว้