Phân vùng khởi động chung

Trong Android 12, hình ảnh boot chung, được gọi là Hình ảnh hạt nhân chung (GKI), chứa ramdisk chung và hạt nhân GKI.

Đối với các thiết bị chạy Android 13, ramdisk chung sẽ bị xoá khỏi hình ảnh boot và được đặt trong một hình ảnh init_boot riêng. Thay đổi này khiến hình ảnh boot chỉ có hạt nhân GKI.

Để nâng cấp các thiết bị tiếp tục sử dụng Android 12 hoặc các phiên bản nhân cũ hơn, ramdisk chung vẫn giữ nguyên vị trí mà không yêu cầu hình ảnh init_boot mới.

Để tạo một ramdisk chung, hãy di chuyển các tài nguyên dành riêng cho nhà cung cấp ra khỏi ramdisk sao cho ramdisk chung chỉ chứa init giai đoạn đầu tiên và một tệp thuộc tính chứa thông tin dấu thời gian.

Trên các thiết bị:

  • Không sử dụng phân vùng recovery chuyên dụng, tất cả các bit khôi phục sẽ di chuyển từ ramdisk chung sang ramdisk vendor_boot.

  • Hãy sử dụng một phân vùng recovery chuyên dụng, không cần thay đổi trong ramdisk recovery vì ramdisk recovery là độc lập.

Kiến trúc

Các biểu đồ sau đây minh hoạ cấu trúc cho các thiết bị chạy Android 12 trở lên. Thiết bị chạy Android 13 có hình ảnh init_boot mới chứa ramdisk chung. Các thiết bị nâng cấp từ Android 12 lên Android 13 sử dụng cùng một cấu trúc như khi nâng cấp lên Android 12.

Chạy bằng Android 13, không có tính năng khôi phục chuyên dụng

Khởi chạy/nâng cấp thiết bị, GKI, không có tính năng khôi phục chuyên dụng

Hình 1. Các thiết bị chạy hoặc nâng cấp lên Android 13, có GKI, không có tính năng khôi phục chuyên dụng.

Khởi chạy bằng Android 13, khôi phục A/B chuyên dụng và (đĩa RAM chuyên dụng)

Khởi chạy/nâng cấp thiết bị, GKI, khôi phục chuyên dụng và A/B

Hình 2. Các thiết bị khởi chạy hoặc nâng cấp lên Android 13, với GKI, chế độ khôi phục chuyên dụng và A/B.

Tham khảo hình này nếu thiết bị có phân vùng recovery_a và recovery_b.

Khởi chạy bằng Android 13, chế độ khôi phục chuyên dụng và không phải A/B (ramdisk chuyên dụng)

Khởi chạy/nâng cấp thiết bị, GKI, khôi phục chuyên dụng và không phải A/B

Hình 3. Thiết bị chạy hoặc nâng cấp lên Android 13 có GKI, tính năng khôi phục chuyên dụng và không áp dụng phương thức khôi phục A/B.

Hãy tham khảo hình này nếu thiết bị có một phân vùng có tên là recovery mà không có hậu tố khe cắm.

Khởi chạy hoặc nâng cấp lên Android 12 mà không cần khôi phục riêng

Khởi chạy/nâng cấp thiết bị, GKI, không có tính năng khôi phục chuyên dụng

Hình 4. Các thiết bị khởi chạy hoặc nâng cấp lên Android 12, với GKI, không có tính năng khôi phục chuyên dụng.

Khởi chạy hoặc nâng cấp lên Android 12, chế độ khôi phục A/B và chuyên dụng (ramdisk chuyên dụng)

Khởi chạy/nâng cấp thiết bị, GKI, khôi phục chuyên dụng và A/B

Hình 5. Các thiết bị khởi chạy hoặc nâng cấp lên Android 12, với GKI, chế độ khôi phục chuyên dụng và A/B.

Tham khảo hình này nếu thiết bị có các phân vùng recovery_a và recovery_b.

Chạy hoặc nâng cấp lên Android 12, khôi phục chuyên dụng và không phải A/B (ramdisk chuyên dụng)

Khởi chạy/nâng cấp thiết bị, GKI, khôi phục riêng và không áp dụng A/B

Hình 6. Thiết bị chạy hoặc nâng cấp lên Android 12 có GKI, tính năng khôi phục chuyên dụng và không áp dụng phương thức khôi phục A/B.

Tham khảo hình này nếu thiết bị có một phân vùng có tên là recovery mà không có hậu tố ô trống.

Nâng cấp lên Android 12, recovery-as-boot (recovery-as-ramdisk)

Chạy/nâng cấp thiết bị, không có GKI, khôi phục khi khởi động

Hình 7. Thiết bị nâng cấp lên Android 12, không có GKI, khôi phục khi khởi động.

Nâng cấp lên Android 12, khôi phục chuyên dụng (ramdisk chuyên dụng)

Chạy/nâng cấp thiết bị, không có GKI, khôi phục chuyên dụng

Hình 8. Các thiết bị nâng cấp lên Android 12, không có GKI, khôi phục chuyên dụng.

Nội dung hình ảnh khởi động

