Triển khai phân vùng động

Phân vùng động được triển khai bằng trình lập bản đồ thiết bị dm-tuyến tính trong nhân Linux. Phân vùng super chứa siêu dữ liệu liệt kê tên và dải ô của mỗi phân vùng động trong super. Trong giai đoạn đầu init, thao tác này siêu dữ liệu được phân tích cú pháp và xác thực, đồng thời tạo các thiết bị chặn ảo để đại diện cho từng phân vùng động.

Khi áp dụng OTA, các phân vùng động sẽ tự động được tạo, đổi kích thước hoặc xoá khi cần. Đối với thiết bị A/B, có hai bản sao của siêu dữ liệu và các thay đổi chỉ được áp dụng cho bản sao biểu thị vùng mục tiêu.

Vì phân vùng động được triển khai trong không gian người dùng, nên cần phải có các phân vùng theo trình tải khởi động không thể chuyển thành động. Ví dụ: boot, Trình tải khởi động đọc dtbo và vbmeta, và nên vẫn phải được coi là vách ngăn thực tế.

Mỗi phân vùng động có thể thuộc về một nhóm cập nhật. Các các nhóm sẽ giới hạn không gian tối đa mà các phân vùng trong nhóm đó có thể sử dụng. Ví dụ: system và vendor có thể thuộc về một nhóm giới hạn tổng kích thước là system và vendor.

Triển khai phân vùng động trên thiết bị mới

Phần này trình bày chi tiết cách triển khai phân vùng động trên các thiết bị mới khởi chạy cùng với Android 10 trở lên. Cần cập nhật thiết bị hiện có, hãy xem phần Nâng cấp Android thiết bị.

Thay đổi phân vùng

Đối với các thiết bị chạy Android 10, hãy tạo một phân vùng có tên là super. super phân vùng xử lý các khe A/B trong nội bộ, vì vậy thiết bị A/B không cần phân tách super_a và super_b. Tất cả phân vùng AOSP chỉ đọc mà trình tải khởi động không sử dụng phải động và phải được xoá khỏi Bảng phân vùng GUID (GPT). Phân vùng dành riêng cho nhà cung cấp không cần phải động và có thể được đặt trong GPT.

Lưu ý: Tránh đặt userdata hoặc bất kỳ nội dung nào khác phân vùng đọc-ghi vĩnh viễn bên trong super.

Để ước tính kích thước của super, hãy thêm kích thước của phân vùng đang bị xoá khỏi GPT. Đối với thiết bị A/B, phải bao gồm kích thước của cả hai vị trí. Hình 1 cho thấy một bảng phân vùng mẫu trước và sau khi chuyển đổi sang quảng cáo động phân vùng.

Hình 1. Bố cục bảng phân vùng thực mới khi chuyển đổi sang phân vùng động

Các phân vùng động được hỗ trợ là:

• Hệ thống
• Nhà cung cấp
• Sản phẩm
• Số máy lẻ hệ thống
• ODM

Đối với các thiết bị chạy Android 10, tuỳ chọn dòng lệnh kernel androidboot.super_partition phải để trống để lệnh sysprop ro.boot.super_partition là trống.

Căn chỉnh phân vùng

Mô-đun trình lập bản đồ thiết bị có thể hoạt động kém hiệu quả hơn nếu Phân vùng super không được căn chỉnh đúng cách. Chiến lược phát hành đĩa đơn Phân vùng super PHẢI được căn chỉnh với I/O tối thiểu kích thước yêu cầu do lớp khối xác định. Theo mặc định, hệ thống xây dựng của mình (thông qua lpmake, công cụ này sẽ tạo hình ảnh phân vùng super), giả định rằng căn chỉnh 1 MiB là đủ cho mọi phân vùng động. Tuy nhiên, nhà cung cấp phải đảm bảo phân vùng super được căn chỉnh đúng cách.

Bạn có thể xác định kích thước yêu cầu tối thiểu của thiết bị khối bằng cách đang kiểm tra sysfs. Ví dụ:

