กฎการจับคู่

คู่เมทริกซ์ความเข้ากันได้และไฟล์ Manifest 2 คู่มีไว้เพื่อปรับยอดเพื่อยืนยันว่าเฟรมเวิร์กและการใช้งานของผู้ให้บริการทำงานร่วมกันได้ การตรวจสอบนี้จะสำเร็จเมื่อตารางความเข้ากันได้ของเฟรมเวิร์กกับไฟล์ Manifest ของอุปกรณ์ตรงกัน รวมถึงเมื่อไฟล์ Manifest ของเฟรมเวิร์กกับตารางความเข้ากันได้ของอุปกรณ์ตรงกัน

การยืนยันนี้จะดำเนินการเมื่อสร้าง ขณะอัปเดต OTA ขณะสร้างแพ็กเกจ ขณะบูต และในการทดสอบความเข้ากันได้ของ VTS

ส่วนต่อไปนี้จะอธิบายกฎการจับคู่โดยละเอียดซึ่งองค์ประกอบต่างๆ ใช้

เวอร์ชันเมทริกซ์ความเข้ากันได้ของเฟรมเวิร์กตรงกัน

หากต้องการจับคู่ไฟล์ Manifest ของอุปกรณ์กับเมทริกซ์ความเข้ากันได้ของเฟรมเวิร์ก เวอร์ชัน FCM ที่จัดส่งซึ่งระบุโดย manifest.target-level ต้องเท่ากับเวอร์ชัน FCM ที่ระบุโดย compatibility-matrix.level ทุกประการ หากไม่มีข้อมูลที่ตรงกัน

เมื่อมีการขอเมทริกซ์ความเข้ากันได้ของเฟรมเวิร์กด้วย libvintf การจับคู่นี้จะสำเร็จเสมอเนื่องจาก libvintf จะเปิดไฟล์ Manifest ของอุปกรณ์ ดึงข้อมูลเวอร์ชัน FCM ที่ใช้งานจริง และแสดงผลเมทริกซ์ความเข้ากันได้ของเฟรมเวิร์กในเวอร์ชัน FCM ที่ใช้งานจริงนั้น (รวมถึง HAL บางรายการที่ไม่บังคับจากเมทริกซ์ความเข้ากันได้ในเวอร์ชัน FCM ที่สูงกว่า)

รายการที่ตรงกันของ HAL

กฎ HAL-match จะระบุเวอร์ชันขององค์ประกอบ 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 กฎการจับคู่จะเป็นดังนี้

Matrix	ไฟล์ Manifest ที่ตรงกัน
2.5	2.5-2.∞ ในตารางความเข้ากันได้ 2.5 คือตัวย่อของ 2.5-5
2.5-7	2.5-2.∞ ระบุข้อมูลต่อไปนี้ 2.5 เป็นเวอร์ชันขั้นต่ำที่ต้องการ ซึ่งหมายความว่าไฟล์ Manifest ที่ระบุ HAL 2.0-2.4 จะใช้งานร่วมกันไม่ได้ 2.7 เป็นเวอร์ชันสูงสุดที่ขอได้ ซึ่งหมายความว่าเจ้าของเมทริกซ์ความเข้ากันได้ (เฟรมเวิร์กหรืออุปกรณ์) จะไม่ขอเวอร์ชันที่สูงกว่า 2.7 เจ้าของไฟล์ Manifest ที่ตรงกันจะยังคงแสดงเวอร์ชัน 2.10 (เป็นตัวอย่าง) ได้เมื่อมีการขอ 2.7 เจ้าของตารางความเข้ากันได้จะทราบเพียงว่าบริการที่ขอใช้งานร่วมกับ API เวอร์ชัน 2.7 ได้ -7 มีไว้เพื่อแจ้งข้อมูลเท่านั้นและไม่ส่งผลต่อกระบวนการอัปเดต OTA ด้วยเหตุนี้ อุปกรณ์ที่มี HAL เวอร์ชัน 2.10 ในไฟล์ Manifest จะยังคงเข้ากันได้กับเฟรมเวิร์กซึ่งระบุ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 กฎการจับคู่จะเป็นดังนี้