Hình ảnh khởi động Android chứa nội dung sau.

  • Thêm hình ảnh init_boot cho các thiết bị chạy Android 13

    • Phiên bản tiêu đề V4
    • Hình ảnh ổ đĩa ngẫu nhiên chung

  • Hình ảnh boot chung

    • Phiên bản tiêu đề V3 hoặc V4
      • boot_signature để chứng nhận boot.img GKI (chỉ dành cho phiên bản 4). boot.img GKI được chứng nhận chưa được ký để khởi động xác minh. Nhà sản xuất thiết bị gốc vẫn phải ký boot.img tạo sẵn bằng khoá AVB dành riêng cho thiết bị.
      • cmdline chung (GENERIC_KERNEL_CMDLINE)
      • Hạt nhân GKI
    • Hình ảnh ổ đĩa ngẫu nhiên chung
      • Chỉ có trong hình ảnh boot từ Android 12 trở xuống

  • Hình ảnh vendor_boot (để biết thông tin chi tiết, hãy xem phần Phân vùng khởi động dành cho nhà cung cấp)

    • Tiêu đề vendor_boot
      • cmdline dành riêng cho thiết bị (BOARD_KERNEL_CMDLINE)
    • Hình ảnh ổ đĩa RAM vendor_boot
      • lib/modules
      • Tài nguyên khôi phục (nếu không có tài nguyên khôi phục chuyên dụng)
    • Hình ảnh dtb

  • Hình ảnh recovery

    • Tiêu đề phiên bản V2
      • cmdline dành riêng cho thiết bị để khôi phục, nếu cần
      • Đối với phân vùng khôi phục không phải A/B, nội dung của tiêu đề phải độc lập; hãy xem Hình ảnh khôi phục. Ví dụ:
      • cmdline không được nối với boot và vendor_boot cmdline.
      • Tiêu đề chỉ định DTBO khôi phục, nếu cần.
      • Đối với phân vùng khôi phục A/B, nội dung có thể được nối hoặc suy luận từ boot và vendor_boot. Ví dụ:
      • cmdline được nối với boot và vendor_boot cmdline.
      • Bạn có thể suy ra DTBO từ tiêu đề vendor_boot.
    • Hình ảnh ổ đĩa ngẫu nhiên recovery
      • Tài nguyên khôi phục
      • Đối với phân vùng khôi phục không phải A/B, nội dung của ổ đĩa ram phải độc lập; hãy xem Hình ảnh khôi phục. Ví dụ:
      • lib/modules phải chứa tất cả các mô-đun hạt nhân cần thiết để khởi động chế độ khôi phục
      • Ramdisk khôi phục phải chứa init.
      • Đối với phân vùng khôi phục A/B, ổ đĩa ram khôi phục sẽ được thêm vào trước ramdisk chung và vendor_boot. Do đó, ổ đĩa này không cần phải độc lập. Ví dụ:
      • lib/modules có thể chỉ chứa các mô-đun hạt nhân bổ sung cần thiết để khởi động chế độ khôi phục, bên cạnh các mô-đun hạt nhân trong vendor_boot ramdisk.
      • Đường liên kết tượng trưng tại /init có thể tồn tại, nhưng bị tệp nhị phân /init ở giai đoạn đầu tiên lu mờ trong hình ảnh khởi động.

Nội dung hình ảnh ổ đĩa RAM chung

Ổ đĩa RAM thông thường chứa các thành phần sau.

  • init
  • system/etc/ramdisk/build.prop
  • Đạo cụ ro.PRODUCT.bootimg.* build
  • Thư mục trống cho các điểm gắn: debug_ramdisk/, mnt/, dev/, sys/, proc/, metadata/
  • first_stage_ramdisk/
    • Các thư mục trống trùng lặp cho các điểm gắn: debug_ramdisk/, mnt/, dev/, sys/, proc/, metadata/

Tích hợp hình ảnh khởi động

