Khởi động lại mềm (<= AOSP 14)

Android 11 hỗ trợ khởi động lại mềm, tức là khởi động lại các quy trình trong thời gian chạy trong không gian người dùng dùng để áp dụng các bản cập nhật yêu cầu khởi động lại (ví dụ: bản cập nhật cho các gói APEX). Hiện tại, tính năng khởi động lại mềm chỉ giới hạn ở các quy trình bắt đầu sau khi userdata được gắn.

Bạn có thể yêu cầu khởi động lại mềm theo các cách sau:

  • Từ PowerManager, bằng cách gọi PowerManager.reboot(PowerManager.REBOOT_USERSPACE)

  • Từ shell, sử dụng adb shell svc power reboot userspace hoặc adb reboot userspace

Sau khi khởi động lại mềm, bộ nhớ được mã hoá dành cho thông tin đăng nhập vẫn được mở khoá.

Nếu thiết bị hỗ trợ khởi động lại mềm, thì phương thức API PowerManager.isRebootingUserspace() sẽ trả về true và giá trị của thuộc tính hệ thống init.userspace_reboot.is_supported sẽ bằng 1.

Nếu thiết bị không hỗ trợ khởi động lại mềm, thì các lệnh gọi đến PowerManager.reboot(PowerManager.REBOOT_USERSPACE), adb reboot userspace và adb shell svc power reboot userspace sẽ không thành công.

Quá trình thực thi khởi động lại mềm

Sau khi yêu cầu khởi động lại mềm (thông qua PowerManager hoặc từ một shell), init sẽ thực hiện các bước sau:

  1. Nhận sys.powerctl=reboot,userspace.

  2. Phát triển nhánh một quy trình UserspaceRebootWatchdogThread() riêng biệt để theo dõi quá trình khởi động lại mềm.

  3. Kích hoạt một thao tác userspace-reboot-requested, thao tác này sẽ đặt lại tất cả các thuộc tính hệ thống có thể ảnh hưởng đến quá trình khởi động lại mềm. Các cơ sở lưu trú chịu ảnh hưởng:

    • sys.usb.config
    • sys.usb.state
    • sys.boot_completed
    • dev.bootcomplete
    • sys.init.updatable_crashing
    • sys.init.updatable_crashing_process_name
    • apexd.status
    • sys.user.0.ce_available
    • sys.shutdown.requested
    • service.bootanim.exit

    Bạn phải thiết lập lại các thuộc tính trên trong trình tự khởi động. Nếu cần, bạn có thể đặt lại các thuộc tính bổ sung. Để biết ví dụ, hãy tham khảo thao tác on userspace-reboot-requested trong rootdir/init.rc.

  4. Chạy hàm DoUserspaceReboot. Hàm này thực hiện các thao tác sau:

    1. Gửi SIGTERM đến các quy trình bắt đầu sau khi userdata được kết nối và chờ dừng các quy trình đó.
    2. Sau khi hết thời gian chờ, gửi SIGKILL để loại bỏ mọi quy trình đang chạy.
    3. Gọi /system/bin/vdc volume reset.
    4. Ngắt kết nối thiết bị sao lưu zRAM.
    5. Huỷ gắn các gói APEX đang hoạt động.
    6. Chuyển về không gian tên gắn khởi động.
    7. Kích hoạt hành động userspace-reboot-resume.

Nếu bạn yêu cầu kiểm tra điểm hệ thống tệp trước khi khởi động lại mềm, thì userdata sẽ được gắn lại vào chế độ kiểm tra điểm trong thao tác userspace-reboot-fs-remount (xem phần sau để biết thông tin chi tiết). Hoạt động khởi động lại mềm sẽ được xem xét sau khi sys.boot_completed property được đặt thành 1. Khi quá trình khởi động lại mềm kết thúc, màn hình sẽ tắt và cần có sự tương tác rõ ràng của người dùng để đánh thức màn hình.

Kiểm tra điểm hệ thống tệp

Nếu bạn yêu cầu một điểm kiểm tra hệ thống tệp trước khi khởi động lại mềm, thì userdata sẽ được kết nối lại ở chế độ kiểm tra trong quá trình khởi động lại mềm. Logic gắn lại được triển khai trong hàm fs_mgr_remount_userdata_into_checkpointing và khác nhau giữa các phương thức kiểm tra điểm. Cụ thể, khi userdata hỗ trợ:

  • Chốt kiểm tra cấp hệ thống tệp (ví dụ: f2fs), userdata được gắn lại bằng tuỳ chọn checkpoint=disable.

  • Điểm kiểm tra cấp khối (ví dụ: ext4), sau đó /data sẽ bị tháo và tất cả các thiết bị ánh xạ thiết bị mẹ mà thiết bị này được gắn trên đó sẽ bị huỷ. Tiếp theo, userdata được gắn bằng cách sử dụng cùng một đường dẫn mã như được sử dụng trong quá trình khởi động kiểm tra điểm trung gian thông thường.