Matrix	ไฟล์ Manifest ที่ตรงกัน
5	5-∞ ในตารางความเข้ากันได้ 5 เป็นตัวย่อของ 5-5
5-7	5-∞ หมายถึงข้อมูลต่อไปนี้ 5 เป็นเวอร์ชันขั้นต่ำที่จำเป็น ซึ่งหมายความว่าไฟล์ Manifest ที่ระบุ HAL 1-4 จะใช้ร่วมกันไม่ได้ 7 เป็นเวอร์ชันสูงสุดที่ขอได้ ซึ่งหมายความว่าเจ้าของเมทริกซ์ความเข้ากันได้ (เฟรมเวิร์กหรืออุปกรณ์) จะไม่ขอเวอร์ชันเกิน 7 เจ้าของไฟล์ Manifest ที่ตรงกันจะยังคงแสดงเวอร์ชัน 10 (เป็นตัวอย่าง) ได้เมื่อมีการขอเวอร์ชัน 7 เจ้าของตารางความเข้ากันได้จะทราบเพียงว่าบริการที่ขอใช้งานร่วมกับ API เวอร์ชัน 7 ได้ -7 มีไว้เพื่อแจ้งข้อมูลเท่านั้นและไม่ส่งผลต่อกระบวนการอัปเดต OTA ดังนั้น อุปกรณ์ที่มี HAL ที่เวอร์ชัน 10 ในไฟล์ Manifest จะยังคงเข้ากันได้กับเฟรมเวิร์กที่ระบุ 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 ของเคิร์นัลอย่างชัดเจนในไฟล์ Manifest ของอุปกรณ์ /vendor/etc/vintf/manifest.xml ในกรณีใดกรณีหนึ่งต่อไปนี้

• เวอร์ชัน FCM ของเคอร์เนลแตกต่างจากเวอร์ชัน FCM เป้าหมาย ตัวอย่างเช่น อุปกรณ์ที่กล่าวถึงมี FCM เป้าหมายเวอร์ชัน 4 และเวอร์ชัน FCM ของเคอร์เนลคือ 5 (ส่วนต่อท้ายสาขาเคอร์เนล r)
• เวอร์ชัน FCM ของเคอร์เนลมากกว่าหรือเท่ากับ 5 (นามสกุลสาขาเคอร์เนล r)

หมายเหตุ: หากเวอร์ชัน FCM ของเคิร์กเนลเท่ากับเวอร์ชัน FCM เป้าหมายและเวอร์ชันดังกล่าวมากกว่าหรือเท่ากับ 5 ไฟล์ต้นทางของไฟล์ Manifest ของอุปกรณ์ที่ระบุโดย DEVICE_MANIFEST_FILE จะไม่จําเป็นต้องระบุเวอร์ชัน FCM ของเคิร์กเนล assemble_vintf จะอนุมานเวอร์ชัน FCM ของเคอร์เนลโดยอัตโนมัติจากเวอร์ชัน FCM เป้าหมายหากเวอร์ชัน FCM เป้าหมายมากกว่าหรือเท่ากับ 5

การทดสอบ VTS จะบังคับใช้ว่าหากระบุเวอร์ชัน FCM ของเคอร์เนล เวอร์ชัน FCM ของเคอร์เนลจะมากกว่าหรือเท่ากับเวอร์ชัน FCM เป้าหมายในไฟล์ Manifest ของอุปกรณ์

ตัวอย่าง: ระบุสาขาเคอร์เนล