Cờ bản dựng kiểm soát cách tạo hình ảnh init_boot, boot, recovery và vendor_boot. Giá trị của biến bảng boolean phải là chuỗi true hoặc trống (là giá trị mặc định).

  • TARGET_NO_KERNEL. Biến này cho biết liệu bản dựng có sử dụng hình ảnh khởi động tạo sẵn hay không. Nếu biến này được đặt thành true, thì hãy đặt BOARD_PREBUILT_BOOTIMAGE thành vị trí của hình ảnh khởi động tạo sẵn (BOARD_PREBUILT_BOOTIMAGE:= device/${company}/${board}/boot.img)

  • BOARD_USES_RECOVERY_AS_BOOT. Biến này cho biết liệu thiết bị có sử dụng hình ảnh recovery làm hình ảnh boot hay không. Khi sử dụng GKI, biến này sẽ trống và tài nguyên khôi phục sẽ được chuyển sang vendor_boot.

  • BOARD_USES_GENERIC_KERNEL_IMAGE. Biến này cho biết rằng bo mạch sử dụng GKI. Biến này không ảnh hưởng đến sysprops hoặc PRODUCT_PACKAGES.

    Đây là nút chuyển GKI cấp bảng; tất cả các biến sau đây đều bị biến này hạn chế.

  • BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT. Biến này kiểm soát việc tài nguyên khôi phục ổ đĩa RAM có được tạo cho vendor_boot hay không.

    • Khi bạn đặt thành true, tài nguyên khôi phục chỉ được tạo thành vendor-ramdisk/ và không được tạo cho recovery/root/.

    • Khi trống, tài nguyên khôi phục chỉ được tạo cho recovery/root/ và không được tạo cho vendor-ramdisk/.

  • BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT. Biến này kiểm soát việc khoá AVB của GSI có được tạo vào vendor_boot hay không.

    • Khi được đặt thành true, nếu BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT:

      • Được đặt, khoá AVB GSI được tạo thành $ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/avb.

      • Bạn chưa đặt chính sách này, các khoá AVB của GSI được tích hợp vào $ANDROID_PRODUCT_OUT/vendor-ramdisk/avb.

    • Khi trống, nếu BOARD_RECOVERY_AS_ROOT:

      • Được đặt, khoá AVB GSI được tạo thành $ANDROID_PRODUCT_OUT/recovery/root/first_stage_ramdisk/avb.

      • Không được đặt, khoá AVB GSI được tạo thành $ANDROID_PRODUCT_OUT/ramdisk/avb.

  • BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE. Biến này kiểm soát việc hình ảnh recovery có chứa hạt nhân hay không. Các thiết bị chạy Android 12 và sử dụng phân vùng recovery A/B phải đặt biến này thành true. Các thiết bị chạy Android 12 và sử dụng biến không phải A/B phải đặt biến này thành false để giữ hình ảnh khôi phục độc lập.

  • BOARD_COPY_BOOT_IMAGE_TO_TARGET_FILES. Biến này kiểm soát việc $OUT/boot*.img có được sao chép vào IMAGES/ trong các tệp đích hay không.

    • aosp_arm64 phải đặt biến này thành true.

    • Các thiết bị khác phải để trống biến này.

  • BOARD_INIT_BOOT_IMAGE_PARTITION_SIZE. Biến này kiểm soát việc liệu init_boot.img có được tạo hay không và đặt kích thước. Khi đặt, ramdisk chung sẽ được thêm vào init_boot.img thay vì boot.img và yêu cầu phải đặt các biến BOARD_AVB_INIT_BOOT* cho vbmeta theo chuỗi.

Các tổ hợp được phép

Thành phần hoặc biến Nâng cấp thiết bị mà không có phân vùng khôi phục Nâng cấp thiết bị bằng phân vùng khôi phục Khởi động thiết bị mà không cần phân vùng khôi phục Khởi chạy thiết bị bằng phân vùng khôi phục A/B Khởi chạy thiết bị có phân vùng khôi phục không phải A/B aosp_arm64
Có chứa boot có có có có có có
Chứa init_boot (Android 13) không không có có có có
Có chứa vendor_boot tùy chọn tùy chọn có có có không
Có chứa recovery không có không có có không
BOARD_USES_RECOVERY_AS_BOOT true trống trống trống trống trống
BOARD_USES_GENERIC_KERNEL_IMAGE trống trống true true true true
PRODUCT_BUILD_RECOVERY_IMAGE trống true hoặc trống trống true hoặc trống true hoặc trống trống
BOARD_RECOVERYIMAGE_PARTITION_SIZE trống > 0 trống > 0 > 0 trống
BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT trống trống true trống trống trống
BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT trống trống true true true trống
BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE trống trống trống true trống trống
BOARD_COPY_BOOT_IMAGE_TO_TARGET_FILES trống trống trống trống trống true

Các thiết bị có phân vùng recovery chuyên dụng có thể đặt PRODUCT_BUILD_RECOVERY_IMAGE thành true hoặc để trống. Đối với những thiết bị này, nếu bạn đặt BOARD_RECOVERYIMAGE_PARTITION_SIZE, thì hình ảnh recovery sẽ được tạo.

Bật vbmeta theo chuỗi cho quá trình khởi động

Bạn phải bật vbmeta theo chuỗi cho hình ảnh boot và init_boot. Hãy chỉ định những thông tin sau:

BOARD_AVB_BOOT_KEY_PATH := external/avb/test/data/testkey_rsa4096.pem
BOARD_AVB_BOOT_ALGORITHM := SHA256_RSA4096
BOARD_AVB_BOOT_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP)
BOARD_AVB_BOOT_ROLLBACK_INDEX_LOCATION := 2

BOARD_AVB_INIT_BOOT_KEY_PATH := external/avb/test/data/testkey_rsa2048.pem
BOARD_AVB_INIT_BOOT_ALGORITHM := SHA256_RSA2048
BOARD_AVB_INIT_BOOT_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP)
BOARD_AVB_INIT_BOOT_ROLLBACK_INDEX_LOCATION := 3

Ví dụ: hãy tham khảo thay đổi này.

Hệ thống dưới dạng gốc

Hệ thống dưới dạng thư mục gốc không được hỗ trợ cho các thiết bị sử dụng GKI. Trên các thiết bị như vậy, BOARD_BUILD_SYSTEM_ROOT_IMAGE phải trống. Hệ thống dưới dạng gốc cũng không được hỗ trợ cho các thiết bị sử dụng phân vùng động.

