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.
Để ướ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.
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
-
Đố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.
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
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êmvbmeta_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ùngvbmeta
. -
Đổ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."
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.ufshcBạ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êninit
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
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 trongBOARD_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ườngBOARD_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 trongBOARD_SUPER_PARTITION_BLOCK_DEVICES
. - Đặt
BOARD_SUPER_PARTITION_SIZE
thành tổng củaBOARD_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 trongBOARD_SUPER_PARTITION_BLOCK_DEVICES
. Thông thường, giá trị này được đặt thànhsystem
. - Đặ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}