หากอุปกรณ์มี 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 ซึ่งระบุอยู่ใน 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 เป้าหมาย	เวอร์ชันของ Kernel FCM	เวอร์ชันเคอร์เนล	จับคู่กับ
3 (P)	ไม่ระบุ	4.4.106	ไม่พบรายการที่ตรงกัน (เวอร์ชันย่อยไม่ตรงกัน)
3 (P)	ไม่ระบุ	4.4.107	4.4-p
3 (P)	ไม่ระบุ	4.19.42	4.19-q (ดูหมายเหตุด้านล่าง)
3 (P)	ไม่ระบุ	5.4.41	5.4-r (ดูหมายเหตุด้านล่าง)
3 (จุด)	3 (จุด)	4.4.107	4.4-p
3 (จุด)	3 (P)	4.19.42	ไม่พบรายการที่ตรงกัน (ไม่มีสาขาเคอร์เนล 4.19-p)
3 (P)	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 (R)	ไม่ระบุ	ใดๆ	VTS ไม่สําเร็จ (ต้องระบุเวอร์ชัน FCM ของเคอร์เนลสําหรับ FCM เป้าหมายเวอร์ชัน 5)
5 (R)	4 (ค)	ใดๆ	VTS ไม่สําเร็จ (เวอร์ชัน FCM ของเคอร์เนล < เวอร์ชัน FCM เป้าหมาย)
5 (R)	5 (R)	4.14.180	4.14-r

หมายเหตุ: สําหรับอุปกรณ์ที่มีเวอร์ชัน FCM เป้าหมายต่ำกว่า 5 (R) และเวอร์ชัน FCM ของเคอร์เนลที่ไม่ระบุ ออบเจ็กต์ VINTF จะเลือกสาขาเคอร์เนลที่มีนามสกุลต่ำสุดซึ่งมากกว่าเวอร์ชัน FCM เป้าหมายที่มีเวอร์ชันเคอร์เนลที่ตรงกัน ในตัวอย่างข้างต้น อุปกรณ์ที่มี FCM เวอร์ชันเป้าหมาย 3 (P) จะใช้สาขาเคอร์เนล 4.19-q เนื่องจาก 4.19-q มีนามสกุลต่ำสุดในบรรดาสาขาเคอร์เนล 4.19-* ทั้งหมด ซึ่งก็คือ [4.19-q, 4.19-r, 4.19-s] ระบบไม่อนุญาตให้อุปกรณ์ที่มี FCM เวอร์ชันเป้าหมาย 5 (R) ขึ้นไปใช้ลักษณะการเลือกข้อกำหนดนี้ เนื่องจากต้องระบุเวอร์ชัน FCM ของเคอร์เนล

จับคู่การกำหนดค่าเคอร์เนล

หากส่วน <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 หรือเทียบเท่าเลขฐาน 16

ตัวอย่าง: การจับคู่เคอร์เนลที่สำเร็จ

เมทริกซ์ความเข้ากันได้ของเฟรมเวิร์กที่มี 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 ให้ไปยังขั้นตอนถัดไปและตรวจสอบเวอร์ชันเคอร์เนล
• is 2, no match to matrix. ออบเจ็กต์ 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"> where 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 (เช่น 1.0, 2.1) โปรดดูรายละเอียดที่หัวข้อการกำหนดเวอร์ชันและความเข้ากันได้ เวอร์ชัน AVB มีพร็อพเพอร์ตี้ระบบต่อไปนี้

• ro.boot.vbmeta.avb_version เป็น Bootloader เวอร์ชัน libavb
• ro.boot.avb_version เป็นเวอร์ชัน libavb ในระบบปฏิบัติการ Android (init/fs_mgr)

พร็อพเพอร์ตี้ของระบบจะปรากฏขึ้นก็ต่อเมื่อมีการใช้ libavb ที่เกี่ยวข้องเพื่อยืนยันข้อมูลเมตา AVB (และแสดงผลเป็น "OK") จะไม่มีสถานะนี้หากการยืนยันไม่สำเร็จ (หรือไม่มีการยืนยันเลย)

การจับคู่ความเข้ากันได้จะเปรียบเทียบข้อมูลต่อไปนี้