Nếu bạn sử dụng khoá chuỗi khoá cấp hệ thống tệp để quản lý khoá được mã hoá bằng thông tin xác thực (CE) và khoá được mã hoá bằng thiết bị (DE), thì các khoá sẽ bị mất sau khi userdata được tháo. Để cho phép khôi phục khoá, khi cài đặt khoá vào quy trình khoá hệ thống tệp, vold cũng cài đặt cùng một khoá thuộc loại fscrypt-provisioning vào quy trình khoá cấp phiên. Khi init_user0 được gọi, vold sẽ cài đặt lại các khoá trong khoá hệ thống tệp.

Dự phòng để khởi động lại hoàn toàn

Để đảm bảo rằng việc khởi động lại mềm không khiến thiết bị ở trạng thái không sử dụng được, Android 11 có tính năng dự phòng để khởi động lại hoàn toàn. Tính năng này được kích hoạt khi đáp ứng một trong các điều kiện sau:

  • Thiết bị không khởi động được quá trình khởi động lại mềm (tức là sys.init.userspace_reboot.in_progress=1) trong một khoảng thời gian chờ nhất định.
  • Một quá trình không thể dừng trong một khoảng thời gian chờ nhất định.
  • Thao tác /system/bin/vdc volume reset không thành công.
  • Không thể tháo thiết bị zRAM.
  • Gói APEX đang hoạt động ngắt kết nối không chính xác.
  • Không thể gắn lại userdata vào chế độ kiểm tra điểm.
  • Thiết bị không khởi động thành công (tức là sys.boot_completed=1) trong một khoảng thời gian chờ nhất định.

Cấu hình theo từng thiết bị

Bạn có thể điều chỉnh một số khía cạnh khởi động lại mềm bằng cách thay đổi giá trị của các thuộc tính sau:

  • init.userspace_reboot.is_supported kiểm soát thời điểm thiết bị có thể khởi động lại mềm. Nếu giá trị của thuộc tính này là false, 0 hoặc không được chỉ định, thì các lượt khởi động lại sẽ bị từ chối.
  • init.userspace_reboot.sigkill.timeoutmillis kiểm soát thời gian chờ tính bằng mili giây cho các quy trình đã nhận được tín hiệu SIGKILL để dừng. Nếu một trong các quy trình không dừng lại được trong thời gian chờ nhất định, thì quá trình khởi động lại dự phòng sẽ được kích hoạt.
  • init.userspace_reboot.sigterm.timeoutmillis kiểm soát thời gian chờ tính bằng mili giây cho các quy trình đã nhận được tín hiệu SIGTERM để chấm dứt. Tất cả các quy trình không thể chấm dứt trong thời gian chờ đã cho sẽ nhận được tín hiệu SIGKILL.
  • init.userspace_reboot.started.timeoutmillis kiểm soát thời gian chờ tính bằng mili giây để bắt đầu khởi động mềm (tức là sys.init.userspace_reboot.in_progress=1). Nếu thiết bị không bắt đầu khởi động lại mềm trong khoảng thời gian chờ nhất định, thì quá trình khởi động lại cứng sẽ được kích hoạt.
  • init.userspace_reboot.userdata_remount.timeoutmillis kiểm soát thời gian chờ tính bằng mili giây để tháo userdata. Nếu thiết bị không thể ngắt kết nối userdata trong khoảng thời gian chờ nhất định, thì thao tác dự phòng cho quá trình khởi động lại cứng sẽ được kích hoạt.
  • init.userspace_reboot.watchdog.timeoutmillis kiểm soát thời gian chờ để thiết bị khởi động thành công (tức là sys.boot_completed=1). Nếu thiết bị không khởi động được trong thời gian chờ đã cho, thì chế độ dự phòng sẽ được kích hoạt để khởi động lại hoàn toàn.

Tuỳ chỉnh ảnh động trong quá trình khởi động lại mềm

Quá trình triển khai tham chiếu của quá trình khởi động lại mềm bao gồm khả năng tuỳ chỉnh ảnh động hiển thị trong quá trình khởi động lại mềm.

Ở cuối thao tác userspace-reboot-fs-remount, init sẽ khởi động dịch vụ bootanim. Dịch vụ này tìm kiếm sự tồn tại của các tệp ảnh động sau đây, theo thứ tự được liệt kê và phát tệp đầu tiên tìm thấy:

  • /product/media/userspace-reboot.zip
  • /oem/media/userspace-reboot.zip
  • /system/media/userspace-reboot.zip
sau

Nếu bạn không chỉ định tệp ảnh động cụ thể nào trong quá trình khởi động lại, thì bootanim sẽ hiển thị ảnh động android mặc định.

Thử nghiệm

Android 11 bao gồm cách triển khai tham chiếu của một khởi động lại mềm. Ngoài ra, bạn có thể xác minh quá trình khởi động lại mềm bằng các bài kiểm thử CTS trong UserspaceRebootHostTest.