Triển khai tính năng A/B ảo – bản vá

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

Kiểm tra chính xác dung lượng có thể phân bổ khi cài đặt qua phương thức tải lên trực tiếp

Việc cài đặt một gói OTA đầy đủ trên một thiết bị A/B ảo có một phân vùng siêu dữ liệu với kích thước nhỏ hơn *2 * sum(size of update groups) có thể không thành công với nội dung 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 ...

Sau đâ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 phải vấn đề này, hãy chọn CL 1399393, tạo lại và flash 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.

Khắc phục 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, một lệnh gọi đến update_engine_client --cancel sẽ khiến CleanupPreviousUpdateAction gặp sự cố. Cũng có thể xảy ra lỗi con trỏ không xác định 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ỷ. Nó duy trì một biến theo dõi mã nhận dạng 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 lỗi phân đoạn.

Đảm bảo các thay đổi sau đây nằm 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: cancel pending tasks on destroy)
  • CL 1663460 (khắc phục lỗi con trỏ không xác định tiềm ẩn khi markSlotSuccessful xuất hiệ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 quy trình hợp nhất. Tuy nhiên, thiết bị sẽ khởi động lại vào 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.

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

  • CL 1439792 (điều kiện tiên quyết cho CL 1439372)
  • CL 1439372 (CleanupPreviousUpdateAction: cancel pending tasks on destroy)
  • CL 1663460 (khắc phục lỗi con trỏ không xác định tiềm ẩn khi markSlotSuccessful xuất hiệ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

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 lựa chọn dm-verity sau đây:

  • CONFIG_DM_VERITY_AVB=y trong kernel
  • Trình tải khởi động được định cấu hình để sử dụng mọi chế độ xác minh (chẳng hạn như AVB_HASHTREE_ERROR_MODE_RESTART_AND_INVALIDATE), không có AVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIO.

Với cấu hình thiết bị này, mọi lỗi về tính 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, thì các thiết bị A/B cũng có thể không hoạt động. Chỉ sử dụng chế độ xác minh 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ề verity: Xử lý lỗi dm-verity.

Xác nhận rằng 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 biệt các hình ảnh hệ thống và hình ảnh nhà cung cấp, sau đó sử dụng merge_target_files để hợp nhất chúng, thì các cấu hình A/B ảo có thể bị loại bỏ không chính xác trong quá trình hợp nhất. Để xác minh rằng các cấu hình A/B ảo là chính xác trong tệp đích đã 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á/giá trị giống hệt nhau trong thông tin phân vùng động)

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

Kể từ Android 13, snapuserd đã được di chuyển từ ramdisk của nhà cung cấp sang ramdisk chung. 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, A/B ảo yêu cầu bản sao hệ thống của snapuserd. Để đảm bảo rằng bản sao chính xác của snapuserd được đặt đúng vị trí, hãy áp dụng CL 2031243 (sao chép snapuserd vào first_stage_ramdisk).