เชอร์รี่เลือกแพตช์ต่อไปนี้เพื่อแก้ไขปัญหาที่ทราบต่อไปนี้
ตรวจสอบพื้นที่ที่จัดสรรได้อย่างถูกต้องเมื่อไซด์โหลด
ไซด์โหลดแพ็คเกจ OTA แบบเต็มบนอุปกรณ์ Virtual A/B ที่มีพาร์ติชันขั้นสูงที่มีขนาดน้อยกว่า *2 * ผลรวม (ขนาดของกลุ่มการอัปเดต)* อาจล้มเหลวด้วยสิ่งต่อไปนี้ในบันทึกการกู้คืน /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
ยกเลิกงานที่ค้างอยู่เมื่อทำลาย จะรักษาตัวแปรที่ติดตาม ID งานของงานที่ค้างอยู่ในลูปข้อความ เมื่อทำลาย งานที่ค้างอยู่จะถูกยกเลิกเพื่อหลีกเลี่ยงข้อผิดพลาด segfault
ตรวจสอบให้แน่ใจว่าการเปลี่ยนแปลงต่อไปนี้อยู่ในแผนผังต้นทาง Android 11 ของคุณเพื่อแก้ไขข้อขัดข้อง SIGSEGV
ใน update_engine
ระหว่างการผสาน:
- CL 1439792 (ข้อกำหนดเบื้องต้นสำหรับ CL 1439372)
- CL 1439372 (
CleanupPreviousUpdateAction
: ยกเลิกงานที่ค้างอยู่เมื่อทำลาย) - CL 1663460 (แก้ไขข้อผิดพลาด wild pointer ที่อาจเกิดขึ้นเมื่อ
markSlotSuccessful
มาช้า)
แก้ไขการสลับช่อง VAB ที่ไม่ถูกต้อง โพสต์การอัปเดต OTA
ใน Android 11 และสูงกว่า ความล้มเหลวในการซิงโครไนซ์สวิตช์สล็อตในอุปกรณ์หลังจากการอัปเดต OTA อาจทำให้อุปกรณ์อยู่ในสถานะใช้งานไม่ได้ หากการใช้งานการสลับสล็อตของ IBootControl
HAL ของคุณดำเนินการเขียน คุณต้องล้างการเขียนเหล่านั้นทันที หากการเขียนไม่ถูกล้าง และอุปกรณ์จะรีบูตหลังจากการผสานเริ่มต้น แต่ก่อนที่ฮาร์ดแวร์จะสามารถล้างการเขียนสล็อตสวิตช์ อุปกรณ์อาจเปลี่ยนกลับเป็นสล็อตก่อนหน้าและไม่สามารถบูตได้
สำหรับโซลูชันโค้ดตัวอย่าง ให้ดู CL: CL 1535570
ป้องกันการรวม update_engine ก่อนเวลาอันควร
เมื่ออุปกรณ์บู๊ต (Android 11 ขึ้นไป) และการบู๊ตเสร็จสิ้น update_engine
จะเรียก ScheduleWaitMarkBootSuccessful()
และ WaitForMergeOrSchedule()
นี่เป็นการเริ่มกระบวนการผสาน อย่างไรก็ตาม อุปกรณ์จะรีบูตไปที่ช่องเก่า เนื่องจากการผสานเริ่มต้นแล้ว อุปกรณ์ไม่สามารถบู๊ตได้และไม่สามารถใช้งานได้
เพิ่มการเปลี่ยนแปลงต่อไปนี้ลงในแผนผังต้นทางของคุณ โปรดทราบว่า CL 1664859 เป็นทางเลือก
- CL 1439792 (ข้อกำหนดเบื้องต้นสำหรับ CL 1439372)
- CL 1439372 (
CleanupPreviousUpdateAction
: ยกเลิกงานที่ค้างอยู่เมื่อทำลาย) - CL 1663460 (แก้ไขข้อผิดพลาด wild pointer ที่อาจเกิดขึ้นเมื่อ
markSlotSuccessful
มาช้า) - CL 1664859 (เป็นทางเลือก - เพิ่ม
unittest
สำหรับCleanupPreviousUpdateAction
)
ป้องกันข้อมูลสูญหายหรือเสียหายเนื่องจากการข้ามข้อมูลเมตา
ใน Android 11 ขึ้นไป หากอุปกรณ์จัดเก็บข้อมูลมีแคชการเขียนกลับที่มีความผันผวน ภายใต้เงื่อนไขบางประการ ข้อมูลเมตาของการผสานที่เสร็จสมบูรณ์จะถูกข้าม ส่งผลให้ข้อมูลสูญหายหรือเสียหาย
เงื่อนไข:
- หลังจากเสร็จสิ้นการดำเนินการผสานชุดข้อยกเว้นหนึ่งชุดแล้ว
merge_callback()
ก็ถูกเรียกใช้ - ข้อมูลเมตาได้รับการอัปเดตในอุปกรณ์ COW ที่ติดตามการผสานเสร็จสมบูรณ์ (การอัปเดตอุปกรณ์ COW นี้ถูกล้างอย่างหมดจด)
ผลลัพธ์: ระบบหยุดทำงานเนื่องจากแคชของอุปกรณ์จัดเก็บข้อมูลของการผสานล่าสุดไม่ได้รับการล้างข้อมูล
ดูสิ่งต่อไปนี้เพื่อดำเนินการแก้ไข:
ตรวจสอบให้แน่ใจว่าการกำหนดค่า dm-verity ถูกต้อง
ใน Android 11 ขึ้นไป อุปกรณ์สามารถกำหนดค่าโดยไม่ได้ตั้งใจด้วยตัวเลือก dm-verity ต่อไปนี้:
-
CONFIG_DM_VERITY_AVB=y
ในเคอร์เนล - bootloader กำหนดค่าให้ใช้โหมด 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 Errors
ข้ามการทำงานจริงเพื่อตอบสนองต่อข้อผิดพลาด I/O ระหว่างการปิดระบบฉุกเฉิน
ใน Android 11 ขึ้นไป หากมีการเรียกการปิดระบบฉุกเฉิน (เช่น ในกรณีของการปิดระบบระบายความร้อน) อุปกรณ์ dm จะสามารถคงอยู่ได้ในขณะที่อุปกรณ์บล็อกไม่สามารถประมวลผลคำขอ I/O ได้อีกต่อไป ในสถานะนี้ ข้อผิดพลาด I/O ที่ได้รับการจัดการโดยคำขอ dm I/O ใหม่ หรือโดยคำขอที่กำลังดำเนินการอยู่ อาจนำไปสู่สถานะความเสียหายตามความเป็นจริง ซึ่งเป็นการพิจารณาที่ผิด
หากต้องการข้ามการทำงานจริงเพื่อตอบสนองต่อข้อผิดพลาด I/O เมื่อระบบปิด ให้ใช้ดังต่อไปนี้:
CL 1847875 (ข้ามการทำงานจริงเพื่อตอบสนองต่อข้อผิดพลาด I/O ระหว่างการปิดระบบ)
ตรวจสอบให้แน่ใจว่า DM_ANDROID_VERITY_AT_MOST_ONCE_DEFAULT_ENABLED ปิดอยู่
อุปกรณ์ Android Go ที่ใช้เคอร์เนล 4.19 หรือเก่ากว่าอาจมี DM_ANDROID_VERITY_AT_MOST_ONCE_DEFAULT_ENABLED=y
ในการกำหนดค่าเคอร์เนล การตั้งค่านี้เข้ากันไม่ได้กับ Virtual A/B และเป็นที่ทราบกันว่าทำให้เกิดปัญหาความเสียหายของเพจซึ่งพบไม่บ่อยนักเมื่อเปิดใช้งานทั้งสองอย่างพร้อมกัน
สำหรับเคอร์เนล 4.19 และก่อนหน้า ให้ปิดการใช้งานโดยการตั้ง CONFIG_DM_ANDROID_VERITY_AT_MOST_ONCE_DEFAULT_ENABLED=n
ในการกำหนดค่าเคอร์เนล
สำหรับเคอร์เนล 5.4 และใหม่กว่า รหัสจะถูกลบออกและไม่มีตัวเลือกการกำหนดค่า
ยืนยันว่าไฟล์ที่ผสานได้รับการกำหนดค่าอย่างถูกต้อง
หากคุณกำลังสร้างอิมเมจระบบและอิมเมจของผู้จำหน่ายแยกกัน จากนั้นใช้ merge_target_files
เพื่อรวมเข้าด้วยกัน การกำหนดค่า A/B เสมือนอาจผิดพลาดอย่างไม่ถูกต้องในระหว่างกระบวนการผสาน หากต้องการตรวจสอบว่าการกำหนดค่า A/B เสมือนนั้นถูกต้องในไฟล์เป้าหมายที่ผสาน ให้ใช้แพตช์ต่อไปนี้: CL 2084183 (รวมคู่คีย์/วาลที่เหมือนกันในข้อมูลพาร์ติชันแบบไดนามิก)
อัปเดตส่วนประกอบที่จำเป็น
ตั้งแต่ Android 13 นั้น snapuserd
ได้ถูกย้ายจาก ramdisk ของผู้จำหน่ายไปยัง ramdisk ทั่วไป หากอุปกรณ์ของคุณอัปเกรดเป็น Android 13 อาจเป็นไปได้ว่าทั้ง ramdisk ของผู้จำหน่ายและ ramdisk ทั่วไปมีสำเนาของ snapuserd
ในสถานการณ์นี้ Virtual A/B จำเป็นต้องมีสำเนาระบบของ snapuserd
เพื่อให้แน่ใจว่ามีสำเนา snapuserd
ที่ถูกต้อง ให้ใช้ CL 2031243 (คัดลอก snapuserd
ไปที่ first_stage_ramdisk)