Google cam kết thúc đẩy công bằng chủng tộc cho Cộng đồng người da đen. Xem cách thực hiện.

Trang này được dịch bởi Cloud Translation API.

Bản cập nhật hệ thống động

Bản cập nhật hệ thống động (DSU) cho phép bạn tạo ảnh hệ thống Android người dùng có thể tải xuống từ Internet và dùng thử mà không có nguy cơ bị hỏng hình ảnh hệ thống hiện tại. Tài liệu này mô tả cách hỗ trợ DSU.

Yêu cầu về kernel

Xem Triển khai phân vùng động để đáp ứng các yêu cầu về nhân hệ điều hành.

Ngoài ra, DSU còn dựa vào tính năng hạt nhân của tính năng lập bản đồ thiết bị (dm-verity) để xác minh ảnh hệ thống Android. Vì vậy, bạn phải bật nhân hệ điều hành sau cấu hình:

CONFIG_DM_VERITY=y
CONFIG_DM_VERITY_FEC=y

Yêu cầu về phân vùng

Kể từ Android 11, DSU yêu cầu phải có /data để sử dụng hệ thống tệp F2FS hoặc ext4. F2FS mang lại hiệu suất tốt hơn và được đề xuất, nhưng sự khác biệt sẽ không đáng kể.

Dưới đây là một số ví dụ về thời gian cập nhật hệ thống động cho điện thoại Pixel thiết bị:

Sử dụng F2FS:
- 109s, 8G người dùng, 867M hệ thống, loại hệ thống tệp: F2FS: mã hoá=aes-256-xts:aes-256-cts
- 104 giây, 8G người dùng, 867M hệ thống, loại hệ thống tệp: F2FS: mã hoá=băng
Sử dụng định dạng ext4:
- 135s, người dùng 8G, hệ thống 867M, loại hệ thống tệp: ext4: mã hoá=aes-256-xts:aes-256-cts

Nếu mất nhiều thời gian hơn trên nền tảng, bạn nên kiểm tra xem giá đỡ cờ chứa bất kỳ cờ nào cho phép ghi “đồng bộ hoá” hoặc bạn có thể chỉ định chế độ “không đồng bộ” gắn cờ rõ ràng để có hiệu suất tốt hơn.

Cần có phân vùng metadata (16 MB trở lên) để lưu trữ dữ liệu liên quan vào hình ảnh đã cài đặt. Bạn phải lắp thiết bị trong quá trình gắn thiết bị ở giai đoạn đầu tiên.

Phân vùng userdata phải sử dụng hệ thống tệp F2FS hoặc ext4. Khi sử dụng F2FS, bao gồm tất cả bản vá liên quan đến F2FS có trong Nhân hệ điều hành phổ biến của Android.

DSU được phát triển và thử nghiệm bằng kernel/common 4.9. Bạn nên sử dụng kernel 4.9 trở lên cho tính năng này.

Cách hoạt động của lớp trừu tượng phần cứng (HAL) của nhà cung cấp

HAL (Lớp trừu tượng phần cứng) của Weaver

HAL (Lớp trừu tượng phần cứng) của thợ dệt cung cấp một số lượng khe cố định để lưu trữ khoá người dùng. DSU sử dụng thêm hai khe khoá. Nếu nhà sản xuất thiết bị gốc có lớp trừu tượng phần cứng (HAL) cho thợ dệt, nhà sản xuất thiết bị gốc đó cần có đủ chỗ cho hình ảnh hệ thống chung (GSI) và hình ảnh máy chủ lưu trữ.

HAL (Lớp trừu tượng phần cứng) cho người trực điện thoại

Lớp trừu tượng phần cứng (HAL) cho người trực điện thoại cần hỗ trợ các giá trị USER_ID lớn, vì GSI bù trừ UID sang HAL bằng cách +1000000.

Xác minh khởi động

