เลือกแพตช์ต่อไปนี้เพื่อแก้ไขปัญหาที่ทราบต่อไปนี้
ตรวจสอบพื้นที่ที่จัดสรรได้ถูกต้องเมื่อโหลดแอปจากแหล่งที่ไม่รู้จัก
การโหลดแพ็กเกจ OTA แบบเต็มในอุปกรณ์ A/B เสมือนที่มี Super
Partition ที่มีขนาดเล็กกว่า *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 ขัดข้อง นอกจากนี้ ยังอาจเกิดข้อผิดพลาดเกี่ยวกับพอยน์เตอร์ที่อาจไม่ถูกต้องเมื่อ markSlotSuccessful มาถึงช้า
ปัญหานี้ได้รับการแก้ไขโดยการเพิ่มฟังก์ชัน StopActionInternal
CleanupPreviousUpdateAction ยกเลิกงานที่รอดำเนินการเมื่อทำลาย โดยจะเก็บตัวแปรที่ติดตามรหัสงานของงานที่รอดำเนินการใน Message Loop เมื่อ
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ในเคอร์เนล- Bootloader ที่กำหนดค่าให้ใช้โหมดความถูกต้องใดก็ได้ (เช่น
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 เพื่อผสานรวม อิมเมจดังกล่าว การกำหนดค่า Virtual A/B อาจ
ถูกทิ้งอย่างไม่ถูกต้องในระหว่างกระบวนการผสานรวม หากต้องการตรวจสอบว่าการกำหนดค่า Virtual A/B
ในไฟล์เป้าหมายที่ผสานถูกต้อง ให้ใช้แพตช์ต่อไปนี้
CL
2084183
(ผสานคู่คีย์/ค่าที่เหมือนกันในข้อมูลพาร์ติชันแบบไดนามิก)
อัปเดตคอมโพเนนต์ที่จำเป็น
ตั้งแต่ Android 13 เป็นต้นไป เราได้ย้าย snapuserd จาก vendor ramdisk ไปยัง generic
ramdisk หากอุปกรณ์อัปเกรดเป็น Android 13 เป็นไปได้ว่าทั้ง
vendor ramdisk และ generic ramdisk จะมีสำเนาของ snapuserd ในกรณีนี้ Virtual A/B ต้องใช้สำเนาของระบบ snapuserd หากต้องการตรวจสอบว่ามีสำเนาที่ถูกต้องของ snapuserd ให้ใช้ CL
2031243
(คัดลอก snapuserd ไปยัง first_stage_ramdisk)