Triển khai cập nhật A/B

Các OEM và nhà cung cấp SoC muốn triển khai các bản cập nhật hệ thống A/B phải đảm bảo bộ tải khởi động của họ triển khai boot_control HAL và chuyển các tham số chính xác cho nhân.

Triển khai điều khiển khởi động HAL

Bộ tải khởi động có khả năng A/B phải triển khai boot_control HAL tại hardware/libhardware/include/hardware/boot_control.h . Bạn có thể kiểm tra việc triển khai bằng tiện ích system/extras/bootctl và system/extras/tests/bootloader/ .

Bạn cũng phải triển khai máy trạng thái được hiển thị bên dưới:

Thiết lập hạt nhân

Để triển khai cập nhật hệ thống A/B:

1. Cherrypick loạt bản vá kernel sau (nếu cần):
   • Nếu khởi động mà không có ramdisk và sử dụng "boot as recovery", hãy chọn android-review.googlesource.com/#/c/158491/ .
   • Để thiết lập dm-verity không có ramdisk, cherrypick android-review.googlesource.com/#/q/status:merged+project:kernel/common+branch:android-3.18+topic:A_B_Changes_3.18 .
2. Đảm bảo các đối số dòng lệnh nhân chứa các đối số bổ sung sau:

   skip_initramfs rootwait ro init=/init root="/dev/dm-0 dm=system none ro,0 1 android-verity <public-key-id> <path-to-system-partition>"

   ... trong đó giá trị <public-key-id> là ID của khóa chung được sử dụng để xác minh chữ ký bảng xác thực (để biết chi tiết, xem dm-verity ).
3. Thêm chứng chỉ .X509 chứa khóa chung vào khóa hệ thống:
   1. Sao chép chứng chỉ .X509 được định dạng ở định dạng .der vào thư mục gốc của thư mục kernel . Nếu chứng chỉ .X509 được định dạng dưới dạng tệp .pem , hãy sử dụng lệnh openssl sau để chuyển đổi từ định dạng .pem sang .der :

      openssl x509 -in <x509-pem-certificate> -outform der -out <x509-der-certificate>

   2. Xây dựng zImage để bao gồm chứng chỉ như một phần của khóa hệ thống. Để xác minh, hãy kiểm tra mục nhập procfs (yêu cầu phải bật KEYS_CONFIG_DEBUG_PROC_KEYS ):

      angler:/# cat /proc/keys
      
      1c8a217e I------     1 perm 1f010000     0     0 asymmetri
      Android: 7e4333f9bba00adfe0ede979e28ed1920492b40f: X509.RSA 0492b40f []
      2d454e3e I------     1 perm 1f030000     0     0 keyring
      .system_keyring: 1/4

      Việc đưa chứng chỉ .X509 vào thành công cho biết sự hiện diện của khóa chung trong chuỗi khóa hệ thống (điểm nổi bật biểu thị ID khóa chung).
   3. Thay thế khoảng trắng bằng # và chuyển nó dưới dạng <public-key-id> trong dòng lệnh kernel. Ví dụ: chuyển Android:#7e4333f9bba00adfe0ede979e28ed1920492b40f thay cho <public-key-id> .

Đặt biến xây dựng

Bộ tải khởi động có khả năng A/B phải đáp ứng các tiêu chí biến bản dựng sau:

Đặt phân vùng (khe)

Các thiết bị A/B không cần phân vùng khôi phục hoặc phân vùng bộ đệm vì Android không còn sử dụng các phân vùng này nữa. Phân vùng dữ liệu hiện được sử dụng cho gói OTA đã tải xuống và mã hình ảnh khôi phục nằm trên phân vùng khởi động. Tất cả các phân vùng là A/B-ed phải được đặt tên như sau (các vị trí luôn được đặt tên là a , b , v.v.): boot_a , boot_b , system_a , system_b , vendor_a , vendor_b .

Bộ nhớ cache

Đối với các bản cập nhật không phải A/B, phân vùng bộ đệm được sử dụng để lưu trữ các gói OTA đã tải xuống và tạm thời lưu trữ các khối trong khi áp dụng các bản cập nhật. Không bao giờ có cách tốt để định kích thước phân vùng bộ đệm: dung lượng cần thiết phụ thuộc vào bản cập nhật bạn muốn áp dụng. Trường hợp xấu nhất sẽ là một phân vùng bộ đệm lớn bằng hình ảnh hệ thống. Với các bản cập nhật A/B, bạn không cần phải lưu trữ các khối (vì bạn luôn ghi vào một phân vùng hiện không được sử dụng) và với tính năng phát trực tuyến A/B, bạn không cần phải tải xuống toàn bộ gói OTA trước khi áp dụng.

