Triển khai A/B ảo - các 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 không gian có thể phân bổ chính xác khi tải bên

Việc tải một gói OTA đầy đủ trên thiết bị A/B ảo có siêu phân vùng có kích thước nhỏ hơn *2 * sum(kích thước của các nhóm cập nhật)* 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 ...

Đâ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 phải sự cố này, hãy chọn CL 1399393 , xây dựng 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 recovery làm 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 tới update_engine_client --cancel khiến CleanupPreviousUpdateAction gặp sự cố. Lỗi con trỏ hoang dã tiềm ẩn cũng tồn tại khi markSlotSuccessful xuất hiện muộn.

Vấn đề này đã được giải quyết bằng cách thêm hàm StopActionInternal . CleanupPreviousUpdateAction hủy các tác vụ đang chờ xử lý khi hủy. Nó duy trì một biến theo dõi ID tác vụ của tác vụ đang chờ xử lý trong vòng lặp tin nhắn. Khi hủy, tác vụ đang chờ xử lý sẽ bị hủy để tránh lỗi phân tách.

Đảm bảo có những thay đổi sau trong cây nguồn Android 11 của bạn để 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 của CL 1439372)
  • CL 1439372 ( CleanupPreviousUpdateAction : hủy các tác vụ đang chờ xử lý khi hủy)
  • CL 1663460 (sửa lỗi con trỏ hoang dã tiềm ẩn khi markSlotSuccessful đến muộn)

Sửa lỗi chuyển đổi khe VAB không chính xác, đăng cập nhật OTA

Trong Android 11 trở lên, việc không đồng bộ hóa công tắc khe cắm trong thiết bị sau khi cập nhật OTA có thể khiến thiết bị rơi vào trạng thái không sử dụng được. Nếu quá trình triển khai chuyển đổi vị trí của IBootControl HAL của bạn thực hiện ghi, bạn phải xóa các lần ghi đó ngay lập tức. Nếu quá trình ghi không được xóa và thiết bị khởi động lại sau khi quá trình hợp nhất bắt đầu, nhưng trước khi phần cứng có thể xóa quá trình ghi chuyển đổi vị trí, thiết bị có thể trở lại vị trí trước đó và không khởi động được.

Để biết giải pháp mã mẫu, hãy xem CL: CL 1535570 này.

Ngăn chặ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()WaitForMergeOrSchedule() . Điều này bắt đầu quá trình hợp nhất. Tuy nhiên, thiết bị 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 thể hoạt động được.

Thêm những thay đổi sau vào cây nguồn của bạn. Lưu ý rằng CL 1664859 là tùy chọn.

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

Ngăn chặn mất mát hoặc hỏng dữ liệu do siêu dữ liệu bị bỏ qua

Trong Android 11 trở lên, nếu thiết bị lưu trữ có bộ nhớ đệm ghi lại không ổn định thì trong một số điều kiện nhất định, siêu dữ liệu của quá trình hợp nhất đã hoàn tất sẽ bị bỏ qua, dẫn đến mất hoặc hỏng dữ liệu.

Điều kiện:

  1. Sau khi hoàn tất thao tác hợp nhất một nhóm ngoại lệ, merge_callback() đã được gọi.
  2. Siêu dữ liệu đã được cập nhật trong thiết bị COW theo dõi quá trình hoàn tất hợp nhất. (Bản cập nhật này cho thiết bị COW đã được xóa sạch.)

Kết quả: Hệ thống gặp sự cố do bộ đệm của thiết bị lưu trữ của quá trình hợp nhất gần đây không bị xóa.

Xem phần sau để triển khai giải pháp:

Đả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 tùy chọn dm-verity sau:

  • CONFIG_DM_VERITY_AVB=y trong hạt nhân
  • Bộ 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 ), không có AVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIO .

Với cấu hình thiết bị này, bất kỳ lỗi xác thực nào đề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 thể hoạt động. 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 kernel
  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 và thực tế, hãy tham khảo tài liệu xác thực: Xử lý lỗi dm-verity .

Bỏ qua công việc xác thực để xử lý lỗi I/O trong quá trình tắt hệ thống khẩn cấp

Trong Android 11 trở lên, nếu lệnh tắt hệ thống khẩn cấp được gọi (như trong trường hợp tắt máy do nhiệt), thiết bị dm có thể vẫn hoạt động trong khi thiết bị khối không thể xử lý các yêu cầu I/O nữa. Ở trạng thái này, các lỗi I/O được xử lý bởi các yêu cầu I/O dm mới hoặc bởi những yêu cầu đang thực hiện, có thể dẫn đến trạng thái sai lệch thực sự, đây là một phán đoán sai lầm.

Để bỏ qua công việc xác thực nhằm xử lý lỗi I/O khi hệ thống tắt, hãy sử dụng cách sau:

CL 1847875 (Bỏ qua công việc xác thực để phản hồi lỗi I/O trong khi tắt máy)

Đảm bảo tắt DM_ANDROID_VERITY_AT_MOST_ONCE_DEFAULT_ENABLED

Các thiết bị Android Go chạy kernel 4.19 trở về trước có thể có DM_ANDROID_VERITY_AT_MOST_ONCE_DEFAULT_ENABLED=y trong cấu hình kernel của chúng. Cài đặt này không tương thích với A/B ảo và được biết là gây ra sự cố hỏng trang hiếm gặp khi cả hai được bật cùng nhau.

Đối với hạt nhân 4.19 trở về trước, hãy tắt nó bằng cách đặt CONFIG_DM_ANDROID_VERITY_AT_MOST_ONCE_DEFAULT_ENABLED=n trong cấu hình hạt nhân.

Đối với hạt nhân 5.4 trở lên, mã đã bị xóa và tùy chọn cấu hình không khả dụng.

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 xây dựng hình ảnh hệ thống và hình ảnh nhà cung cấp một cách riêng biệt, sau đó sử dụng merge_target_files để hợp nhất chúng, 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ấu hình A/B ảo trong tệp mục tiêu đã hợp nhất là chính xác, hãy áp dụng các bản vá sau: CL 2084183 (hợp nhất các cặp khóa/val 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 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, có thể cả ramdisk của nhà cung cấp và ramdisk chung đều chứa 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 có đúng bản sao của snapuserd , hãy áp dụng CL 2031243 (sao chép snapuserd vào first_stage_ramdisk).