Triển khai tính năng 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

Cài đặt gói OTA đầy đủ không qua cửa hàng ứng dụng trên thiết bị A/B ảo có siêu dữ liệu phân vùng có kích thước nhỏ hơn *2 * sum(kích thước của nhóm cập nhật)* có thể không thành công bằng 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à một 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ố. Đáp lỗi con trỏ tự nhiên 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. Bật 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 nhiệm vụ đang chờ xử lý khi huỷ)
  • CL 1663460 (khắc phục lỗi con trỏ tự nhiên có thể xảy ra khi markSlotSuccessful đến muộn)

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

Khi thiết bị khởi động (Android 11 trở lên) và quá trình khởi động hoàn tất, update_engine 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ị khởi động lại khe cũ. Vì quá trình hợp nhất đã bắt đầu nên thiết bị không thể khởi động 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 nhiệm vụ đang chờ xử lý khi huỷ)
  • CL 1663460 (khắc phục lỗi con trỏ tự nhiên có thể xảy ra khi markSlotSuccessful đến muộn)
  • 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

Trên Android 11 trở lên, người dùng có thể vô tình định cấu hình các thiết bị 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 hợp nhất đã bắt đầu, thì 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 nhân.
  2. Đị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 xác thực: Xử lý độ phân giải Lỗi.

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, thì việc sử dụng merge_target_files để hợp nhất chúng, cấu hình A/B ảo có thể là bị thả không chính xác trong quá trình hợp nhất. Để xác minh A/B ảo cấu hình đã chính xác trong tệp đích hợp nhất, hãy áp dụng các cấu hình sau bản vá: 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 chung ổ đĩa RAM. Nếu thiết bị của bạn đang nâng cấp lên Android 13, thì có 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 đã đặt đúng bản sao của snapuserd, hãy áp dụng CL 2031243 (sao chép snapuserd vào first_stage_ramdisk).