# ls -l /dev/block/by-name/super
lrwxrwxrwx 1 root root 16 1970-04-05 01:41 /dev/block/by-name/super -> /dev/block/sda17
# cat /sys/block/sda/queue/minimum_io_size
786432

Bạn có thể xác minh sự căn chỉnh của phân vùng super trong một theo cách tương tự:

# cat /sys/block/sda/sda17/alignment_offset

Độ lệch căn chỉnh PHẢI bằng 0.

Thay đổi cấu hình thiết bị

Để bật tính năng phân vùng động, hãy thêm cờ sau vào device.mk:

PRODUCT_USE_DYNAMIC_PARTITIONS := true

Thay đổi cấu hình bảng

Bạn cần đặt kích thước của phân vùng super:

BOARD_SUPER_PARTITION_SIZE := <size-in-bytes>

Trên thiết bị A/B, hệ thống xây dựng sẽ gửi lỗi nếu tổng kích thước hình ảnh phân vùng động chiếm hơn một nửa super kích thước phân vùng.

Bạn có thể định cấu hình danh sách phân vùng động như sau. Cho thiết bị sử dụng nhóm cập nhật, hãy liệt kê các nhóm trong Biến BOARD_SUPER_PARTITION_GROUPS. Tên từng nhóm sau đó có một BOARD_group_SIZE và biến BOARD_group_PARTITION_LIST. Đối với các thiết bị A/B, quy mô tối đa của một nhóm chỉ được bao gồm một vị trí, vì tên nhóm được cố định nội bộ.

Dưới đây là một thiết bị mẫu có thể đặt tất cả các phân vùng vào một nhóm có tên là example_dynamic_partitions:

BOARD_SUPER_PARTITION_GROUPS := example_dynamic_partitions
BOARD_EXAMPLE_DYNAMIC_PARTITIONS_SIZE := 6442450944
BOARD_EXAMPLE_DYNAMIC_PARTITIONS_PARTITION_LIST := system vendor product

Dưới đây là một thiết bị mẫu đặt các dịch vụ sản phẩm và hệ thống vào group_foo và vendor, product, và odm vào group_bar:

BOARD_SUPER_PARTITION_GROUPS := group_foo group_bar
BOARD_GROUP_FOO_SIZE := 4831838208
BOARD_GROUP_FOO_PARTITION_LIST := system product_services
BOARD_GROUP_BAR_SIZE := 1610612736
BOARD_GROUP_BAR_PARTITION_LIST := vendor product odm

Lưu ý: Tránh chọn tên có thể xung đột với các biến tạo bản dựng, chẳng hạn như super và super_partition. Để dễ đọc, hãy chọn các tên như foo_dp, foo_dynamic_partitions, foo_dp_group, super_foo hoặc group_foo (trong đó foo là tên của bên cập nhật một nhóm nhất định). Ví dụ: group_OEM hoặc group_VENDOR.

Lưu ý: Có thể có một hoặc nhiều nhóm cập nhật trên thiết bị.

• Đối với các thiết bị chạy A/B ảo, tổng kích thước tối đa của tất cả các nhóm phải tối đa là:
  BOARD_SUPER_PARTITION_SIZE – chi phí
  Xem bài viết Triển khai A/B ảo.
• Đối với các thiết bị chạy A/B, tổng quy mô tối đa của tất cả các nhóm phải là:
  BOARD_SUPER_PARTITION_SIZE / 2 – chi phí vận hành
• Đối với các thiết bị không phải thiết bị A/B và có thêm các thiết bị A/B, tổng giá trị tối đa kích thước của tất cả các nhóm phải là:
  BOARD_SUPER_PARTITION_SIZE – chi phí
• Tại thời điểm tạo, tổng kích thước hình ảnh của mỗi phân vùng trong nhóm cập nhật không được vượt quá kích thước tối đa của nhóm.
• Chi phí đầu vào là cần thiết trong quá trình tính toán để tính đến siêu dữ liệu, căn chỉnh, v.v. Mức hao tổn hợp lý là 4 MiB, nhưng bạn có thể chọn mức hao tổn lớn hơn theo yêu cầu của thiết bị.

Kích thước phân vùng động

