กฎการจับคู่

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

คู่เมทริกซ์ความเข้ากันได้และไฟล์ 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"> เพื่อทําเครื่องหมายว่าไม่จําเป็น คำเตือน: ระบบไม่รองรับ optional นี้อีกต่อไปหลังจาก Android 15
• องค์ประกอบ <version> หลายรายการภายใน <hal> เดียวกันมีความสัมพันธ์แบบ OR หากระบุมากกว่า 2 รายการ คุณต้องใช้เพียงเวอร์ชันเดียว (ดูตัวอย่าง DRM ด้านล่าง)
• ระบบจะประเมินองค์ประกอบ <instance> และ <regex-instance> หลายรายการภายใน <hal> เดียวกันด้วยความสัมพันธ์ AND รายการเดียวเมื่อต้องใช้ <hal> (ดู <ahref="#drm">ตัวอย่าง DRM ด้านล่าง)</ahref="#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 ทุกเวอร์ชันที่ใหม่กว่า Android 11 (ยกเว้น Android 11) รองรับเวอร์ชันสำหรับ AIDL HAL ใน VINTF กฎการจับคู่สำหรับ AIDL HAL จะคล้ายกับกฎของ HIDL และ HAL เดิม ยกเว้นว่าจะไม่มีเวอร์ชันหลัก และมีเพียง 1 เวอร์ชันต่ออินสแตนซ์ HAL (1 หากไม่ได้ระบุเวอร์ชัน)

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

ตัวอย่าง: การจับคู่ 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 เป้าหมายในไฟล์ Manifest ของอุปกรณ์ หากมีการระบุเวอร์ชัน FCM ของเคิร์นัล

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

หากอุปกรณ์มี 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เคอร์เนล สาขา ซึ่งระบุไว้ใน 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> หมายความว่ารายการการกําหนดค่าต้องไม่มีอยู่ใน /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 ให้ไปยังขั้นตอนถัดไปและตรวจสอบเวอร์ชันเคอร์เนล
• 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 เป็นเวอร์ชัน libavb ใน bootloader
• 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 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 ของระบบตรงกัน

เมตริกซ์ความเข้ากันได้ของอุปกรณ์จะประกาศชุด System 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>

จากนั้นเฟรมเวิร์กต้องระบุ System 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