กฎการจับคู่

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

การตรวจสอบนี้เสร็จสิ้น ณ เวลาสร้าง เวลาสร้างแพ็คเกจการอัปเดต 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 เป็นเวอร์ชันขั้นต่ำที่จำเป็น ซึ่งหมายความว่าไฟล์ 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

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 เป็นเวอร์ชันขั้นต่ำที่จำเป็น ซึ่งหมายความว่าไฟล์ 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 อย่างชัดเจนในรายการอุปกรณ์ /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 ที่แตกต่างกัน):

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

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

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

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

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

ตัวอย่าง: การจับคู่เวอร์ชัน 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