Trước khi phân vùng động, kích thước phân vùng được phân bổ quá mức cho đảm bảo rằng chúng có đủ không gian cho các bản cập nhật trong tương lai. Kích thước thực tế được sử dụng nguyên trạng và hầu hết các phân vùng chỉ đọc đều có một lượng dung lượng trống trong hệ thống tệp của họ. Trong phân vùng động, không gian trống đó là không sử dụng được và có thể được dùng để tăng phân vùng trong OTA. Điều quan trọng là phải đảm bảo các phân vùng không làm lãng phí dung lượng và được phân bổ cho kích thước tối thiểu có thể.

Đối với hình ảnh ext4 chỉ có thể đọc, hệ thống xây dựng sẽ tự động phân bổ kích thước tối thiểu nếu không có kích thước phân vùng được mã hoá cứng nào được chỉ định. Chiến lược phát hành đĩa đơn hệ thống xây dựng phù hợp với hình ảnh để hệ thống tệp có ít không gian không được sử dụng nhiều nhất có thể. Việc này giúp đảm bảo rằng thiết bị không lãng phí có thể dùng cho OTA.

Ngoài ra, bạn có thể nén hình ảnh có định dạng ext4 bằng cách cho phép mã hoá khối loại bỏ trùng lặp cấp độ. Để bật tính năng này, hãy sử dụng cấu hình sau:

BOARD_EXT4_SHARE_DUP_BLOCKS := true

Nếu không nên tự động phân bổ kích thước tối thiểu của phân vùng, có hai cách để kiểm soát kích thước phân vùng. Bạn có thể chỉ định một lượng dung lượng trống tối thiểu với BOARD_partitionIMAGE_PARTITION_RESERVED_SIZE, hoặc bạn có thể chỉ định BOARD_partitionIMAGE_PARTITION_SIZE để buộc thành một kích thước cụ thể. Không có lựa chọn nào phù hợp trừ phi cần thiết.

Ví dụ:

BOARD_PRODUCTIMAGE_PARTITION_RESERVED_SIZE := 52428800

Thao tác này buộc hệ thống tệp trong product.img phải có 50 MiB dung lượng không sử dụng.

Lưu ý: Hệ thống xây dựng chỉ có thể hình ảnh hệ thống tệp ext4 phù hợp nhất và chỉ trên những hình ảnh được tạo bởi bản dựng. Đối với hình ảnh tạo sẵn hoặc hình ảnh sử dụng hệ thống tệp khác, là rất quan trọng để đảm bảo hệ thống tệp không lãng phí theo cách thủ công dung lượng trên ổ đĩa.

Thay đổi hệ thống dưới dạng gốc

Các thiết bị chạy Android 10 không được phép sử dụng hệ thống dưới dạng thư mục gốc.

Thiết bị có phân vùng động (cho dù ứng dụng chạy cùng với hay được trang bị lại phân vùng động) không được sử dụng hệ thống làm thư mục gốc. Nhân hệ điều hành Linux không thể diễn giải phân vùng super và do đó không thể gắn kết Chính system. system hiện được gắn kết bằng init giai đoạn đầu tiên, nằm trong ổ đĩa RAM.

Đừng đặt BOARD_BUILD_SYSTEM_ROOT_IMAGE. Ngang bằng Android 10, Cờ BOARD_BUILD_SYSTEM_ROOT_IMAGE chỉ được dùng để phân biệt xem hệ thống được cài đặt bằng kernel hay bằng init giai đoạn đầu tiên trong ramdisk.

Đang đặt BOARD_BUILD_SYSTEM_ROOT_IMAGE thành true gây ra lỗi bản dựng khi PRODUCT_USE_DYNAMIC_PARTITIONS cũng true.

Khi bạn đặt BOARD_USES_RECOVERY_AS_BOOT thành true, hình ảnh khôi phục được tạo dưới dạng boot.img chứa mã khôi phục ổ đĩa RAM. Trước đây, trình tải khởi động sử dụng nhân skip_initramfs tham số dòng lệnh để quyết định chế độ khởi động. Cho Thiết bị Android 10, trình tải khởi động KHÔNG ĐƯỢC vượt qua skip_initramfs vào dòng lệnh của nhân. Thay vào đó, trình tải khởi động sẽ chuyển androidboot.force_normal_boot=1 để bỏ qua bước khôi phục và khởi động thiết bị Android bình thường. Thiết bị chạy Android 12 phải sử dụng bootconfig để truyền androidboot.force_normal_boot=1.