• sysprop ro.boot.vbmeta.avb_version with avb.vbmeta-version from framework compatibility matrix;
  • 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 สำเนา โดยแต่ละรายการมีเวอร์ชันหลักแตกต่างกันสำหรับอุปกรณ์ที่อัปเกรดและอุปกรณ์ที่เปิดตัว ในกรณีนี้ จะแชร์รูปภาพระบบที่ไม่ได้ลงชื่อเดียวกันได้ แต่อิมเมจระบบสุดท้ายที่มีลายเซ็นจะแตกต่างกัน (มี avb.vbmeta-version ต่างกัน) ดังนี้

รูปที่ 1 เวอร์ชัน AVB ตรงกัน (/system คือ 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 11

สำหรับอุปกรณ์ที่เปิดตัวด้วย Android 9 หรือต่ำกว่า เมื่ออัปเดตเป็น Android 10 ระบบจะจับคู่ข้อกำหนดเวอร์ชัน AVB ในตารางความเข้ากันได้ของเฟรมเวิร์กกับเวอร์ชัน AVB ปัจจุบันในอุปกรณ์ หากเวอร์ชัน AVB มีการอัปเกรดเวอร์ชันหลักระหว่าง OTA (เช่น จาก 0.0 เป็น 1.0) การตรวจสอบความเข้ากันได้ของ VINTF ใน OTA จะไม่แสดงถึงความเข้ากันได้หลัง OTA

OEM อาจวาง AVB เวอร์ชันปลอมไว้ในแพ็กเกจ OTA เพื่อบรรเทาปัญหา (compatibility.zip) เพื่อผ่านการตรวจสอบ โดยทำดังนี้

1. เลือก CL ต่อไปนี้มาใส่ในซอร์สทรีของ Android 9
   • CL 732261
   • CL 732262
2. กำหนด BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE สำหรับอุปกรณ์ ค่าของ AVB ควรเท่ากับเวอร์ชัน AVB ก่อน OTA กล่าวคือเวอร์ชัน AVB ของอุปกรณ์เมื่อเปิดตัว
3. สร้างแพ็กเกจ 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>

ตัวอย่าง ก เป็นการจับคู่ที่ตรงกัน เนื่องจาก 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>

ตัวอย่าง ข. ไม่ตรงกัน แม้ว่า VNDK เวอร์ชัน 27 จะอยู่ในไฟล์ Manifest ของเฟรมเวิร์ก แต่เฟรมเวิร์กในสแนปชอตนั้นยังไม่รองรับ libjpeg.so ระบบจะไม่พิจารณา VNDK เวอร์ชัน 26

เวอร์ชัน SDK ของระบบตรงกัน

เมตริกซ์ความเข้ากันได้ของอุปกรณ์จะประกาศชุด SDK ของระบบเวอร์ชันที่จำเป็นใน compatibility-matrix.system-sdk.version ระบบจะจับคู่ก็ต่อเมื่อชุดนั้นเป็นชุดย่อยของเวอร์ชัน SDK ของระบบที่ระบุตามที่ประกาศไว้ใน manifest.system-sdk.version ในไฟล์ Manifest ของเฟรมเวิร์ก

• ในกรณีพิเศษ หากไม่มีการระบุเวอร์ชันของ System SDK ในเมทริกซ์ความเข้ากันได้ของอุปกรณ์ ระบบจะถือว่าเป็นการจับคู่ที่ตรงกันเสมอ เนื่องจากชุดที่ว่างเปล่าเป็นส่วนย่อยของชุดใดๆ

ตัวอย่าง: การจับคู่เวอร์ชัน SDK ของระบบสําเร็จ

หากตารางความเข้ากันได้ของอุปกรณ์ระบุข้อกำหนดต่อไปนี้ใน System 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>

ตัวอย่าง ก. ตรงกัน

<!-- Framework Manifest Example B -->
<system-sdk>
    <version>26</version>
    <version>27</version>
    <version>28</version>
</system-sdk>

ตัวอย่าง ข. ตรงกัน

<!-- Framework Manifest Example C -->
<system-sdk>
    <version>26</version>
</system-sdk>

ตัวอย่าง ค ไม่ตรงกันเนื่องจากไม่ได้ระบุ System SDK เวอร์ชัน 27