ใช้การทดสอบ A/B เสมือนจริง - แพตช์

เลือกแพตช์ต่อไปนี้เพื่อแก้ไขปัญหาที่ทราบแล้ว

ตรวจสอบพื้นที่ที่จัดสรรได้ถูกต้องเมื่อไซด์โหลด

การโหลดแพ็กเกจ OTA แบบเต็มลงในอุปกรณ์ A/B เสมือนซึ่งมีพาร์ติชันหลักที่มีขนาดเล็กกว่า *2 * sum(size of update groups)* อาจไม่สำเร็จ โดยมีข้อความต่อไปนี้ในบันทึกการกู้คืน /tmp/recovery.log

The maximum size of all groups with suffix _b (...) has exceeded half of allocatable space for dynamic partitions ...

ตัวอย่างบันทึกมีดังนี้

[INFO:dynamic_partition_control_android.cc(1020)] Will overwrite existing partitions. Slot A may be unbootable until update finishes!
[...]
[ERROR:dynamic_partition_control_android.cc(803)] The maximum size of all groups with suffix _b (2147483648) has exceeded half of allocatable space for dynamic partitions 1073741824.

หากพบปัญหานี้ ให้เลือก CL 1399393 เพื่อสร้างใหม่และแฟลชพาร์ติชันการบูตหรือพาร์ติชันการกู้คืนหากอุปกรณ์ไม่ได้ใช้การกู้คืนเป็นบูต

แก้ไขข้อผิดพลาดของการแบ่งกลุ่มระหว่างการผสานรวม

หลังจากใช้การอัปเดต OTA แล้ว ในระหว่างกระบวนการผสาน VAB จะมีการเรียก update_engine_client --cancel ทำให้ CleanupPreviousUpdateAction ขัดข้อง นอกจากนี้ ยังมีข้อผิดพลาดเกี่ยวกับ Wild Pointer ที่อาจเกิดขึ้นเมื่อ markSlotSuccessful มาช้า

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

ตรวจสอบว่าการเปลี่ยนแปลงต่อไปนี้อยู่ในแผนผังแหล่งที่มาของ Android 11 เพื่อแก้ไข SIGSEGV ขัดข้องใน update_engine ระหว่างการรวม:

  • CL 1439792 (ก มาก่อนของ CL 1439372)
  • CL 1439372 (CleanupPreviousUpdateAction: cancel pending tasks on destroy)
  • CL 1663460 (แก้ไข อาจเป็นข้อผิดพลาดตัวระบุตำแหน่งเมื่อ markSlotSuccessful มาช้า)

ป้องกันไม่ให้ผสาน update_engine ก่อนเวลาอันควร

เมื่ออุปกรณ์เปิดเครื่อง (Android 11 ขึ้นไป) และการเปิดเครื่องเสร็จสมบูรณ์ update_engine โทรหา ScheduleWaitMarkBootSuccessful() และ WaitForMergeOrSchedule() ซึ่งจะเป็นการเริ่มกระบวนการผสานรวม แต่อุปกรณ์จะรีบูตกลับไปที่ช่องเก่า เนื่องจากเริ่มผสานแล้ว อุปกรณ์จึงบูตไม่สำเร็จและใช้งานไม่ได้

เพิ่มการเปลี่ยนแปลงต่อไปนี้ลงในสคีมาต้นทาง โปรดทราบว่า CL 1664859 เป็นตัวเลือก

  • CL 1439792 (ข้อกำหนดเบื้องต้นของ CL 1439372)
  • CL 1439372 (CleanupPreviousUpdateAction: cancel pending tasks on destroy)
  • CL 1663460 (แก้ไข อาจเป็นข้อผิดพลาดตัวระบุตำแหน่งเมื่อ markSlotSuccessful มาช้า)
  • CL 1664859 (ไม่บังคับ - เพิ่ม unittest สำหรับ CleanupPreviousUpdateAction)

ตรวจสอบการกําหนดค่า dm-verity ที่ถูกต้อง

ใน Android 11 ขึ้นไป อุปกรณ์อาจได้รับการกำหนดค่าด้วยตัวเลือก dm-verity ต่อไปนี้โดยไม่ตั้งใจ

  • CONFIG_DM_VERITY_AVB=y ในเคอร์เนล
  • บูตโหลดเดอร์ที่กำหนดค่าให้ใช้โหมด Verity ใดก็ได้ (เช่น AVB_HASHTREE_ERROR_MODE_RESTART_AND_INVALIDATE) โดยไม่ต้องใช้ AVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIO

ด้วยการกำหนดค่าอุปกรณ์นี้ ข้อผิดพลาดด้านความถูกต้องจะทำให้พาร์ติชัน vbmeta เกิดความเสียหาย และทำให้อุปกรณ์ที่ไม่ใช่ A/B ใช้งานไม่ได้ ในทำนองเดียวกัน หากการผสานเริ่มขึ้นแล้ว อุปกรณ์ A/B อาจใช้งานไม่ได้เช่นกัน ใช้เฉพาะ โหมดตรวจสอบ AVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIO

  1. ตั้งค่า CONFIG_DM_VERITY_AVB=n ในเคอร์เนล
  2. กำหนดค่าอุปกรณ์ที่จะใช้ โหมดAVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIOแทน

ดูข้อมูลเพิ่มเติมได้จากเอกสารยืนยันความถูกต้อง: การจัดการ dm-verity ข้อผิดพลาด

ยืนยันว่าไฟล์ที่ผสานได้รับการกําหนดค่าอย่างถูกต้อง

หากคุณสร้างอิมเมจระบบและอิมเมจของผู้ให้บริการแยกกัน ให้ใช้ merge_target_files เพื่อรวม การกำหนดค่า A/B เสมือนอาจ ถูกตัดออกอย่างไม่ถูกต้องระหว่างขั้นตอนการผสานรวม หากต้องการยืนยันว่าการกำหนดค่า A/B เสมือนถูกต้องในไฟล์เป้าหมายที่ผสาน ให้ใช้แพตช์ต่อไปนี้ CL 2084183 (ผสานคู่คีย์/ค่าที่เหมือนกันในข้อมูลพาร์ติชันแบบไดนามิก)

อัปเดตคอมโพเนนต์ที่จําเป็น

ตั้งแต่ Android 13 snapuserd ได้ย้ายจาก RAMdisk ของผู้ให้บริการไปยัง RAMdisk ทั่วไปแล้ว หากอุปกรณ์กำลังอัปเกรดเป็น Android 13 เป็นไปได้ว่าทั้งแรมดิสก์ของผู้ให้บริการและแรมดิสก์ทั่วไปจะมีสำเนาของ snapuserd ด้วยวิธีนี้ A/B เสมือนต้องการสำเนาระบบของ snapuserd โปรดใช้ CL 2031243 (คัดลอก snapuserd ไปยัง first_stage_ramdisk) เพื่อให้มั่นใจว่ามีsnapuserdสำเนาที่ถูกต้อง