Bố cục phân vùng

Trên Android 10, hệ thống tệp gốc không còn được bao gồm trong ramdisk.img và thay vào đó được hợp nhất vào system.img (nghĩa là system.img luôn được tạo dưới dạng nếu bạn đã đặt BOARD_BUILD_SYSTEM_ROOT_IMAGE). Thiết bị ra mắt cùng Android 10:

• Sử dụng bố cục phân vùng hệ thống làm gốc (tự động được thực thi bằng không có tuỳ chọn để thay đổi hành vi).
• Phải sử dụng ổ đĩa ramdisk, bắt buộc phải có cho dm-tuyến tính.
• Phải đặt BOARD_BUILD_SYSTEM_ROOT_IMAGE thành false. Chế độ cài đặt này chỉ dùng để phân biệt các thiết bị dùng ổ đĩa RAM và các thiết bị không sử dụng ổ đĩa RAM (mà thay vào đó gắn kết system.img).

Ý nghĩa của cấu hình hệ thống dưới dạng gốc khác nhau giữa Android 9 và Android 10. Trong hệ thống Android 9 ở dạng gốc cấu hình, BOARD_BUILD_SYSTEM_ROOT_IMAGE được đặt thành true buộc bản dựng hợp nhất hệ thống tệp gốc vào system.img sau đó gắn system.img làm tệp gốc hệ thống (rootfs). Cấu hình này là bắt buộc đối với các thiết bị khởi chạy cùng với Android 9 nhưng không bắt buộc đối với các thiết bị nâng cấp lên Android 9 và dành cho các thiết bị chạy các phiên bản Android thấp hơn. Trên Android 10 cấu hình hệ thống dưới dạng gốc, bản dựng sẽ luôn hợp nhất $TARGET_SYSTEM_OUT và $TARGET_ROOT_OUT thành system.img; cấu hình này là chế độ mặc định cho tất cả thiết bị chạy Android 10.

Android 10 bổ sung các thay đổi về khả năng hỗ trợ phân vùng động, một hệ thống phân vùng không gian người dùng cho phép cập nhật qua mạng không dây (OTA) tạo, đổi kích thước hoặc huỷ phân vùng. Trong lần thay đổi này, Linux nhân hệ điều hành không thể gắn phân vùng hệ thống logic trên các thiết bị đang chạy nữa Android 10, vì vậy thao tác này được xử lý bằng khởi tạo giai đoạn.

Các phần sau đây mô tả các yêu cầu về hệ thống dưới dạng thư mục gốc cho OTA chỉ có hệ thống, cung cấp hướng dẫn về cách cập nhật các thiết bị để sử dụng chế độ hệ thống làm thư mục gốc (bao gồm cả việc thay đổi bố cục phân vùng và yêu cầu về hạt nhân dm-verity). Cho chi tiết về những thay đổi đối với ramdisk, xem Ramdisk Vách ngăn.

Giới thiệu về OTA chỉ dành cho hệ thống

OTA chỉ dành cho hệ thống, cho phép các bản phát hành Android cập nhật system.img và product.img mà không thay đổi yêu cầu bố cục phân vùng hệ thống làm gốc. Tất cả thiết bị chạy Android 10 phải sử dụng bố cục phân vùng hệ thống làm gốc để bật OTA chỉ dành cho hệ thống.

• Thiết bị A/B gắn phân vùng system dưới dạng rootfs, đã sử dụng hệ thống dưới dạng thư mục gốc và không yêu cầu thay đổi để hỗ trợ OTA của hệ thống.
• Các thiết bị không phải A/B, gắn phân vùng system tại /system phải được cập nhật để sử dụng bố cục phân vùng hệ thống dưới dạng gốc để hỗ trợ các OTA của hệ thống.

Để biết thông tin chi tiết về thiết bị A/B và thiết bị không phải A/B, hãy tham khảo Cập nhật hệ thống A/B (Seamless).

Sử dụng lớp phủ của nhà cung cấp (<=AOSP 14)

