เมทริกซ์ความเข้ากันได้ 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.MAJORro.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.MAJORro.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 ระบุไว้