Thay đổi về cấu hình AVB

Thận trọng: Phân vùng động cần Android đã xác minh Tính năng Khởi động (AVB) và không hoạt động với tính năng Xác minh quy trình khởi động 1.0.

Khi sử dụng Android Xác minh quy trình khởi động 2.0, nếu thiết bị không sử dụng phân vùng theo chuỗi , thì bạn không cần thay đổi. Nếu sử dụng chuỗi Tuy nhiên, một trong những phân vùng được xác minh là phân vùng động, thì bạn cần thay đổi.

Dưới đây là cấu hình mẫu cho một thiết bị liên kết vbmeta cho system và vendor phân vùng.

BOARD_AVB_SYSTEM_KEY_PATH := external/avb/test/data/testkey_rsa2048.pem
BOARD_AVB_SYSTEM_ALGORITHM := SHA256_RSA2048
BOARD_AVB_SYSTEM_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP)
BOARD_AVB_SYSTEM_ROLLBACK_INDEX_LOCATION := 1

BOARD_AVB_VENDOR_KEY_PATH := external/avb/test/data/testkey_rsa2048.pem
BOARD_AVB_VENDOR_ALGORITHM := SHA256_RSA2048
BOARD_AVB_VENDOR_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP)
BOARD_AVB_VENDOR_ROLLBACK_INDEX_LOCATION := 1

Với cấu hình này, trình tải khởi động muốn tìm vbmeta chân trang ở cuối system và vendor phân vùng. Vì những phân vùng này không còn hiển thị với trình tải khởi động (chúng nằm trong super), hai cần thay đổi.

• Thêm vbmeta_system và vbmeta_vendor phân vùng vào bảng phân vùng của thiết bị. Đối với thiết bị A/B, hãy thêm vbmeta_system_a, vbmeta_system_b vbmeta_vendor_a và vbmeta_vendor_b. Nếu thêm một hoặc nhiều phân vùng này, chúng phải có cùng kích thước làm phân vùng vbmeta.
• Đổi tên cờ cấu hình bằng cách thêm VBMETA_ và chỉ định những phân vùng mà chuỗi mở rộng đến:

  BOARD_AVB_VBMETA_SYSTEM := system
  BOARD_AVB_VBMETA_SYSTEM_KEY_PATH := external/avb/test/data/testkey_rsa2048.pem
  BOARD_AVB_VBMETA_SYSTEM_ALGORITHM := SHA256_RSA2048
  BOARD_AVB_VBMETA_SYSTEM_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP)
  BOARD_AVB_VBMETA_SYSTEM_ROLLBACK_INDEX_LOCATION := 1
  
  BOARD_AVB_VBMETA_VENDOR := vendor
  BOARD_AVB_VBMETA_VENDOR_KEY_PATH := external/avb/test/data/testkey_rsa2048.pem
  BOARD_AVB_VBMETA_VENDOR_ALGORITHM := SHA256_RSA2048
  BOARD_AVB_VBMETA_VENDOR_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP)
  BOARD_AVB_VBMETA_VENDOR_ROLLBACK_INDEX_LOCATION := 1
  

Một thiết bị có thể đang sử dụng một, cả hai hoặc không sử dụng phân vùng nào trong số này. Thay đổi chỉ cần khi liên kết vào một phân vùng logic.

Các thay đổi đối với trình tải khởi động AVB

Nếu trình tải khởi động đã nhúng libavb, bao gồm các bản vá sau:

• 818cf56740775446285466eda984acedd4baeac0 – "libavb: Chỉ GUID phân vùng truy vấn khi lệnh cmdline cần chúng".
• 5abd6bc2578968d24406d834471adfd995a0c2e9 – "Cho phép không có phân vùng hệ thống"
• 9ba3b6613b4e5130fa01a11d984c6b5f0eb3af05 — "Khắc phục AvbSlotVerifyData->cmdline có thể là NULL"