Lớp phủ nhà cung cấp cho phép bạn phủ các thay đổi đối với vendor phân vùng tại thời điểm khởi động thiết bị. Lớp phủ nhà cung cấp là một tập hợp các mô-đun nhà cung cấp trong phân vùng product bị phủ lên vendor phân vùng khi thiết bị khởi động, thay thế và thêm vào các mô-đun hiện có.

Khi thiết bị khởi động, quá trình init sẽ hoàn tất quá trình đầu tiên chế độ kết nối giai đoạn và đọc các thuộc tính mặc định. Sau đó, Google Tìm kiếm /product/vendor_overlay/<target_vendor_version> và các giá đỡ mỗi thư mục con trên thư mục phân vùng vendor tương ứng, nếu các điều kiện sau được đáp ứng:

• /vendor/<overlay_dir> đã tồn tại.
• /product/vendor_overlay/<target_vendor_version>/<overlay_dir> có cùng ngữ cảnh tệp với /vendor/<overlay_dir>.
• init được phép gắn kết trên ngữ cảnh tệp của /vendor/<overlay_dir>.

Triển khai lớp phủ nhà cung cấp

Cài đặt các tệp lớp phủ của nhà cung cấp trong /product/vendor_overlay/<target_vendor_version>. Các tệp đó phủ phân vùng vendor khi thiết bị khởi động, thay thế các tệp có cùng tên và thêm bất kỳ tệp mới nào. Lớp phủ nhà cung cấp không thể xoá tệp từ phân vùng vendor.

Tệp lớp phủ nhà cung cấp phải có cùng ngữ cảnh tệp với tệp đích chúng thay thế trong phân vùng vendor. Theo mặc định, các tệp trong Thư mục /product/vendor_overlay/<target_vendor_version> có ngữ cảnh vendor_file. Nếu ngữ cảnh tệp không khớp giữa tệp lớp phủ của nhà cung cấp và tệp mà họ thay thế, hãy chỉ định rằng trong sepolicy dành riêng cho thiết bị. Ngữ cảnh tệp được đặt ở cấp thư mục. Nếu ngữ cảnh tệp của thư mục lớp phủ nhà cung cấp không khớp với thư mục đích, và ngữ cảnh tệp chính xác không được chỉ định trong sepolicy dành riêng cho thiết bị, thư mục lớp phủ nhà cung cấp đó không được phủ lên thư mục đích.

Để sử dụng lớp phủ nhà cung cấp, nhân hệ điều hành phải bật OverlayFS bằng cách đặt CONFIG_OVERLAY_FS=y. Ngoài ra, nhân phải được hợp nhất từ nhân hệ điều hành phổ biến 4.4 trở lên hoặc được vá bằng "overlayfs: override_creds=off option bypass creator_cred".

Ví dụ về cách triển khai lớp phủ nhà cung cấp

