กฎการจับคู่

เมทริกซ์ความเข้ากันได้และไฟล์ 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 รายการขึ้นไป คุณจะต้องใช้เพียงเวอร์ชันใดเวอร์ชันหนึ่งเท่านั้น (ดูHAL ตรงกันสําหรับ โมดูล DRM)
• องค์ประกอบ <instance> และ <regex-instance> หลายรายการภายในองค์ประกอบ <hal> เดียวกันจะได้รับการประเมินด้วยความสัมพันธ์ AND เดียวเมื่อต้องระบุ <hal> (ดูการจับคู่ HAL ที่สำเร็จสำหรับโมดูล DRM)

ตัวอย่าง: การจับคู่ HAL ของโมดูลสําเร็จ

สำหรับ HAL ที่เวอร์ชัน 2.5 กฎการจับคู่จะเป็นดังนี้

ตัวอย่าง: การจับคู่ 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 ขึ้นไปรองรับเวอร์ชันสำหรับ AIDL HAL ใน VINTF กฎการจับคู่สำหรับ AIDL HAL จะคล้ายกับกฎของ HIDL และ HAL ดั้งเดิม ยกเว้นว่า ไม่มีเวอร์ชันหลัก และมีเวอร์ชันเดียวต่ออินสแตนซ์ HAL (1 หาก ไม่ได้ระบุเวอร์ชัน)

• องค์ประกอบ <hal> หลายรายการจะได้รับการประเมินด้วยความสัมพันธ์ AND รายการเดียว
• องค์ประกอบ <hal> มี <hal optional="true"> เพื่อทำเครื่องหมายว่า ไม่จำเป็น
• องค์ประกอบ <instance> และ <regex-instance> หลายรายการภายใน <hal> เดียวกันจะได้รับการประเมินด้วยความสัมพันธ์ AND เดียวเมื่อต้องระบุ <hal> (ดูการจับคู่ HAL ที่สำเร็จสำหรับโมดูลหลายรายการ)

ตัวอย่าง: การจับคู่ HAL ของโมดูลสําเร็จ

สำหรับ HAL ที่เวอร์ชัน 5 กฎการจับคู่จะเป็นดังนี้

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

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

ตัวอย่าง: กำหนดสาขาเคอร์เนล

หากอุปกรณ์มี FCM เวอร์ชันเป้าหมายเป็น 4 (เปิดตัวใน Android 10) แต่ใช้เคอร์เนลจากสาขา 4.19-r ไฟล์ Manifest ของอุปกรณ์ควรระบุข้อมูลต่อไปนี้

<manifest version="2.0" type="device" target-level="4">
   <kernel target-level="5" />
</manifest>

ออบเจ็กต์ VINTF จะตรวจสอบความเข้ากันได้ของเคอร์เนลกับข้อกำหนดใน4.19-r kernel branch ซึ่งระบุไว้ใน 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 ร่วมกัน

กำหนดค่าเคอร์เนลที่ตรงกัน

หากส่วน <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> หมายความว่าต้องไม่มี config item ใน /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>

ระบบจะจับคู่สาขาเคอร์เนลก่อน ระบุสาขาเคอร์เนลในไฟล์ Manifest ของอุปกรณ์ ใน manifest.kernel.target-level ซึ่งค่าเริ่มต้นคือ manifest.level หากไม่ได้ระบุค่าแรก

• หากสาขาเคอร์เนลในไฟล์ Manifest ของอุปกรณ์เป็น 1 กระบวนการจะไปยังขั้นตอนถัดไปและ ตรวจสอบเวอร์ชันเคอร์เนล
• หากสาขาเคอร์เนลในไฟล์ Manifest ของอุปกรณ์เป็น 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

การจับคู่ SEPolicy

SEPolicy ต้องมีการจับคู่ต่อไปนี้

• <sepolicy-version> จะกำหนดช่วงเวอร์ชันย่อยที่ปิดสำหรับทุกเวอร์ชันหลัก เวอร์ชัน SEPolicy ที่อุปกรณ์รายงาน ต้องอยู่ในช่วงใดช่วงหนึ่งต่อไปนี้จึงจะเข้ากันได้กับเฟรมเวิร์ก กฎการจับคู่ จะคล้ายกับเวอร์ชัน HAL โดยจะถือว่าตรงกันหากเวอร์ชัน SEPolicy สูงกว่าหรือเท่ากับเวอร์ชันขั้นต่ำสำหรับช่วง เวอร์ชันสูงสุดเป็นเพียงข้อมูลเท่านั้น
• <kernel-sepolicy-version> ซึ่งก็คือเวอร์ชัน DB ของนโยบาย ต้อง น้อยกว่า security_policyvers() ที่อุปกรณ์รายงาน

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

เมทริกซ์ความเข้ากันได้ของเฟรมเวิร์กระบุข้อมูล 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 แสดงว่าตรงกัน
• เวอร์ชัน SEPolicy ต้องเป็น 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 (และแสดงผลเป็น OK) ไม่มีหากเกิดการยืนยันไม่สำเร็จ (หรือไม่มีการยืนยันเลย)

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

• sysprop ro.boot.vbmeta.avb_version with 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 with 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 ที่แตกต่างกันสำหรับอุปกรณ์ที่อัปเกรดและอุปกรณ์ที่เปิดตัว ในกรณีนี้ คุณสามารถแชร์อิมเมจระบบที่ไม่ได้ลงนามเดียวกันได้ แต่ อิมเมจระบบที่ลงนามสุดท้ายจะแตกต่างกัน (มี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
   • CL 732261
   • CL 732262
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 ที่เฟรมเวิร์กจัดเตรียมไว้ในไฟล์ 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 ของเฟรมเวิร์ก

• ในกรณีพิเศษ หากไม่มีการแจงนับเวอร์ชัน 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>

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