Nếu sử dụng phân vùng theo chuỗi, hãy thêm bản vá bổ sung:

• 49936b4c0109411fdd38bd4ba3a32a01c40439a9 — "libavb: Hỗ trợ blob vbmeta khi bắt đầu phân vùng."
  Lưu ý: Trước đây, bạn không bắt buộc phải triển khai get_size_of_partition trong AvbOps. Sau đây là thay đổi bắt buộc và trình tải khởi động phải triển khai hàm này.

Thay đổi dòng lệnh kernel

Bạn phải thêm một thông số mới là androidboot.boot_devices vào dòng lệnh kernel. init dùng thông tin này để bật đường liên kết tượng trưng /dev/block/by-name. Đó phải là thành phần đường dẫn thiết bị đến liên kết tượng trưng theo tên cơ bản được tạo bởi ueventd, tức là /dev/block/platform/device-path/by-name/partition-name. Các thiết bị chạy Android 12 trở lên phải sử dụng bootconfig để truyền androidboot.boot_devices đến init.

Ví dụ: nếu liên kết tượng trưng của phân vùng cấp cao theo tên là /dev/block/platform/soc/100000.ufshc/by-name/super, bạn có thể thêm tham số dòng lệnh trong tệp BoardConfig.mk dưới dạng sau:

BOARD_KERNEL_CMDLINE += androidboot.boot_devices=soc/100000.ufshc

Bạn có thể thêm tham số bootconfig trong tệp BoardConfig.mk như sau:

BOARD_BOOTCONFIG += androidboot.boot_devices=soc/100000.ufshc

thay đổi fstab

Lớp phủ cây thiết bị và cây thiết bị không được chứa fstab mục nhập. Sử dụng tệp fstab thuộc ổ đĩa ram.

Phải thực hiện các thay đổi đối với tệp fstab cho các phân vùng logic:

• Trường cờ fs_mgr phải bao gồm cờ logical và cờ first_stage_mount, được giới thiệu trong Android 10, cho biết rằng một phân vùng cần được gắn trong giai đoạn đầu tiên.
• Một phân vùng có thể chỉ định avb=vbmeta partition name với tư cách là Cờ fs_mgr, sau đó là vbmeta được chỉ định phân vùng được khởi tạo bởi giai đoạn đầu tiên init trước khi cố gắng kết nối bất kỳ thiết bị nào.
• Trường dev phải là tên phân vùng.

Các mục nhập fstab sau đây đặt hệ thống, nhà cung cấp và sản phẩm là logic phân vùng theo các quy tắc trên.

#<dev>  <mnt_point> <type>  <mnt_flags options> <fs_mgr_flags>
system   /system     ext4    ro,barrier=1        wait,slotselect,avb=vbmeta,logical,first_stage_mount
vendor   /vendor     ext4    ro,barrier=1        wait,slotselect,avb,logical,first_stage_mount
product  /product    ext4    ro,barrier=1        wait,slotselect,avb,logical,first_stage_mount

Lưu ý: Không bao gồm slotselect cho thiết bị không phải A/B.

Sao chép tệp fstab vào ổ đĩa ramdisk giai đoạn đầu tiên.

Thay đổi SELinux

Thiết bị khối siêu phân vùng phải được đánh dấu bằng nhãn super_block_device. Ví dụ: nếu liên kết tượng trưng của phân vùng cấp cao theo tên là /dev/block/platform/soc/100000.ufshc/by-name/super, thêm dòng sau vào file_contexts:

/dev/block/platform/soc/10000\.ufshc/by-name/super   u:object_r:super_block_device:s0

khởi động nhanh

Trình tải khởi động (hoặc bất kỳ công cụ cài đặt ROM nào không thuộc phạm vi người dùng) không hiểu các phân vùng động để không thể cài đặt ROM. Để giải quyết vấn đề này, thiết bị phải sử dụng phương thức triển khai không gian người dùng của giao thức khởi động nhanh, có tên là khởi động nhanh.

