เลือกแพตช์ต่อไปนี้เพื่อแก้ไขปัญหาที่ทราบแล้ว
ตรวจสอบพื้นที่ที่กําหนดได้ถูกต้องเมื่อโหลดแอปจากแหล่งที่ไม่รู้จัก
การโหลดแพ็กเกจ 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: ยกเลิกงานที่รอดำเนินการในการทำลาย) - 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 เท่านั้น
- ตั้งค่า
CONFIG_DM_VERITY_AVB=nในเคอร์เนล - กําหนดค่าอุปกรณ์ให้ใช้โหมด
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 อาจเป็นไปได้ว่าทั้ง RAM ของผู้ให้บริการและ RAM ทั่วไปมีสำเนาของ snapuserd ในกรณีนี้ Virtual A/B ต้องใช้สำเนาระบบของ snapuserd โปรดใช้ CL
2031243 (คัดลอก snapuserd ไปยัง first_stage_ramdisk) เพื่อให้มั่นใจว่ามีsnapuserdสำเนาที่ถูกต้อง