Triển khai A/B ảo – bản vá

Hãy chọn các bản vá sau đây để giải quyết các vấn đề đã biết sau.

Kiểm tra chính xác dung lượng có thể phân bổ khi tải không qua cửa hàng

Việc tải gói OTA đầy đủ không qua cửa hàng ứng dụng trên một thiết bị A/B ảo có phân vùng siêu cấp có kích thước nhỏ hơn *2 * sum(size of update groups)* có thể không thành công với thông tin sau trong nhật ký khôi phục /tmp/recovery.log:

The maximum size of all groups with suffix _b (...) has exceeded half of allocatable space for dynamic partitions ...

Dưới đây là ví dụ về nhật ký:

[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.

Nếu bạn gặp vấn đề này, hãy chọn CL 1399393, tạo lại và cài đặt ROM cho phân vùng khởi động hoặc phân vùng khôi phục nếu thiết bị không sử dụng chế độ khôi phục làm chế độ khởi động.

Sửa lỗi phân đoạn trong quá trình hợp nhất

Sau khi áp dụng bản cập nhật OTA, trong quá trình hợp nhất VAB, lệnh gọi đến update_engine_client --cancel sẽ khiến CleanupPreviousUpdateAction gặp sự cố. Lỗi con trỏ ngẫu nhiên cũng có thể xảy ra khi markSlotSuccessful đến muộn.

Vấn đề này đã được giải quyết bằng cách thêm hàm StopActionInternal. CleanupPreviousUpdateAction huỷ các tác vụ đang chờ xử lý khi huỷ. Phương thức này duy trì một biến theo dõi mã nhận dạng tác vụ của tác vụ đang chờ xử lý trong vòng lặp thông báo. Khi huỷ, tác vụ đang chờ xử lý sẽ bị huỷ để tránh segfault.

Đảm bảo các thay đổi sau đây có trong cây nguồn Android 11 để khắc phục sự cố SIGSEGV trong update_engine trong quá trình hợp nhất:

  • CL 1439792 (điều kiện tiên quyết cho CL 1439372)
  • CL 1439372 (CleanupPreviousUpdateAction: huỷ các tác vụ đang chờ xử lý khi huỷ)
  • CL 1663460 (sửa lỗi con trỏ hoang dã tiềm ẩn khi markSlotSuccessful đến muộn)

Ngăn việc hợp nhất sớm update_engine

Khi một thiết bị khởi động (Android 11 trở lên) và quá trình khởi động hoàn tất, update_engine sẽ gọi ScheduleWaitMarkBootSuccessful() và WaitForMergeOrSchedule(). Thao tác này sẽ bắt đầu quá trình hợp nhất. Tuy nhiên, thiết bị sẽ khởi động lại ở khe cắm cũ. Vì quá trình hợp nhất đã bắt đầu, nên thiết bị không khởi động được và không hoạt động được.

Thêm các thay đổi sau vào cây nguồn. Xin lưu ý rằng CL 1664859 là không bắt buộc.

  • CL 1439792 (điều kiện tiên quyết cho CL 1439372)
  • CL 1439372 (CleanupPreviousUpdateAction: huỷ các tác vụ đang chờ xử lý khi huỷ)
  • CL 1663460 (khắc phục lỗi con trỏ ký tự đại diện có thể xảy ra khi markSlotSuccessful đến trễ)
  • CL 1664859 (không bắt buộc – thêm unittest cho CleanupPreviousUpdateAction)

Đảm bảo cấu hình dm-verity chính xác

Trong Android 11 trở lên, các thiết bị có thể vô tình được định cấu hình bằng các tuỳ chọn dm-verity sau:

  • CONFIG_DM_VERITY_AVB=y trong nhân
  • Trình tải khởi động được định cấu hình để sử dụng bất kỳ chế độ xác thực nào (chẳng hạn như AVB_HASHTREE_ERROR_MODE_RESTART_AND_INVALIDATE) mà không cần AVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIO.

Với cấu hình thiết bị này, mọi lỗi xác thực đều khiến phân vùng vbmeta bị hỏng và khiến các thiết bị không phải A/B không hoạt động được. Tương tự, nếu quá trình hợp nhất đã bắt đầu, các thiết bị A/B cũng có thể không hoạt động được. Chỉ sử dụng chế độ xác thực AVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIO.

  1. Đặt CONFIG_DM_VERITY_AVB=n trong hạt nhân.
  2. Thay vào đó, hãy định cấu hình thiết bị để sử dụng chế độ AVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIO.

Để biết thêm thông tin, hãy tham khảo tài liệu về tính năng xác thực: Xử lý lỗi dm-verity.

Xác nhận tệp đã hợp nhất được định cấu hình chính xác

Nếu bạn đang tạo riêng hình ảnh hệ thống và hình ảnh của nhà cung cấp, hãy sử dụng merge_target_files để hợp nhất các hình ảnh đó, cấu hình A/B ảo có thể bị bỏ nhầm trong quá trình hợp nhất. Để xác minh rằng cấu hình A/B ảo là chính xác trong tệp mục tiêu đã hợp nhất, hãy áp dụng các bản vá sau: CL 2084183 (hợp nhất các cặp khoá/val giống nhau trong thông tin phân vùng động)

Cập nhật thành phần cần thiết

Kể từ Android 13, snapuserd đã được chuyển từ ổ đĩa ram của nhà cung cấp sang ổ đĩa RAM chung. Nếu thiết bị của bạn đang nâng cấp lên Android 13, thì cả ramdisk của nhà cung cấp và ramdisk chung đều chứa một bản sao của snapuserd. Trong trường hợp này, Virtual A/B yêu cầu bản sao hệ thống của snapuserd. Để đảm bảo rằng bạn đã có bản sao chính xác của snapuserd, hãy áp dụng CL 2031243 (sao chép snapuserd vào first_stage_ramdisk).