Để biết thêm thông tin về cách triển khai chế độ khởi động nhanh, hãy xem phần Chuyển chế độ Khởi động nhanh sang Không gian người dùng.

gắn lại adb

Đối với các nhà phát triển sử dụng bản dựng eng hoặc userdebug, adb remount cực kỳ hữu ích trong việc lặp lại nhanh. Phân vùng động tạo ra sự cố với adb remount vì không còn dung lượng trống dung lượng trong mỗi hệ thống tệp. Để giải quyết vấn đề này, thiết bị có thể bật lớp phủ. Miễn là có không gian trống trong phân vùng cấp cao, adb remount tự động tạo một thành phần động tạm thời phân vùng và sử dụng lớp phủ tệp để ghi. Phân vùng tạm thời là có tên là scratch, nên không dùng tên này cho tên khác phân vùng.

Để biết thêm thông tin về cách bật lớp phủ, hãy xem lớp overlayfs README trong AOSP.

Nâng cấp thiết bị Android

Nếu bạn nâng cấp một thiết bị lên Android 10 và muốn bao gồm hỗ trợ phân vùng động trong OTA, bạn không cần thay đổi bảng phân vùng tích hợp sẵn. Một số cấu hình bổ sung là bắt buộc.

Thay đổi cấu hình thiết bị

Để điều chỉnh lại tính năng phân vùng động, hãy thêm các cờ sau vào device.mk:

PRODUCT_USE_DYNAMIC_PARTITIONS := true
PRODUCT_RETROFIT_DYNAMIC_PARTITIONS := true

Thay đổi cấu hình bảng

Bạn phải đặt các biến bảng sau:

• Đặt BOARD_SUPER_PARTITION_BLOCK_DEVICES thành danh sách thiết bị chặn được sử dụng để lưu trữ số lượng kích thước của phân vùng động. Đây là danh sách tên của các cơ sở hạ tầng thực tế hiện có trên thiết bị.
• Đặt BOARD_SUPER_PARTITION_partition_DEVICE_SIZE theo kích thước của từng thiết bị khối trong BOARD_SUPER_PARTITION_BLOCK_DEVICES. Đây là danh sách kích thước của các phân vùng thực hiện có trên thiết bị. Việc này thường BOARD_partitionIMAGE_PARTITION_SIZE trong bảng hiện tại .
• Huỷ đặt BOARD_partitionIMAGE_PARTITION_SIZE hiện có cho tất cả phân vùng trong BOARD_SUPER_PARTITION_BLOCK_DEVICES.
• Đặt BOARD_SUPER_PARTITION_SIZE thành tổng của BOARD_SUPER_PARTITION_partition_DEVICE_SIZE.
• Đặt BOARD_SUPER_PARTITION_METADATA_DEVICE thành thiết bị khối Siêu dữ liệu phân vùng động sẽ được lưu trữ. Phải là một trong BOARD_SUPER_PARTITION_BLOCK_DEVICES. Thông thường, giá trị này được đặt thành system.
• Đặt BOARD_SUPER_PARTITION_GROUPS, BOARD_group_SIZE và BOARD_group_PARTITION_LIST. Xem Thay đổi cấu hình bảng trên thiết bị mới để biết thông tin chi tiết.

Ví dụ: nếu thiết bị đã có phân vùng hệ thống và phân vùng của nhà cung cấp và bạn muốn chuyển đổi chúng vào phân vùng động và thêm phân vùng sản phẩm mới trong quá trình cập nhật, hãy đặt cấu hình bảng sau:

BOARD_SUPER_PARTITION_BLOCK_DEVICES := system vendor
BOARD_SUPER_PARTITION_METADATA_DEVICE := system

# Rename BOARD_SYSTEMIMAGE_PARTITION_SIZE to BOARD_SUPER_PARTITION_SYSTEM_DEVICE_SIZE.
BOARD_SUPER_PARTITION_SYSTEM_DEVICE_SIZE := <size-in-bytes>

# Rename BOARD_VENDORIMAGE_PARTITION_SIZE to BOARD_SUPER_PARTITION_VENDOR_DEVICE_SIZE
BOARD_SUPER_PARTITION_VENDOR_DEVICE_SIZE := <size-in-bytes>