Cấu hình sản phẩm

Các thiết bị sử dụng ramdisk chung phải cài đặt danh sách các tệp được phép cài đặt vào ramdisk. Để thực hiện việc này, hãy chỉ định nội dung sau trong device.mk:

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

Tệp generic_ramdisk.mk cũng ngăn các tệp makefile khác vô tình cài đặt các tệp khác vào ramdisk (thay vào đó, hãy di chuyển các tệp đó sang vendor_ramdisk).

Thiết lập thiết bị

Hướng dẫn thiết lập sẽ khác nhau giữa các thiết bị chạy Android 13, nâng cấp lên Android 12 và chạy Android 12. Android 13 có thiết lập tương tự như Android 12

  • Thiết bị nâng cấp lên Android 12:

    • Có thể giữ nguyên giá trị của BOARD_USES_RECOVERY_AS_BOOT. Nếu làm như vậy, thì các biến này sẽ sử dụng cấu hình cũ và các biến bản dựng mới phải trống. Nếu các thiết bị đó:

      • Đặt BOARD_USES_RECOVERY_AS_BOOT thành true, cấu trúc sẽ như trong Hình 3.

      • Đặt BOARD_USES_RECOVERY_AS_BOOT thành trống, cấu trúc sẽ như trong Hình 4.

    • Có thể đặt BOARD_USES_RECOVERY_AS_BOOT thành trống. Nếu có, thì các ứng dụng đó đang sử dụng cấu hình mới. Nếu các thiết bị đó:

      • Không sử dụng phân vùng recovery chuyên dụng, cấu trúc như minh hoạ trong Hình 1 và tuỳ chọn thiết lập thiết bị là Tuỳ chọn 1.

      • Sử dụng một phân vùng recovery chuyên dụng, cấu trúc như minh hoạ trong Hình 2a hoặc Hình 2b và tuỳ chọn thiết lập thiết bị là Tuỳ chọn 2a hoặc Tuỳ chọn 2b.

  • Các thiết bị chạy Android 12 phải đặt BOARD_USES_RECOVERY_AS_BOOT thành trống và sử dụng cấu hình mới. Nếu các thiết bị đó:

    • Không sử dụng phân vùng recovery chuyên dụng, cấu trúc như trong Hình 1 và tuỳ chọn thiết lập thiết bị là Tuỳ chọn 1.

    • Sử dụng một phân vùng recovery chuyên dụng, cấu trúc như minh hoạ trong Hình 2a hoặc Hình 2b và tuỳ chọn thiết lập thiết bị là Tuỳ chọn 2a hoặc Tuỳ chọn 2b.

Vì aosp_arm64 chỉ tạo GKI (chứ không phải vendor_boot hoặc khôi phục), nên đây không phải là một mục tiêu hoàn chỉnh. Đối với aosp_arm64cấu hình bản dựng, hãy tham khảo generic_arm64.

Tuỳ chọn 1: Không có phân vùng khôi phục chuyên dụng

Các thiết bị không có phân vùng recovery chứa hình ảnh boot chung trong phân vùng boot. Ramdisk vendor_boot chứa tất cả tài nguyên khôi phục, bao gồm cả lib/modules (với các mô-đun hạt nhân của nhà cung cấp). Trên các thiết bị như vậy, cấu hình sản phẩm kế thừa từ generic_ramdisk.mk.

Đặt giá trị BOARD

Đặt các giá trị sau:

BOARD_USES_RECOVERY_AS_BOOT :=
BOARD_USES_GENERIC_KERNEL_IMAGE := true
BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT := true
BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE :=
BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT := true

Ramdisk vendor_boot có thể chứa đường liên kết tượng trưng /init đến /system/bin/init và init_second_stage.recovery tại /system/bin/init. Tuy nhiên, vì ramdisk chung được nối sau ramdisk vendor_boot, nên đường liên kết tượng trưng của /init sẽ bị ghi đè. Khi thiết bị khởi động vào chế độ khôi phục, tệp nhị phân /system/bin/init là cần thiết để hỗ trợ khởi động giai đoạn thứ hai. Nội dung của vendor_boot + ổ đĩa ram chung như sau:

  • /init (từ ramdisk chung, được tạo từ init_first_stage)
  • /system/bin/init (từ vendor_ramdisk, được tạo từ init_second_stage.recovery)

Di chuyển tệp fstab

Di chuyển mọi tệp fstab đã cài đặt vào ramdisk chung sang vendor_ramdisk. Ví dụ: hãy tham khảo thay đổi này.

Cài đặt mô-đun