Nếu bạn muốn hỗ trợ khởi động Hình ảnh GSI dành cho nhà phát triển ở trạng thái ĐÃ KHOÁ mà không tắt quy trình khởi động được xác minh, hãy thêm khoá GSI dành cho nhà phát triển bằng cách thêm dòng sau vào tệp device/<device_name>/device.mk:

$(call inherit-product, $(SRC_TARGET_DIR)/product/developer_gsi_keys.mk)

Bảo vệ khôi phục

Khi sử dụng DSU, hình ảnh hệ thống Android đã tải xuống phải mới hơn hình ảnh hình ảnh hệ thống hiện tại trên thiết bị. Việc này được thực hiện bằng cách so sánh bản vá bảo mật trong Xác minh quy trình khởi động trên Android (AVB) Mã mô tả thuộc tính AVB của cả hai hình ảnh hệ thống: Prop: com.android.build.system.security_patch -> '2019-04-05'.

Đối với các thiết bị không sử dụng AVB, hãy đặt cấp bản vá bảo mật của hệ thống hiện tại hình ảnh vào lệnh cmdline nhân hệ điều hành hoặc bootconfig bằng trình tải khởi động: androidboot.system.security_patch=2019-04-05.

Yêu cầu về phần cứng

Khi bạn chạy một thực thể DSU, hệ thống sẽ phân bổ 2 tệp tạm thời:

Một phân vùng logic để lưu trữ GSI.img (1~1,5 G)
Phân vùng /data trống 8 GB làm hộp cát để chạy GSI

Bạn nên đặt trước ít nhất 10 GB dung lượng trống trước khi khởi chạy DSU thực thể. DSU cũng hỗ trợ phân bổ qua thẻ SD. Khi thẻ SD đang hiện tại, nó có mức độ ưu tiên cao nhất trong quá trình phân bổ. Hỗ trợ thẻ SD bây giờ là rất quan trọng đối với các thiết bị tiết kiệm pin hơn có thể không có đủ bộ nhớ trong. Khi có thẻ SD, hãy đảm bảo bạn chưa lắp thẻ. Không hỗ trợ DSU đã sử dụng thẻ SD.

Giao diện người dùng có sẵn

Bạn có thể chạy DSU bằng adb, một ứng dụng của Nhà sản xuất thiết bị gốc (OEM) hoặc trình tải DSU bằng một lần nhấp (trong Android 11 trở lên).

Chạy DSU bằng adb

Để chạy DSU bằng adb, hãy nhập các lệnh sau:

$ simg2img out/target/product/.../system.img system.raw
$ gzip -c system.raw > system.raw.gz
$ adb push system.raw.gz /storage/emulated/0/Download
$ adb shell am start-activity \
-n com.android.dynsystem/com.android.dynsystem.VerificationActivity  \
-a android.os.image.action.START_INSTALL    \
-d file:///storage/emulated/0/Download/system.raw.gz  \
--el KEY_SYSTEM_SIZE $(du -b system.raw|cut -f1)  \
--el KEY_USERDATA_SIZE 8589934592

Chạy DSU bằng một ứng dụng

Điểm truy cập chính vào DSU là android.os.image.DynamicSystemClient.java API:

public class DynamicSystemClient {


...
...