# This is BOARD_SUPER_PARTITION_SYSTEM_DEVICE_SIZE + BOARD_SUPER_PARTITION_VENDOR_DEVICE_SIZE
BOARD_SUPER_PARTITION_SIZE := <size-in-bytes>

# Configuration for dynamic partitions. For example:
BOARD_SUPER_PARTITION_GROUPS := group_foo
BOARD_GROUP_FOO_SIZE := <size-in-bytes>
BOARD_GROUP_FOO_PARTITION_LIST := system vendor product

Thay đổi SELinux

Các thiết bị khối siêu phân vùng phải được đánh dấu bằng thuộc tính này super_block_device_type. Ví dụ: nếu thiết bị đã có Phân vùng system và vendor, bạn muốn dùng chúng dưới dạng khối thiết bị để lưu trữ số lượng kích thước của phân vùng động và các liên kết tượng trưng theo tên của chúng được đánh dấu là system_block_device:

/dev/block/platform/soc/10000\.ufshc/by-name/system   u:object_r:system_block_device:s0
/dev/block/platform/soc/10000\.ufshc/by-name/vendor   u:object_r:system_block_device:s0

Sau đó, hãy thêm dòng sau vào device.te:

typeattribute system_block_device super_block_device_type;

Đối với các cấu hình khác, vui lòng xem phần Triển khai phân vùng động trên thiết bị mới.

Để biết thêm thông tin về nội dung cập nhật cho việc cải tiến, hãy xem OTA cho các thiết bị A/B không có Dynamic Vách ngăn.

Hình ảnh gốc

Để thiết bị chạy có hỗ trợ phân vùng động, hãy tránh sử dụng tính năng khởi động nhanh cho không gian người dùng để cài đặt ROM hình ảnh gốc, vì việc khởi động vào không gian người dùng chậm hơn các phương thức cài đặt ROM khác.

Để giải quyết vấn đề này, make dist hiện tạo thêm một Hình ảnh super.img có thể được chiếu nhanh trực tiếp lên lớp phủ phân vùng. Quảng cáo này tự động gói nội dung của các phân vùng, nghĩa là dữ liệu này chứa system.img, vendor.img, v.v. ngoài super siêu dữ liệu phân vùng. Hình ảnh này có thể được cài đặt ROM trực tiếp lên Phân vùng super không có bất kỳ công cụ bổ sung hoặc sử dụng nào khởi động nhanh. Sau khi tạo bản dựng, super.img được đặt trong ${ANDROID_PRODUCT_OUT}.

Đối với các thiết bị A/B chạy bằng phân vùng động, super.img chứa các hình ảnh trong vị trí A. Sau khi cài đặt ROM trực tiếp Super hình ảnh, hãy đánh dấu vị trí A là có thể khởi động trước khi khởi động lại thiết bị.

Đối với các thiết bị được cải tiến, make dist sẽ tạo một tập hợp super_*.img hình ảnh có thể được cài đặt ROM trực tiếp vào phân vùng vật lý tương ứng. Ví dụ: make dist bản dựng super_system.img và super_vendor.img khi BOARD_SUPER_PARTITION_BLOCK_DEVICES là hệ thống nhà cung cấp. Những hình ảnh này được đặt trong thư mục OTA trong target_files.zip.

Điều chỉnh thiết bị lưu trữ của trình liên kết thiết bị

Tính năng phân vùng động phù hợp với một số trình lập bản đồ thiết bị không xác định . Không phải tất cả các lượt chuyển đổi này đều được tạo thực thể như mong đợi, do đó, bạn phải theo dõi tất cả gắn kết và cập nhật các thuộc tính Android của tất cả phân vùng được liên kết bằng các thiết bị lưu trữ cơ bản của họ.

Một cơ chế bên trong init theo dõi các giá trị gắn kết và không đồng bộ cập nhật các thuộc tính của Android. Khoảng thời gian này không được đảm bảo trong một khoảng thời gian cụ thể, nên bạn phải cung cấp đủ thời gian để mọi điều kiện kích hoạt on property phản ứng. Các cơ sở lưu trú này dev.mnt.blk.<partition> trong đó <partition> hiện là root, system, data hoặc vendor. Mỗi thuộc tính đều được liên kết với tên thiết bị lưu trữ cơ sở, như được thể hiện trong các ví dụ sau:

taimen:/ % getprop | grep dev.mnt.blk
[dev.mnt.blk.data]: [sda]
[dev.mnt.blk.firmware]: [sde]
[dev.mnt.blk.metadata]: [sde]
[dev.mnt.blk.persist]: [sda]
[dev.mnt.blk.root]: [dm-0]
[dev.mnt.blk.vendor]: [dm-1]

blueline:/ $ getprop | grep dev.mnt.blk
[dev.mnt.blk.data]: [dm-4]
[dev.mnt.blk.metadata]: [sda]
[dev.mnt.blk.mnt.scratch]: [sda]
[dev.mnt.blk.mnt.vendor.persist]: [sdf]
[dev.mnt.blk.product]: [dm-2]
[dev.mnt.blk.root]: [dm-0]
[dev.mnt.blk.system_ext]: [dm-3]
[dev.mnt.blk.vendor]: [dm-1]
[dev.mnt.blk.vendor.firmware_mnt]: [sda]

Ngôn ngữ init.rc cho phép các thuộc tính Android mở rộng theo quy tắc, đồng thời nền tảng có thể điều chỉnh thiết bị lưu trữ khi cần bằng các lệnh như sau:

write /sys/block/${dev.mnt.blk.root}/queue/read_ahead_kb 128
write /sys/block/${dev.mnt.blk.data}/queue/read_ahead_kb 128

Sau khi quá trình xử lý lệnh bắt đầu trong init giai đoạn thứ hai, epoll loop sẽ hoạt động và các giá trị bắt đầu cập nhật. Tuy nhiên, bởi vì trình kích hoạt thuộc tính không hoạt động cho đến cuối init, nên không thể sử dụng trong các giai đoạn khởi động ban đầu để xử lý root, system hoặc vendor. Có thể bạn sẽ thấy kernel mặc định read_ahead_kb là đủ cho đến khi init.rc tập lệnh có thể ghi đè trong early-fs (khi nhiều trình nền và cơ sở khác nhau khởi động). Do đó, Google khuyên bạn bạn sử dụng tính năng on property, cùng với một thuộc tính do init.rc kiểm soát như sys.read_ahead_kb, để xử lý vấn đề thời gian hoạt động và ngăn chặn tình huống tương tranh, như trong ví dụ:

on property:dev.mnt.blk.root=* && property:sys.read_ahead_kb=*
    write /sys/block/${dev.mnt.blk.root}/queue/read_ahead_kb ${sys.read_ahead_kb:-2048}

on property:dev.mnt.blk.system=* && property:sys.read_ahead_kb=*
    write /sys/block/${dev.mnt.blk.system}/queue/read_ahead_kb ${sys.read_ahead_kb:-2048}

on property:dev.mnt.blk.vendor=* && property:sys.read_ahead_kb=*
    write /sys/block/${dev.mnt.blk.vendor}/queue/read_ahead_kb ${sys.read_ahead_kb:-2048}

on property:dev.mnt.blk.product=* && property:sys.read_ahead_kb=*
    write /sys/block/${dev.mnt.blk.system_ext}/queue/read_ahead_kb ${sys.read_ahead_kb:-2048}

on property:dev.mnt.blk.oem=* && property:sys.read_ahead_kb=*
    write /sys/block/${dev.mnt.blk.oem}/queue/read_ahead_kb ${sys.read_ahead_kb:-2048}

on property:dev.mnt.blk.data=* && property:sys.read_ahead_kb=*
    write /sys/block/${dev.mnt.blk.data}/queue/read_ahead_kb ${sys.read_ahead_kb:-2048}

on early-fs:
    setprop sys.read_ahead_kb ${ro.read_ahead_kb.boot:-2048}

on property:sys.boot_completed=1
   setprop sys.read_ahead_kb ${ro.read_ahead_kb.bootcomplete:-128}