Bạn có thể cài đặt các mô-đun dành riêng cho thiết bị vào vendor_ramdisk (bỏ qua bước này nếu bạn không có bất kỳ mô-đun dành riêng cho thiết bị nào để cài đặt).

  • Sử dụng biến thể vendor_ramdisk của mô-đun khi mô-đun cài đặt vào /first_stage_ramdisk. Mô-đun này sẽ có sẵn sau khi init chuyển đổi thư mục gốc thành /first_stage_ramdisk nhưng trước khi init chuyển đổi thư mục gốc thành /system. Để biết ví dụ, hãy xem phần Checksum siêu dữ liệu và Nén A/B ảo.

  • Sử dụng biến thể recovery của mô-đun khi mô-đun cài đặt vào /. Mô-đun này sẽ có sẵn trước khi init chuyển sang thư mục gốc thành /first_stage_ramdisk. Để biết thông tin chi tiết về cách cài đặt mô-đun vào /, hãy xem Bảng điều khiển giai đoạn đầu tiên.

Bảng điều khiển giai đoạn đầu

Vì bảng điều khiển giai đoạn đầu khởi động trước khi init chuyển đổi thư mục gốc thành /first_stage_ramdisk, nên bạn cần cài đặt biến thể recovery của các mô-đun. Theo mặc định, cả hai biến thể mô-đun đều được cài đặt vào build/make/target/product/base_vendor.mk, vì vậy, nếu tệp makefile của thiết bị kế thừa từ tệp đó, bạn không cần cài đặt rõ ràng biến thể recovery.

Để cài đặt các mô-đun khôi phục một cách rõ ràng, hãy sử dụng mã sau.

PRODUCT_PACKAGES += \
    linker.recovery \
    shell_and_utilities_recovery \

Điều này đảm bảo rằng linker, sh và toybox cài đặt vào $ANDROID_PRODUCT_OUT/recovery/root/system/bin, sau đó cài đặt vào /system/bin trong vendor_ramdisk.

Để thêm các mô-đun cần thiết cho bảng điều khiển giai đoạn đầu (ví dụ: adbd), hãy sử dụng nội dung sau.

PRODUCT_PACKAGES += adbd.recovery

Điều này đảm bảo rằng các mô-đun được chỉ định sẽ cài đặt vào $ANDROID_PRODUCT_OUT/recovery/root/system/bin, sau đó cài đặt vào /system/bin trong vendor_ramdisk.

Giá trị tổng kiểm siêu dữ liệu

Để hỗ trợ giá trị tổng kiểm siêu dữ liệu trong quá trình liên kết giai đoạn đầu, các thiết bị không hỗ trợ GKI sẽ cài đặt biến thể ramdisk của các mô-đun sau. Để thêm tính năng hỗ trợ cho GKI, hãy di chuyển các mô-đun sang $ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/system/bin:

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    resize2fs.vendor_ramdisk \
    tune2fs.vendor_ramdisk \

Ví dụ: hãy tham khảo danh sách thay đổi này.

Nén A/B ảo

Để hỗ trợ tính năng nén A/B ảo, bạn phải cài đặt snapuserd vào vendor_ramdisk. Thiết bị phải kế thừa từ virtual_ab_ota/compression.mk, cài đặt biến thể vendor_ramdisk của snapuserd.

Thay đổi đối với quy trình khởi động

Quá trình khởi động vào quy trình khôi phục hoặc khởi động vào Android không thay đổi, ngoại trừ trường hợp sau:

  • Ramdisk build.prop di chuyển vào /second_stage_resources để init giai đoạn thứ hai có thể đọc dấu thời gian bản dựng của quá trình khởi động.

Vì tài nguyên di chuyển từ ramdisk chung sang ramdisk vendor_boot, nên kết quả của việc nối ramdisk chung với ramdisk vendor_boot sẽ không thay đổi.

Cung cấp e2fsck

Tệp makefile của thiết bị có thể kế thừa từ:

  • virtual_ab_ota/launch_with_vendor_ramdisk.mk nếu thiết bị hỗ trợ A/B ảo nhưng không hỗ trợ nén.

  • virtual_ab_ota/compression.mk nếu thiết bị hỗ trợ tính năng nén A/B ảo.

Tệp makefile của sản phẩm sẽ cài đặt $ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/system/bin/e2fsck. Trong thời gian chạy, giai đoạn đầu tiên init chuyển thư mục gốc thành /first_stage_ramdisk, sau đó thực thi /system/bin/e2fsck.

Tuỳ chọn 2a: Phân vùng khôi phục chuyên dụng và A/B

Sử dụng tuỳ chọn này cho các thiết bị có phân vùng recovery A/B; tức là thiết bị có recovery_a và recovery_b partition. Các thiết bị đó bao gồm thiết bị A/B và thiết bị A/B ảo có thể cập nhật phân vùng khôi phục, với cấu hình sau:

AB_OTA_PARTITIONS += recovery

Ramdisk vendor_boot chứa các bit của nhà cung cấp của ramdisk và các mô-đun hạt nhân của nhà cung cấp, bao gồm:

  • Tệp fstab dành riêng cho thiết bị

  • lib/modules (bao gồm các mô-đun nhân của nhà cung cấp)

Ổ đĩa RAM recovery chứa tất cả tài nguyên khôi phục. Trên các thiết bị như vậy, cấu hình sản phẩm kế thừa từ generic_ramdisk.mk.

Đặt giá trị BOARD

Đặt các giá trị sau cho thiết bị có phân vùng A/B recovery:

BOARD_USES_RECOVERY_AS_BOOT :=
BOARD_USES_GENERIC_KERNEL_IMAGE := true
BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT :=
BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE := true
BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT := true

Ổ đĩa ram recovery có thể chứa một đường liên kết tượng trưng /init -> /system/bin/init và init_second_stage.recovery tại /system/bin/init. Tuy nhiên, vì ổ đĩa RAM khởi động được nối sau ổ đĩa RAM recovery, nên đường liên kết tượng trưng /init sẽ bị ghi đè. Khi thiết bị khởi động vào chế độ khôi phục, tệp nhị phân /system/bin/init là cần thiết để hỗ trợ khởi động giai đoạn thứ hai.

Khi thiết bị khởi động vào recovery, nội dung của recovery + vendor_boot + ramdisk chung sẽ như sau:

  • /init (từ ramdisk, được tạo từ init_first_stage)
  • /system/bin/init (từ recovery ramdisk, được tạo từ init_second_stage.recovery và thực thi từ /init)

Khi thiết bị khởi động vào Android, nội dung của vendor_boot + ổ đĩa RAM chung sẽ như sau:

  • /init (từ ramdisk chung, được tạo từ init_first_stage)

Di chuyển tệp fstab

Di chuyển mọi tệp fstab đã cài đặt vào ổ đĩa ram chung sang vendor_ramdisk. Ví dụ: hãy tham khảo thay đổi này.

Cài đặt mô-đun

Bạn có thể cài đặt các mô-đun dành riêng cho thiết bị vào vendor_ramdisk (bỏ qua bước này nếu bạn không có mô-đun nào dành riêng cho thiết bị để cài đặt). Init không chuyển đổi cấp độ gốc. Biến thể vendor_ramdisk của các mô-đun sẽ cài đặt vào thư mục gốc của vendor_ramdisk. Để biết ví dụ về cách cài đặt mô-đun vào vendor_ramdisk, hãy xem Bảng điều khiển giai đoạn đầu, Checksum siêu dữ liệu và Nén A/B ảo.

Bảng điều khiển giai đoạn đầu

Để cài đặt biến thể vendor_ramdisk của các mô-đun, hãy sử dụng nội dung sau:

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    shell_and_utilities_vendor_ramdisk \

Điều này đảm bảo rằng linker, sh và toybox cài đặt vào $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin, sau đó cài đặt vào /system/bin trong vendor_ramdisk.

Để thêm các mô-đun cần thiết cho bảng điều khiển giai đoạn đầu (ví dụ: adbd), hãy bật biến thể vendor_ramdisk của các mô-đun này bằng cách tải các bản vá có liên quan lên AOSP, sau đó sử dụng các lệnh sau,

PRODUCT_PACKAGES += adbd.vendor_ramdisk

Điều này đảm bảo rằng các mô-đun được chỉ định sẽ cài đặt vào $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin. Nếu ramdisk vendor_boot được tải ở chế độ khôi phục, thì mô-đun này cũng có trong recovery. Nếu vendor_boot ramdisk không được tải ở chế độ khôi phục, thì thiết bị cũng có thể cài đặt adbd.recovery.

Checksum siêu dữ liệu

Để hỗ trợ tổng kiểm siêu dữ liệu trong quá trình gắn giai đoạn đầu tiên, các thiết bị không hỗ trợ GKI sẽ cài đặt biến thể ramdisk của các mô-đun sau. Để thêm tính năng hỗ trợ cho GKI, hãy di chuyển các mô-đun sang $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin:

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    resize2fs.vendor_ramdisk \
    tune2fs.vendor_ramdisk \

Ví dụ: hãy tham khảo danh sách thay đổi này.

Nén A/B ảo

Để hỗ trợ tính năng nén A/B ảo, bạn phải cài đặt snapuserd vào vendor_ramdisk. Thiết bị phải kế thừa từ virtual_ab_ota/compression.mk, cài đặt biến thể vendor_ramdisk của snapuserd.

Thay đổi đối với quy trình khởi động

Khi khởi động vào Android, quy trình khởi động sẽ không thay đổi. vendor_boot + ramdisk chung tương tự như quy trình khởi động hiện có, ngoại trừ việc fstab tải từ vendor_boot. Vì system/bin/recovery không tồn tại, nên first_stage_init sẽ xử lý việc này như một quá trình khởi động thông thường.

