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