กฎการจับคู่

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

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

รูปที่ 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. Cherry-เลือก CLs ต่อไปนี้ไปยังแผนผังต้นทางของ 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>

ตัวอย่างเช่นเป็นคู่เพราะ 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