Khi khởi động vào chế độ khôi phục, quy trình khởi động sẽ thay đổi. Quá trình khôi phục + vendor_boot + ramdisk chung tương tự như quy trình khôi phục hiện có, nhưng nhân được tải từ hình ảnh boot thay vì từ hình ảnh recovery. Quy trình khởi động cho chế độ khôi phục như sau.

  1. Trình tải khởi động khởi động, sau đó thực hiện những việc sau:

    1. Đẩy tính năng khôi phục + vendor_boot + ramdisk chung vào /. (Nếu OEM sao chép các mô-đun hạt nhân trong ramdisk khôi phục bằng cách thêm các mô-đun đó vào BOARD_RECOVERY_KERNEL_MODULES), thì vendor_boot là không bắt buộc.)
    2. Chạy hạt nhân từ phân vùng boot.

  2. Hạt nhân sẽ gắn ramdisk vào /, sau đó thực thi /init từ ramdisk chung.

  3. Giai đoạn khởi chạy đầu tiên bắt đầu, sau đó thực hiện các bước sau:

    1. Đặt IsRecoveryMode() == true và ForceNormalBoot() == false.
    2. Tải các mô-đun hạt nhân của nhà cung cấp từ /lib/modules.
    3. Gọi DoFirstStageMount() nhưng bỏ qua việc gắn vì IsRecoveryMode() == true. (Thiết bị không giải phóng ramdisk (vì / vẫn giống như trước) nhưng gọi SetInitAvbVersionInRecovery().)
    4. Bắt đầu khởi chạy giai đoạn thứ hai từ /system/bin/init từ recovery ramdisk.

Cung cấp e2fsck

Tệp makefile của thiết bị có thể kế thừa từ:

  • virtual_ab_ota/launch_with_vendor_ramdisk.mk nếu thiết bị hỗ trợ A/B ảo nhưng không hỗ trợ nén.

  • virtual_ab_ota/compression.mk nếu thiết bị hỗ trợ nén A/B ảo.

Tệp makefile của sản phẩm sẽ cài đặt $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin/e2fsck. Tại thời gian chạy, giai đoạn đầu tiên init sẽ thực thi /system/bin/e2fsck.

Lựa chọn 2b: Phân vùng khôi phục chuyên dụng và không phải A/B

Sử dụng tuỳ chọn này cho các thiết bị có phân vùng recovery không phải A/B; tức là thiết bị có phân vùng tên là recovery không có hậu tố khe. Các thiết bị như vậy bao gồm:

  • thiết bị không phải A/B;
  • Các thiết bị A/B và A/B ảo, trong đó phân vùng khôi phục không thể cập nhật. (Đây là điều bất thường.)

ramdisk vendor_boot chứa các bit của nhà cung cấp của ramdisk và các mô-đun nhân của nhà cung cấp, bao gồm:

  • Tệp fstab dành riêng cho thiết bị
  • lib/modules (bao gồm các mô-đun nhân của nhà cung cấp)

Hình ảnh recovery phải tự chứa. Tệp này phải chứa tất cả tài nguyên bắt buộc để khởi động chế độ khôi phục, bao gồm:

  • Hình ảnh nhân hệ điều hành
  • Hình ảnh DTBO
  • Mô-đun nhân trong lib/modules
  • Bắt đầu giai đoạn đầu dưới dạng một đường liên kết tượng trưng /init -> /system/bin/init
  • Tệp nhị phân khởi động giai đoạn hai /system/bin/init
  • Tệp fstab dành riêng cho thiết bị
  • Tất cả tài nguyên khôi phục khác, bao gồm cả tệp nhị phân recovery

Trên các thiết bị như vậy, cấu hình sản phẩm kế thừa từ generic_ramdisk.mk.

Đặt giá trị BẢNG

Đặt các giá trị sau cho thiết bị không phải A/B:

BOARD_USES_RECOVERY_AS_BOOT :=
BOARD_USES_GENERIC_KERNEL_IMAGE := true
BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT :=
BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE :=
BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT := true

recovery ramdisk phải chứa một đường liên kết tượng trưng /init -> /system/bin/init và init_second_stage.recovery tại /system/bin/init. Khi thiết bị khởi động vào chế độ khôi phục, tệp nhị phân /system/bin/init là cần thiết để hỗ trợ cả giai đoạn khởi động đầu tiên và giai đoạn khởi động thứ hai.

Khi thiết bị khởi động vào recovery, nội dung của recovery ramdisk sẽ như sau:

  • /init -> /system/bin/init (từ recovery ổ đĩa RAM)
  • /system/bin/init (từ ramdisk recovery, tạo từ init_second_stage.recovery và được thực thi từ /init)

Khi thiết bị khởi động vào Android, nội dung của vendor_boot + các ổ đĩa RAM chung sẽ như sau:

  • /init (từ ramdisk, được tạo từ init_first_stage)

Di chuyển tệp fstab

Di chuyển mọi tệp fstab đã cài đặt vào ramdisk chung sang vendor_ramdisk và ramdisk recovery. Ví dụ: hãy tham khảo thay đổi này.

Cài đặt mô-đun

Bạn có thể cài đặt các mô-đun dành riêng cho thiết bị vào vendor_ramdisk và recovery ramdisk (bỏ qua bước này nếu bạn không có mô-đun dành riêng cho thiết bị nào để cài đặt). init không chuyển đổi thư mục gốc. Biến thể vendor_ramdisk của các mô-đun sẽ cài đặt vào thư mục gốc của vendor_ramdisk. Biến thể recovery của các mô-đun sẽ cài đặt vào thư mục gốc của recovery ramdisk. Để biết ví dụ về cách cài đặt mô-đun vào vendor_ramdisk và recovery ramdisk, hãy xem Bảng điều khiển giai đoạn đầu và Checksum siêu dữ liệu.

Bảng điều khiển giai đoạn một