Sự hồi phục

Đĩa RAM khôi phục hiện được chứa trong tệp boot.img . Khi vào recovery, bootloader không thể đặt tùy chọn skip_initramfs trên dòng lệnh kernel.

Đối với các bản cập nhật không phải A/B, phân vùng khôi phục chứa mã được sử dụng để áp dụng các bản cập nhật. Các bản cập nhật A/B được áp dụng bởi update_engine đang chạy trong hình ảnh hệ thống được khởi động thông thường. Vẫn có một chế độ khôi phục được sử dụng để thực hiện thiết lập lại dữ liệu ban đầu và tải các gói cập nhật (đó là nguồn gốc của tên "phục hồi"). Mã và dữ liệu cho chế độ khôi phục được lưu trữ trong phân vùng khởi động thông thường trong đĩa ram; để khởi động vào ảnh hệ thống, bộ nạp khởi động yêu cầu hạt nhân bỏ qua đĩa ram (nếu không, thiết bị sẽ khởi động vào chế độ khôi phục. Chế độ khôi phục nhỏ (và phần lớn đã có trên phân vùng khởi động), vì vậy phân vùng khởi động không tăng kích thước.

Fstab

Đối số slotselect phải nằm trên dòng cho các phân vùng A/B-ed. Ví dụ:

<path-to-block-device>/vendor  /vendor  ext4  ro
wait,verify=<path-to-block-device>/metadata,slotselect

Không có phân vùng nào được đặt tên là vendor . Thay vào đó, phân vùng vendor_a hoặc vendor_b sẽ được chọn và gắn vào điểm gắn kết /vendor .

Đối số vị trí hạt nhân

Hậu tố vị trí hiện tại phải được chuyển qua nút cây thiết bị (DT) cụ thể ( /firmware/android/slot_suffix ) hoặc thông qua dòng lệnh nhân androidboot.slot_suffix hoặc đối số bootconfig.

Theo mặc định, fastboot nhấp nháy vị trí hiện tại trên thiết bị A/B. Nếu gói cập nhật cũng chứa hình ảnh cho khe cắm khác, không phải là khe cắm hiện tại, fastboot cũng sẽ flash những hình ảnh đó. Các tùy chọn có sẵn bao gồm:

• --slot SLOT . Ghi đè hành vi mặc định và nhắc fastboot flash vị trí được chuyển vào dưới dạng đối số.
• --set-active [ SLOT ] . Đặt vị trí là hoạt động. Nếu không có đối số tùy chọn nào được chỉ định, thì vị trí hiện tại được đặt là hoạt động.
• fastboot --help . Nhận thông tin chi tiết về các lệnh.

Nếu bộ tải khởi động triển khai fastboot, nó sẽ hỗ trợ lệnh set_active <slot> để đặt vị trí hoạt động hiện tại thành vị trí nhất định (điều này cũng phải xóa cờ không thể khởi động cho vị trí đó và đặt lại số lần thử lại về giá trị mặc định). Bộ tải khởi động cũng phải hỗ trợ các biến sau:

• has-slot:<partition-base-name-without-suffix> . Trả về “có” nếu phân vùng đã cho hỗ trợ các vị trí, nếu không thì “không”.
• current-slot . Trả về hậu tố vị trí sẽ được khởi động từ lần tiếp theo.
• slot-count . Trả về một số nguyên đại diện cho số lượng vị trí có sẵn. Hiện tại, hai vị trí được hỗ trợ nên giá trị này là 2 .
• slot-successful:<slot-suffix> . Trả về "có" nếu vị trí nhất định đã được đánh dấu là khởi động thành công, nếu không thì trả về "không".
• slot-unbootable:<slot-suffix> . Trả về “có” nếu vị trí đã cho được đánh dấu là không thể khởi động, ngược lại là "không".
• slot-retry-count . Số lần thử lại còn lại để cố gắng khởi động vị trí nhất định.

Để xem tất cả các biến, hãy chạy fastboot getvar all .

Tạo các gói OTA

Các công cụ gói OTA tuân theo các lệnh giống như các lệnh dành cho thiết bị không phải A/B. Tệp target_files.zip phải được tạo bằng cách xác định các biến bản dựng cho mục tiêu A/B. Các công cụ gói OTA tự động xác định và tạo các gói ở định dạng dành cho trình cập nhật A/B.

Ví dụ:

• Để tạo OTA đầy đủ:

  ./build/make/tools/releasetools/ota_from_target_files \
      dist_output/tardis-target_files.zip \
      ota_update.zip
  

• Để tạo OTA gia tăng:

  ./build/make/tools/releasetools/ota_from_target_files \
      -i PREVIOUS-tardis-target_files.zip \
      dist_output/tardis-target_files.zip \
      incremental_ota_update.zip
  

Cấu hình phân vùng

update_engine có thể cập nhật bất kỳ cặp phân vùng A/B nào được xác định trong cùng một đĩa. Một cặp phân vùng có tiền tố chung (chẳng hạn như system hoặc boot ) và hậu tố trên mỗi khe cắm (chẳng hạn như _a ). Danh sách các phân vùng mà trình tạo tải trọng xác định một bản cập nhật được cấu hình bởi biến tạo AB_OTA_PARTITIONS .

Ví dụ: nếu một cặp phân vùng bootloader_a và booloader_b được bao gồm ( _a và _b là hậu tố của vị trí), bạn có thể cập nhật các phân vùng này bằng cách chỉ định thông tin sau trên cấu hình sản phẩm hoặc bo mạch:

AB_OTA_PARTITIONS := \
  boot \
  system \
  bootloader

Tất cả các phân vùng được cập nhật bởi update_engine không được sửa đổi bởi phần còn lại của hệ thống. Trong quá trình cập nhật gia tăng hoặc delta , dữ liệu nhị phân từ vị trí hiện tại được sử dụng để tạo dữ liệu trong vị trí mới. Bất kỳ sửa đổi nào cũng có thể khiến dữ liệu vị trí mới không xác minh được trong quá trình cập nhật và do đó cập nhật không thành công.

Định cấu hình sau khi cài đặt

Bạn có thể định cấu hình bước hậu cài đặt khác nhau cho từng phân vùng được cập nhật bằng cách sử dụng một tập hợp các cặp khóa-giá trị. Để chạy chương trình tại /system/usr/bin/postinst trong một hình ảnh mới, hãy chỉ định đường dẫn liên quan đến thư mục gốc của hệ thống tệp trong phân vùng hệ thống.

Ví dụ: usr/bin/postinst là system/usr/bin/postinst (nếu không sử dụng đĩa RAM). Ngoài ra, hãy chỉ định loại hệ thống tệp để chuyển đến lệnh gọi hệ thống mount(2) . Thêm phần sau vào tệp .mk của sản phẩm hoặc thiết bị (nếu có):

AB_OTA_POSTINSTALL_CONFIG += \
  RUN_POSTINSTALL_system=true \
  POSTINSTALL_PATH_system=usr/bin/postinst \
  FILESYSTEM_TYPE_system=ext4

Biên soạn

Các ứng dụng có thể được biên dịch trong nền trước khi khởi động lại với hình ảnh hệ thống mới. Để biên dịch các ứng dụng trong nền, hãy thêm phần sau vào cấu hình thiết bị của sản phẩm (trong device.mk của sản phẩm):

1. Bao gồm các thành phần gốc trong bản dựng để đảm bảo tập lệnh biên dịch và tệp nhị phân được biên dịch và đưa vào ảnh hệ thống.

     # A/B OTA dexopt package
     PRODUCT_PACKAGES += otapreopt_script
   

2. Kết nối tập lệnh biên dịch với update_engine để chạy như một bước sau khi cài đặt.

     # A/B OTA dexopt update_engine hookup
     AB_OTA_POSTINSTALL_CONFIG += \
       RUN_POSTINSTALL_system=true \
       POSTINSTALL_PATH_system=system/bin/otapreopt_script \
       FILESYSTEM_TYPE_system=ext4 \
       POSTINSTALL_OPTIONAL_system=true
   

Để được trợ giúp cài đặt các tệp được chọn trước trong phân vùng hệ thống thứ hai chưa sử dụng, hãy tham khảo Cài đặt khởi động lần đầu các tệp DEX_PREOPT .