เมทริกซ์ความเข้ากันได้สองคู่และรายการมีขึ้นเพื่อกระทบยอดเพื่อตรวจสอบว่ากรอบงานและการใช้งานผู้ขายสามารถทำงานร่วมกันได้ การตรวจสอบนี้จะสำเร็จเมื่อจับคู่ระหว่างเมทริกซ์ความเข้ากันได้ของเฟรมเวิร์กกับรายการอุปกรณ์ รวมถึงระหว่างไฟล์รายการเฟรมเวิร์กกับเมทริกซ์ความเข้ากันได้ของอุปกรณ์
การตรวจสอบนี้จะทำเวลาที่สร้างที่ OTA เวลาในการสร้างแพคเกจการปรับปรุงในเวลาบูตและในการทดสอบความเข้ากันได้ VTS
ส่วนต่อไปนี้ให้รายละเอียดกฎการจับคู่ที่ใช้โดยส่วนประกอบต่างๆ
การจับคู่เวอร์ชันเมทริกซ์ความเข้ากันได้ของกรอบงาน
เพื่อให้ตรงกับประจักษ์อุปกรณ์ที่มีเมทริกซ์กรอบการทำงานร่วมกันในการจัดส่งสินค้ารุ่น FCM ระบุโดย manifest.target-level จะต้องเท่ากับรุ่น FCM ที่ระบุโดย compatibility-matrix.level มิฉะนั้นจะไม่มีการแข่งขัน
เมื่อเมทริกซ์กรอบการทำงานร่วมกันที่มีการร้องขอกับ libvintf ตรงนี้อยู่เสมอประสบความสำเร็จเพราะ libvintf เปิดประจักษ์อุปกรณ์ดึงข้อมูลการจัดส่งสินค้า FCM เวอร์ชันและผลตอบแทนเมทริกซ์กรอบการทำงานร่วมกันที่ว่าการจัดส่งสินค้า FCM เวอร์ชัน (บวกบาง HAL ที่ไม่จำเป็นจากการฝึกอบรมการทำงานร่วมกันที่ FCM สูง รุ่น)
การแข่งขัน HAL
ฮาลการแข่งขันระบุกฎรุ่นของ hal องค์ประกอบในไฟล์ Manifest ที่ถือว่าได้รับการสนับสนุนโดยเจ้าของของเมทริกซ์การทำงานร่วมกันที่สอดคล้องกัน
HIDL และ HAL ดั้งเดิม
กฎการจับคู่สำหรับ HIDL และ HAL ดั้งเดิมมีดังนี้
- หลาย
<hal>องค์ประกอบจะมีการประเมินมีเพียงหนึ่งเดียวและความสัมพันธ์ - หลาย
<version>องค์ประกอบภายในเดียวกัน<hal>มีหรือความสัมพันธ์ หากมีการระบุตั้งแต่สองเวอร์ชันขึ้นไป จะต้องดำเนินการเพียงหนึ่งเวอร์ชันเท่านั้น (ดู ตัวอย่าง DRM ด้านล่าง.) - หลาย
<instance>และ<regex-instance>องค์ประกอบภายในเดียวกัน<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 กฎการแข่งขัน HALs AIDL มีความคล้ายคลึงกับของ HIDL และ HALs พื้นเมืองยกเว้นว่ามีอยู่ไม่มีรุ่นที่สำคัญและมีอีกหนึ่งรุ่นต่อเช่น HAL ( 1 ถ้าเป็นรุ่นที่ไม่ได้ระบุ)
- หลาย
<hal>องค์ประกอบจะมีการประเมินมีเพียงหนึ่งเดียวและความสัมพันธ์ - หลาย
<instance>และ<regex-instance>องค์ประกอบภายในเดียวกัน<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> ส่วนของเมทริกซ์กรอบเข้ากันได้อธิบายถึงความต้องการกรอบของลินุกซ์บนอุปกรณ์ ข้อมูลนี้จะหมายถึงการถูกจับคู่กับ ข้อมูล เกี่ยวกับเมล็ดที่ได้รับรายงานจากวัตถุ 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) แต่วิ่ง kernel จาก 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
จับคู่เคอร์เนลเวอร์ชัน
เมทริกซ์สามารถรวมหลาย <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> ส่วนตรงตามความต้องการเหล่านี้ก็ไม่ใช่การแข่งขัน
ตัวอย่าง: เลือกข้อกำหนดสำหรับการจับคู่
พิจารณากรณีสมมุติต่อไปนี้ที่ FCMs ใน /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> จะตรงกับข้อความหลังเครื่องหมายเท่ากับ (รวมถึงคำพูด) ได้ถึงอักขระ newline หรือ # กับชั้นนำและต่อท้ายช่องว่างที่ถูกตัดทอน
การกำหนดค่าเคอร์เนลต่อไปนี้เป็นตัวอย่างของการจับคู่ที่สำเร็จ:
# 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 จะเป็นการจับคู่กันหากเวอร์ชันที่แบ่งแยกดินแดนสูงกว่าหรือเท่ากับเวอร์ชันต่ำสุดสำหรับช่วงนั้น เวอร์ชันสูงสุดเป็นเพียงข้อมูลเท่านั้น -
<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 (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 ห้องสมุดแต่ละคนมีรุ่นใหญ่ที่แตกต่างกันสำหรับอุปกรณ์การอัพเกรดและการเปิดตัวอุปกรณ์ ในกรณีนี้ภาพที่ได้รับการรับรองระบบเดียวกันสามารถใช้ร่วมกัน แต่สุดท้ายภาพระบบการลงนามจะแตกต่างกัน (ที่มีแตกต่างกัน 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> รายการด้วยการจับคู่ <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>
ตัวอย่างเช่นเป็นคู่เพราะ 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 ของระบบตรงกัน
เมทริกซ์เข้ากับอุปกรณ์ประกาศชุดของที่จำเป็นรุ่นระบบ 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