Để cài đặt biến thể vendor_ramdisk của các mô-đun, hãy sử dụng nội dung sau:

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    shell_and_utilities_vendor_ramdisk \

Điều này đảm bảo rằng linker, sh và toybox cài đặt vào $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin, sau đó cài đặt vào /system/bin trong vendor_ramdisk.

Để thêm các mô-đun cần thiết cho bảng điều khiển giai đoạn đầu (ví dụ: adbd), hãy bật biến thể vendor_ramdisk của các mô-đun này bằng cách tải các bản vá có liên quan lên AOSP, sau đó sử dụng các lệnh sau,

PRODUCT_PACKAGES += adbd.vendor_ramdisk

Điều này đảm bảo rằng các mô-đun được chỉ định sẽ cài đặt vào $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin.

Để cài đặt biến thể recovery của các mô-đun, hãy thay thế vendor_ramdisk bằng recovery:

PRODUCT_PACKAGES += \
    linker.recovery \
    shell_and_utilities_recovery \
    adbd.recovery \

Checksum siêu dữ liệu

Để hỗ trợ tổng kiểm siêu dữ liệu trong quá trình gắn giai đoạn đầu tiên, các thiết bị không hỗ trợ GKI sẽ cài đặt biến thể ramdisk của các mô-đun sau. Để thêm tính năng hỗ trợ cho GKI, hãy di chuyển các mô-đun sang $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin:

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    resize2fs.vendor_ramdisk \
    tune2fs.vendor_ramdisk \

Để hỗ trợ tổng kiểm siêu dữ liệu trong quá trình gắn ở giai đoạn đầu trong quá trình khôi phục, hãy bật biến thể khôi phục của các mô-đun này và cài đặt các mô-đun đó.

Thay đổi đối với quy trình khởi động

Khi khởi động vào Android, quy trình khởi động sẽ không thay đổi. vendor_boot + ramdisk chung tương tự như quy trình khởi động hiện có, ngoại trừ việc fstab tải từ vendor_boot. Vì system/bin/recovery không tồn tại, nên first_stage_init sẽ xử lý như một quá trình khởi động bình thường.

Khi khởi động vào chế độ khôi phục, quá trình khởi động sẽ không thay đổi. Ổ đĩa khôi phục được tải theo cách tương tự như quy trình khôi phục hiện tại. Hạt nhân được tải từ hình ảnh recovery. Quy trình khởi động cho chế độ khôi phục như sau.

  1. Trình tải khởi động khởi động, sau đó thực hiện những việc sau:

    1. Đẩy ổ đĩa khôi phục tới /.
    2. Chạy hạt nhân từ phân vùng recovery.

  2. Hạt nhân sẽ gắn ramdisk vào /, sau đó thực thi /init, đây là một đường liên kết tượng trưng đến /system/bin/init từ ramdisk recovery.

  3. Quá trình bắt đầu giai đoạn đầu tiên bắt đầu, sau đó thực hiện những việc sau:

    1. Đặt IsRecoveryMode() == true và ForceNormalBoot() == false.
    2. Tải các mô-đun hạt nhân của nhà cung cấp từ /lib/modules.
    3. Gọi DoFirstStageMount() nhưng bỏ qua việc gắn vì IsRecoveryMode() == true. (Thiết bị không giải phóng ramdisk (vì / vẫn giống như trước) nhưng gọi SetInitAvbVersionInRecovery().)
    4. Bắt đầu khởi chạy giai đoạn thứ hai từ /system/bin/init từ recovery ramdisk.

Dấu thời gian của hình ảnh khởi động

Mã sau đây là ví dụ về tệp dấu thời gian hình ảnh boot:

####################################
# from generate-common-build-props
# These properties identify this partition image.
####################################
ro.product.bootimage.brand=Android
ro.product.bootimage.device=generic_arm64
ro.product.bootimage.manufacturer=unknown
ro.product.bootimage.model=AOSP on ARM64
ro.product.bootimage.name=aosp_arm64
ro.bootimage.build.date=Mon Nov 16 22:46:27 UTC 2020
ro.bootimage.build.date.utc=1605566787
ro.bootimage.build.fingerprint=Android/aosp_arm64/generic_arm64:S/MASTER/6976199:userdebug/test-keys
ro.bootimage.build.id=MASTER
ro.bootimage.build.tags=test-keys
ro.bootimage.build.type=userdebug
ro.bootimage.build.version.incremental=6976199
ro.bootimage.build.version.release=11
ro.bootimage.build.version.release_or_codename=S
ro.bootimage.build.version.sdk=30
# Auto-added by post_process_props.py
persist.sys.usb.config=none
# end of file

  • Trong thời gian xây dựng, tệp system/etc/ramdisk/build.prop sẽ được thêm vào ổ đĩa RAM chung. Tệp này chứa thông tin về dấu thời gian của bản dựng.

  • Trong thời gian chạy, giai đoạn đầu tiên init sao chép các tệp từ ramdisk sang tmpfs trước khi giải phóng ramdisk để giai đoạn thứ hai init có thể đọc tệp này nhằm đặt các thuộc tính dấu thời gian hình ảnh boot.