ใช้ A/B เสมือน - แพตช์

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

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

ไซด์โหลดแพ็คเกจ 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 ขึ้นไป หากอุปกรณ์จัดเก็บข้อมูลมีแคชการเขียนกลับที่มีความผันผวน ภายใต้เงื่อนไขบางประการ ข้อมูลเมตาของการผสานที่เสร็จสมบูรณ์จะถูกข้าม ส่งผลให้ข้อมูลสูญหายหรือเสียหาย

เงื่อนไข:

  1. หลังจากเสร็จสิ้นการดำเนินการผสานชุดข้อยกเว้นหนึ่งชุดแล้ว merge_callback() ก็ถูกเรียกใช้
  2. ข้อมูลเมตาได้รับการอัปเดตในอุปกรณ์ 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 เท่านั้น

  1. ตั้งค่า CONFIG_DM_VERITY_AVB=n ในเคอร์เนล
  2. กำหนดค่าอุปกรณ์ให้ใช้โหมด 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)