     /**
     * Start installing DynamicSystem from URL with default userdata size.
     *
     * @param systemUrl A network URL or a file URL to system image.
     * @param systemSize size of system image.
     */
    public void start(String systemUrl, long systemSize) {
        start(systemUrl, systemSize, DEFAULT_USERDATA_SIZE);
    }

Bạn phải gói/cài đặt trước ứng dụng này trên thiết bị. Bởi vì DynamicSystemClient là một API hệ thống, bạn không thể tạo ứng dụng bằng thuộc tính thông thường SDK API và bạn không thể phát hành SDK đó trên Google Play. Mục đích của ứng dụng này là:

Tìm nạp danh sách hình ảnh và URL tương ứng bằng lược đồ do nhà cung cấp xác định.
Khớp các hình ảnh trong danh sách với thiết bị và hiển thị hình ảnh tương thích để người dùng chọn.

Gọi DynamicSystemClient.start như sau:

DynamicSystemClient aot = new DynamicSystemClient(...)
   aot.start(
        ...URL of the selected image...,
        ...uncompressed size of the selected image...);

URL trỏ đến tệp hình ảnh hệ thống được nén, không thưa thớt mà bạn có thể tạo bằng các lệnh sau:

$ simg2img ${OUT}/system.img ${OUT}/system.raw
$ gzip ${OUT}/system.raw
$ ls ${OUT}/system.raw.gz

Tên tệp phải theo định dạng sau:

<android version>.<lunch name>.<user defined title>.raw.gz

Ví dụ:

o.aosp_taimen-userdebug.2018dev.raw.gz
p.aosp_taimen-userdebug.2018dev.raw.gz

Trình tải DSU bằng một lần nhấp

Android 11 ra mắt trình tải DSU bằng một lần nhấp là một giao diện người dùng trong chế độ cài đặt dành cho nhà phát triển.

Hình 1. Khởi chạy trình tải DSU

Khi nhấp vào nút Trình tải DSU, nhà phát triển sẽ tìm nạp một trình tải lên được định cấu hình sẵn Bộ mô tả JSON DSU từ web và hiển thị tất cả hình ảnh có thể áp dụng trong trình đơn nổi. Chọn một hình ảnh để bắt đầu cài đặt DSU và tiến trình hiển thị trên thanh thông báo.

Tiến trình cài đặt hình ảnh DSU

Hình 2. Tiến trình cài đặt hình ảnh DSU

Theo mặc định, trình tải DSU tải một phần mô tả JSON có chứa hình ảnh GSI. Các phần sau đây minh hoạ cách tạo các gói DSU do OEM ký và tải chúng qua trình tải DSU.

Cờ tính năng

Tính năng DSU nằm dưới cờ tính năng settings_dynamic_android. Trước bằng cách sử dụng DSU, hãy đảm bảo cờ tính năng tương ứng được bật.

Đang bật cờ tính năng.

Hình 3. Bật cờ tính năng

Giao diện người dùng của cờ tính năng có thể không dùng được trên thiết bị đang chạy bản dựng người dùng. Ngang bằng trong trường hợp này, hãy dùng lệnh adb:

$ adb shell setprop persist.sys.fflag.override.settings_dynamic_system 1

Hình ảnh hệ thống lưu trữ của nhà cung cấp trên GCE (không bắt buộc)

Một trong các vị trí lưu trữ hình ảnh hệ thống có thể là Bộ chứa Compute Engine (GCE). Quản trị viên phát hành sử dụng Bảng điều khiển bộ nhớ GCP để thêm/xoá/thay đổi hình ảnh hệ thống đã phát hành.

Các hình ảnh này phải cho phép truy cập công khai, như minh họa bên dưới:

Quyền truy cập công khai trong GCE

Hình 4. Quyền truy cập công khai trong GCE

Quy trình công khai một mục trong Tài liệu của Google Cloud.

DSU nhiều phân vùng trong tệp ZIP

Kể từ Android 11, DSU có thể có nhiều phân vùng. Ví dụ: tệp này có thể chứa product.img ngoài tham số system.img. Khi thiết bị khởi động, giai đoạn đầu tiên init sẽ phát hiện cài đặt phân vùng DSU và tạm thời thay thế phân vùng trên thiết bị, khi DSU đã cài đặt đang được bật. Gói DSU có thể chứa một phân vùng không có phân vùng tương ứng trên thiết bị.

Quá trình DSU có nhiều phân vùng

Hình 5. Quá trình DSU có nhiều phân vùng

DSU do OEM ký

Để đảm bảo tất cả hình ảnh đang chạy trên thiết bị đều được thiết bị cho phép tất cả hình ảnh trong gói DSU đều phải được ký. Ví dụ: giả sử có một gói DSU chứa hai hình ảnh phân vùng như bên dưới:

dsu.zip {
    - system.img
    - product.img
}

Cả system.img và product.img đều phải được ký bằng khoá OEM thì mới có thể sử dụng được đưa vào tệp ZIP. Phương pháp phổ biến là sử dụng (ví dụ: RSA), trong đó khoá bí mật được dùng để ký gói và sẽ được dùng để xác minh khoá đó. Đĩa RAM giai đoạn đầu tiên phải bao gồm phần ghép nối khoá công khai, ví dụ: /avb/*.avbpubkey. Nếu thiết bị đã áp dụng AVB, thì quy trình ký tên hiện tại là đủ. Các phần sau đây minh hoạ quá trình ký và đánh dấu vị trí của khoá xuất bản AVB được dùng để xác minh hình ảnh trong gói DSU.

Mã mô tả JSON DSU

Phần mô tả JSON DSU mô tả các gói DSU. Lớp này hỗ trợ 2 dữ liệu gốc. Trước tiên, dữ liệu gốc include bao gồm các phần mô tả JSON hoặc lệnh chuyển hướng khác trình tải DSU đến một vị trí mới. Ví dụ:

{
    "include": ["https://.../gsi-release/gsi-src.json"]
}

Tiếp theo, dữ liệu gốc image được dùng để mô tả các gói DSU đã phát hành. Bên trong có một số thuộc tính:

Thuộc tính name và details là các chuỗi hiển thị trên hộp thoại để người dùng chọn.
Các thuộc tính cpu_api, vndk và os_version được dùng cho kiểm tra khả năng tương thích, được mô tả trong phần tiếp theo.
Thuộc tính pubkey (không bắt buộc) mô tả các đối tượng công khai khoá kết hợp với khoá bí mật dùng để ký gói DSU. Khi bạn chỉ định giá trị này, dịch vụ DSU có thể kiểm tra xem thiết bị có khoá hay không dùng để xác minh gói DSU. Việc này giúp tránh việc cài đặt một DSU không nhận dạng được gói, ví dụ: cài đặt DSU do OEM-A ký cho một thiết bị do OEM-B.
Thuộc tính không bắt buộc tos trỏ đến một tệp văn bản mô tả điều khoản dịch vụ của gói DSU tương ứng. Khi một nhà phát triển chọn một gói DSU có thuộc tính điều khoản dịch vụ được chỉ định, hộp thoại minh hoạ trong Hình 6 mở ra, yêu cầu nhà phát triển chấp nhận các điều khoản trước khi cài đặt gói DSU.

Hình 6. Hộp thoại Điều khoản dịch vụ

Để tham khảo, dưới đây là phần mô tả JSON của DSU cho GSI:

{
   "images":[
      {
         "name":"GSI+GMS x86",
         "os_version":"10",
         "cpu_abi": "x86",
         "details":"exp-QP1A.190711.020.C4-5928301",
         "vndk":[
            27,
            28,
            29
         ],
         "pubkey":"",
         "tos": "https://dl.google.com/developers/android/gsi/gsi-tos.txt",
         "uri":"https://.../gsi/gsi_gms_x86-exp-QP1A.190711.020.C4-5928301.zip"
      },
      {
         "name":"GSI+GMS ARM64",
         "os_version":"10",
         "cpu_abi": "arm64-v8a",
         "details":"exp-QP1A.190711.020.C4-5928301",
         "vndk":[
            27,
            28,
            29
         ],
         "pubkey":"",
         "tos": "https://dl.google.com/developers/android/gsi/gsi-tos.txt",
         "uri":"https://.../gsi/gsi_gms_arm64-exp-QP1A.190711.020.C4-5928301.zip"
      },
      {
         "name":"GSI ARM64",
         "os_version":"10",
         "cpu_abi": "arm64-v8a",
         "details":"exp-QP1A.190711.020.C4-5928301",
         "vndk":[
            27,
            28,
            29
         ],
         "pubkey":"",
         "uri":"https://.../gsi/aosp_arm64-exp-QP1A.190711.020.C4-5928301.zip"
      },
      {
         "name":"GSI x86_64",
         "os_version":"10",
         "cpu_abi": "x86_64",
         "details":"exp-QP1A.190711.020.C4-5928301",
         "vndk":[
            27,
            28,
            29
         ],
         "pubkey":"",
         "uri":"https://.../gsi/aosp_x86_64-exp-QP1A.190711.020.C4-5928301.zip"
      }
   ]
}

Quản lý khả năng tương thích

Một số thuộc tính dùng để chỉ định khả năng tương thích giữa một gói DSU và thiết bị cục bộ:

cpu_api là một chuỗi mô tả cấu trúc thiết bị. Thuộc tính này là bắt buộc và được so sánh với thuộc tính hệ thống ro.product.cpu.abi. Giá trị của các giá trị này phải hoàn toàn khớp nhau.
os_version là một số nguyên không bắt buộc dùng để chỉ định một bản phát hành Android. Cho ví dụ: đối với Android 10, os_version là 10 và đối với Android 11, os_version là 11. Khi việc này đã chỉ định, thì thuộc tính này phải bằng hoặc lớn hơn ro.system.build.version.release thuộc tính hệ thống của chúng tôi. Quy trình kiểm tra này dùng để ngăn việc khởi động hình ảnh GSI của Android 10 trên Android 11 thiết bị của nhà cung cấp (hiện không được hỗ trợ). Bạn được phép khởi động hình ảnh GSI Android 11 trên thiết bị Android 10.
vndk là một mảng không bắt buộc dùng để xác định tất cả VNDK có trong gói DSU. Khi bạn chỉ định giá trị này, trình tải DSU sẽ kiểm tra xem số được trích xuất từ thuộc tính hệ thống ro.vndk.version đều được đưa vào.

Thu hồi khoá DSU vì lý do bảo mật

Trong trường hợp cực kỳ hiếm khi cặp khoá RSA được dùng để ký các hình ảnh DSU được bị xâm phạm, ramdisk phải được cập nhật càng sớm càng tốt để xoá khoá bị lộ. Ngoài việc cập nhật phân vùng khởi động, bạn có thể chặn khoá bị xâm phạm bằng danh sách thu hồi khoá DSU (danh sách khoá bị cấm) từ một HTTPS URL.

Danh sách thu hồi khoá DSU chứa danh sách các khoá công khai AVB đã bị thu hồi. Trong quá trình cài đặt DSU, các khoá công khai bên trong hình ảnh DSU sẽ được xác thực bằng danh sách thu hồi. Nếu hình ảnh bị phát hiện có chứa tệp công khai bị thu hồi thì quá trình cài đặt DSU sẽ dừng.

URL của danh sách thu hồi khoá phải là một URL loại HTTPS để đảm bảo tính bảo mật và được chỉ định trong chuỗi tài nguyên:

frameworks/base/packages/DynamicSystemInstallationService/res/values/strings.xml@key_revocation_list_url

Giá trị của chuỗi là https://dl.google.com/developers/android/gsi/gsi-keyblacklist.json, là một danh sách thu hồi đối với các khoá GSI do Google phát hành. Chuỗi tài nguyên này có thể là phủ và tuỳ chỉnh, để những OEM sử dụng tính năng DSU có thể cung cấp và duy trì danh sách cấm chính của riêng họ. Đây là cách để OEM chặn một số khoá công khai mà không cần cập nhật hình ảnh ổ đĩa ram của thiết bị.

Danh sách thu hồi có định dạng như sau:

{
   "entries":[
      {
         "public_key":"bf14e439d1acf231095c4109f94f00fc473148e6",
         "status":"REVOKED",
         "reason":"Key revocation test key"
      },
      {
         "public_key":"d199b2f29f3dc224cca778a7544ea89470cbef46",
         "status":"REVOKED",
         "reason":"Key revocation test key"
      }
   ]
}

public_key là chuỗi đại diện SHA-1 của khoá đã thu hồi, ở định dạng được mô tả trong phần tạo khoá xuất bản AVB .
status cho biết trạng thái thu hồi của khoá. Hiện tại, chỉ có giá trị được hỗ trợ là REVOKED.
reason là một chuỗi không bắt buộc mô tả lý do thu hồi.

Quy trình DSU

Phần này mô tả cách thực hiện một số quy trình cấu hình DSU.

Tạo một cặp khoá mới

Dùng lệnh openssl để tạo cặp khoá riêng tư/công khai RSA trong .pem định dạng (ví dụ: có kích thước 2048 bit):

$ openssl genrsa -out oem_cert_pri.pem 2048
$ openssl rsa -in oem_cert_pri.pem -pubout -out oem_cert_pub.pem

Khoá riêng tư có thể không truy cập được và chỉ được giữ trong một mô-đun bảo mật phần cứng (HSM). Trong trường hợp này, có thể có chứng chỉ khoá công khai x509 sau khoá tạo. Xem phần Thêm mã khóa ghép nối vào ổ đĩa ram để biết hướng dẫn tạo khoá công khai AVB từ chứng chỉ x509.

Cách chuyển đổi chứng chỉ x509 sang định dạng PEM:

$ openssl x509 -pubkey -noout -in oem_cert_pub.x509.pem > oem_cert_pub.pem

Hãy bỏ qua bước này nếu chứng chỉ đã là tệp PEM.

Thêm mã pubkey ghép nối vào ổ đĩa RAM

Bạn phải đặt oem_cert.avbpubkey dưới /avb/*.avbpubkey để xác minh gói DSU đã ký. Trước tiên, hãy chuyển đổi khoá công khai ở định dạng PEM sang AVB công khai định dạng khoá:

$ avbtool extract_public_key --key oem_cert_pub.pem --output oem_cert.avbpubkey

Sau đó, đưa khoá công khai vào ổ đĩa RAM giai đoạn đầu tiên theo các bước sau.

Thêm một mô-đun tạo sẵn để sao chép avbpubkey. Ví dụ: hãy thêm device/<company>/<board>/oem_cert.avbpubkey và device/<company>/<board>/avb/Android.mk với nội dung như sau:

include $(CLEAR_VARS)

LOCAL_MODULE := oem_cert.avbpubkey
LOCAL_MODULE_CLASS := ETC
LOCAL_SRC_FILES := $(LOCAL_MODULE)
ifeq ($(BOARD_USES_RECOVERY_AS_BOOT),true)
LOCAL_MODULE_PATH := $(TARGET_RECOVERY_ROOT_OUT)/first_stage_ramdisk/avb
else
LOCAL_MODULE_PATH := $(TARGET_RAMDISK_OUT)/avb
endif

include $(BUILD_PREBUILT)

Làm cho mục tiêu droidcore phụ thuộc vào oem_cert.avbpubkey đã thêm:
```
droidcore: oem_cert.avbpubkey
```

Tạo thuộc tính AVB pubkey trong phần mô tả JSON

oem_cert.avbpubkey ở định dạng nhị phân của khoá công khai AVB. Sử dụng SHA-1 để làm cho mã đó dễ đọc trước khi đặt vào bộ mô tả JSON:

$ sha1sum oem_cert.avbpubkey | cut -f1 -d ' '
3e62f2be9d9d813ef5........866ac72a51fd20

Đây sẽ là nội dung của thuộc tính pubkey của phần mô tả JSON.

   "images":[
      {
         ...
         "pubkey":"3e62f2be9d9d813ef5........866ac72a51fd20",
         ...
      },

Ký gói DSU

Bạn có thể sử dụng một trong các phương thức sau để ký gói DSU:

Phương thức 1: Tái sử dụng cấu phần phần mềm do quy trình ký AVB ban đầu tạo ra để tạo một gói DSU. Một phương pháp khác là trích xuất dữ liệu đã ký hình ảnh từ gói phát hành và sử dụng hình ảnh đã trích xuất để tạo tệp ZIP trực tiếp.

Phương pháp 2: Sử dụng các lệnh sau để ký phân vùng DSU nếu khóa. Mỗi img trong một gói DSU (tệp ZIP) được ký riêng biệt:

$ key_len=$(openssl rsa -in oem_cert_pri.pem -text | grep Private-Key | sed -e 's/.*(\(.*\) bit.*/\1/')
$ for partition in system product; do
    avbtool add_hashtree_footer \
        --image ${OUT}/${partition}.img \
        --partition_name ${partition} \
        --algorithm SHA256_RSA${key_len} \
        --key oem_cert_pri.pem
done

Để biết thêm thông tin về cách thêm add_hashtree_footer bằng avbtool, hãy xem Sử dụng avbtool.

Xác minh gói DSU trên thiết bị

Bạn nên xác minh tất cả hình ảnh cục bộ dựa trên việc ghép nối khoá công khai với các lệnh sau:


for partition in system product; do
    avbtool verify_image --image ${OUT}/${partition}.img  --key oem_cert_pub.pem
done

Kết quả dự kiến sẽ có dạng như sau:

Verifying image dsu/system.img using key at oem_cert_pub.pem
vbmeta: Successfully verified footer and SHA256_RSA2048 vbmeta struct in dsu/system.img
: Successfully verified sha1 hashtree of dsu/system.img for image of 898494464 bytes

Verifying image dsu/product.img using key at oem_cert_pub.pem
vbmeta: Successfully verified footer and SHA256_RSA2048 vbmeta struct in dsu/product.img
: Successfully verified sha1 hashtree of dsu/product.img for image of 905830400 bytes

Tạo một gói DSU

Ví dụ sau đây sẽ tạo một gói DSU chứa system.img và product.img:

dsu.zip {
    - system.img
    - product.img
}

Sau khi cả hai hình ảnh đã được ký, hãy sử dụng lệnh sau để tạo tệp ZIP:

$ mkdir -p dsu
$ cp ${OUT}/system.img dsu
$ cp ${OUT}/product.img dsu
$ cd dsu && zip ../dsu.zip *.img && cd -

Tuỳ chỉnh DSU bằng một lần nhấp

Theo mặc định, trình tải DSU trỏ đến một siêu dữ liệu của hình ảnh GSI https://...google.com/.../gsi-src.json.

OEM có thể ghi đè danh sách bằng cách xác định persist.sys.fflag.override.settings_dynamic_system.list thuộc tính trỏ đến chỉ số mô tả JSON của riêng chúng. Ví dụ: OEM có thể cung cấp siêu dữ liệu JSON bao gồm GSI cũng như hình ảnh thuộc quyền sở hữu riêng của OEM như sau:

{
    "include": ["https://dl.google.com/.../gsi-src.JSON"]
    "images":[
      {
         "name":"OEM image",
         "os_version":"10",
         "cpu_abi": "arm64-v8a",
         "details":"...",
         "vndk":[
            27,
            28,
            29
         ],
         "spl":"...",
         "pubkey":"",
         "uri":"https://.../....zip"
      },

}

OEM có thể tạo chuỗi siêu dữ liệu DSU đã phát hành như trong Hình 7.

Tạo chuỗi siêu dữ liệu DSU đã xuất bản

Hình 7. Tạo chuỗi siêu dữ liệu DSU đã xuất bản