Quy trình này minh hoạ việc triển khai một lớp phủ nhà cung cấp phủ lên các thư mục /vendor/lib/*, /vendor/etc/* và /vendor/app/*.

1. Thêm tệp tạo sẵn của nhà cung cấp trong device/<vendor>/<target>/vendor_overlay/<target_vendor_version>/:

   device/google/device/vendor_overlay/28/lib/libfoo.so
   device/google/device/vendor_overlay/28/lib/libbar.so
   device/google/device/vendor_overlay/28/etc/baz.xml
   device/google/device/vendor_overlay/28/app/qux.apk
   

2. Cài đặt các tệp tạo sẵn của nhà cung cấp vào product/vendor_overlay inch device/google/device/device.mk:

   PRODUCT_COPY_FILES += \
       $(call find-copy-subdir-files,*,device/google/device/vendor_overlay,$(TARGET_COPY_OUT_PRODUCT)/vendor_overlay)
   

3. Xác định ngữ cảnh tệp nếu tệp phân vùng vendor mục tiêu có ngữ cảnh khác vendor_file. Bởi vì /vendor/lib/* sử dụng ngữ cảnh vendor_file, điều này không bao gồm thư mục đó.

   Thêm đoạn mã sau vào device/google/device-sepolicy/private/file_contexts:

   /(product|system/product)/vendor_overlay/[0-9]+/etc(/.*)?   u:object_r:vendor_configs_file:s0
   /(product|system/product)/vendor_overlay/[0-9]+/app(/.*)?   u:object_r:vendor_app_file:s0
   

4. Cho phép quy trình init gắn lớp phủ của nhà cung cấp trên tệp các ngữ cảnh khác ngoài vendor_file. Vì init quy trình đã có quyền gắn kết trên ngữ cảnh vendor_file, ví dụ này không xác định chính sách cho vendor_file.

   Thêm đoạn mã sau vào device/google/device-sepolicy/public/init.te:

   allow init vendor_configs_file:dir mounton;
   allow init vendor_app_file:dir mounton;
   

Xác thực lớp phủ của nhà cung cấp

Để xác thực cấu hình lớp phủ của nhà cung cấp, hãy thêm tệp vào /product/vendor_overlay/<target_vendor_version>/<overlay_dir> và kiểm tra xem các tệp có phủ lên trên các tệp trong /vendor/<overlay_dir>.

Đối với các bản dựng userdebug, có một mô-đun kiểm thử cho Atest:

$ atest -v fs_mgr_vendor_overlay_test

Cập nhật lên hệ thống dưới dạng thư mục gốc

Để cập nhật các thiết bị không phải A/B để sử dụng hệ thống dưới dạng gốc, bạn phải cập nhật lược đồ phân vùng cho boot.img và system.img, đặt tăng dm-verity và xoá mọi phần phụ thuộc khởi động trên thư mục gốc dành riêng cho thiết bị .

Cập nhật phân vùng

Không giống như các thiết bị A/B sử dụng lại /boot làm phân vùng khôi phục, Các thiết bị không thuộc A/B phải giữ lại phân vùng /recovery riêng biệt vì chúng không có phân vùng vị trí dự phòng (ví dụ: từ boot_a đến boot_b). Nếu /recovery là đã bị loại bỏ trên thiết bị không phải A/B và được thiết lập tương tự như lược đồ A/B, chế độ khôi phục có thể bị lỗi trong lần cập nhật phân vùng /boot không thành công. Cho lý do này, phân vùng /recovery phải là phân vùng riêng biệt khỏi /boot cho các thiết bị không phải A/B, tức là hình ảnh khôi phục tiếp tục được cập nhật theo cách trì hoãn (tức là tương tự như trên các thiết bị chạy Android 8.1.0 trở xuống).

Bảng sau đây liệt kê sự khác biệt về phân vùng hình ảnh đối với các thiết bị không phải A/B trước và sau Android 9.

Hình ảnh	Ramdisk (trước 9)	Hệ thống dưới dạng gốc (sau 9)
boot.img	Chứa một nhân và một ramdisk.img: ramdisk.img -/ - init.rc - init - etc -> /system/etc - system/ (mount point) - vendor/ (mount point) - odm/ (mount point) ...	Chỉ chứa một nhân khởi động thông thường.
recovery.img	Chứa nhân hệ điều hành khôi phục và tính năng khôi phục ramdisk.img.
system.img	Chứa những thành phần sau: system.img -/ - bin/ - etc - vendor -> /vendor - ...	Chứa nội dung hợp nhất của system.img gốc và ramdisk.img: system.img -/ - init.rc - init - etc -> /system/etc - system/ - bin/ - etc/ - vendor -> /vendor - ... - vendor/ (mount point) - odm/ (mount point) ...

Bản thân các phân vùng không thay đổi; sử dụng cả ổ đĩa RAM và hệ thống dưới dạng thư mục gốc lược đồ phân vùng sau:

• /boot
• /system
• /system
• /recovery
• /vendor, v.v.

Thiết lập dm-verity

Trong hệ thống dưới dạng gốc, nhân phải gắn system.img trong / (điểm gắn) với dm-verity. AOSP hỗ trợ dm-verity sau cho system.img.

vboot 1.0

Đối với vboot 1.0, nhân phải phân tích cú pháp Dành riêng cho Android siêu dữ liệu trên /system, sau đó chuyển đổi thành các tham số dm-verity để thiết lập dm-verity (cần có các bản vá nhân hệ điều hành này). Ví dụ sau đây cho thấy các chế độ cài đặt liên quan đến dm-verity cho system-as-root trong dòng lệnh kernel:

ro root=/dev/dm-0 rootwait skip_initramfs init=/init
dm="system none ro,0 1 android-verity /dev/sda34"
veritykeyid=id:7e4333f9bba00adfe0ede979e28ed1920492b40f

vboot 2.0

Đối với vboot 2.0 (AVB), trình tải khởi động phải tích hợp external/avb/libavb, sau đó phân tích cú pháp bộ mô tả cây băm cho /system, chuyển đổi CANNOT TRANSLATE dm-verity params và cuối cùng chuyển các tham số đến nhân hệ điều hành thông qua dòng lệnh kernel. (Phần mô tả Hashatree của /system có thể có trên /vbmeta hoặc trên chính /system.)

vboot 2.0 yêu cầu các bản vá nhân hệ điều hành sau:

• https://android-review.googlesource.com/#/c/kernel/common/+/158491/
• bản vá nhân hệ điều hành 4.4, bản vá nhân hệ điều hành 4.9, v.v.

Lưu ý: Các tệp bản vá nhân hệ điều hành dành riêng cho AVB là cũng có trên external/avb/contrib/linux/.

Ví dụ sau đây cho thấy các chế độ cài đặt liên quan đến dm-verity cho system-as-root trong dòng lệnh kernel:

ro root=/dev/dm-0 rootwait  skip_initramfs init=/init

dm="1 vroot none ro 1,0 5159992 verity 1
PARTUUID=00000016-0000-0000-0000-000000000000
PARTUUID=00000016-0000-0000-0000-000000000000 4096 4096 644999 644999
sha1 d80b4a8be3b58a8ab86fad1b498640892d4843a2
8d08feed2f55c418fb63447fec0d32b1b107e42c 10 restart_on_corruption
ignore_zero_blocks use_fec_from_device
PARTUUID=00000016-0000-0000-0000-000000000000 fec_roots 2 fec_blocks
650080 fec_start 650080"

Sử dụng thư mục gốc dành riêng cho thiết bị

Với system-as-root, sau hình ảnh hệ thống chung (GSI) được cài đặt ROM trên thiết bị (và trước khi chạy các bài kiểm thử Bộ thử nghiệm dành cho nhà cung cấp), bất kỳ thư mục gốc dành riêng cho thiết bị được thêm bằng BOARD_ROOT_EXTRA_FOLDERS đã biến mất vì toàn bộ nội dung trong thư mục gốc đã được thay thế bằng GSI hệ thống ở dạng gốc. Việc xoá các thư mục này có thể khiến thiết bị không thể khởi động nếu tồn tại một phần phụ thuộc trong thư mục gốc dành riêng cho thiết bị (ví dụ: chúng được dùng làm điểm gắn).

Để tránh sự cố này, không sử dụng BOARD_ROOT_EXTRA_FOLDERS để thêm thư mục gốc dành riêng cho thiết bị. Nếu bạn cần chỉ định giá đỡ dành riêng cho thiết bị điểm, hãy sử dụng /mnt/vendor/<mount point> (được thêm vào danh sách thay đổi). Các điểm gắn dành riêng cho nhà cung cấp này có thể được chỉ định trực tiếp trong cả hai cây thiết bị fstab (đối với giai đoạn đầu tiên gắn kết) và tệp /vendor/etc/fstab.{ro.hardware} không có thiết lập bổ sung (khi fs_mgr tạo chúng trong /mnt/vendor/*).