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

Android 11 hỗ trợ khởi động lại mềm. Đây là các quy trình khởi động lại thời gian chạy trong không gian người dùng được 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 ở những 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 những 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 ở trạng thái mở khoá.

Nếu một thiết bị hỗ trợ khởi động lại phần 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 phần 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.

Thực hiện 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â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 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 phần mềm. Cơ sở lưu trú bị ả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 cần đặt lại các thuộc tính nêu 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 gắn và đợi các quy trình đó dừng lại.
    2. Sau khi hết thời gian chờ, hãy gửi SIGKILL để huỷ mọi quy trình đang chạy.
    3. Cuộc gọi /system/bin/vdc volume reset.
    4. Huỷ gắn thiết bị hỗ trợ 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 kết khởi động.
    7. Kích hoạt thao tác userspace-reboot-resume.

Nếu bạn yêu cầu tạo điểm kiểm tra hệ thống tệp trước khi khởi động lại mềm, userdata sẽ được gắn lại vào chế độ tạo điểm kiểm tra trong thao tác userspace-reboot-fs-remount (xem phần sau để biết thông tin chi tiết). Quá trình khởi động lại mềm đượ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ẽ vẫn tắt và người dùng phải tương tác một cách rõ ràng để đánh thức màn hình.

Kiểm tra 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, userdata sẽ được gắn 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. Cụ thể, khi userdata hỗ trợ:

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

  • Kiểm tra điểm chặn cấp khối (ví dụ: ext4), sau đó /data sẽ được 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 lên trên sẽ bị huỷ. Tiếp theo, userdata được gắn bằng cùng một đường dẫn mã như được dùng trong quá trình khởi động kiểm tra điểm đánh dấu thông thường.

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

Quay lại chế độ khởi động lại bắt buộc

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

  • 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 quy trình không dừng trong thời gian chờ nhất định.
  • Thao tác /system/bin/vdc volume reset không thành công.
  • Không tháo được thiết bị zRAM.
  • Một gói APEX đang hoạt động bị huỷ gắn kết không đúng cách.
  • Không thể gắn lại userdata vào chế độ tạo điểm kiểm tra.
  • 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 cho từng thiết bị

Bạn có thể điều chỉnh một số khía cạnh của thao tác khởi động lại phần 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ể thực hiện thao tác 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ần thử 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 trong thời gian chờ đã cho, thì quá trình khởi động lại bắt buộc 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 đều 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 lại mềm (tức là sys.init.userspace_reboot.in_progress=1). Nếu thiết bị không khởi động lại mềm trong thời gian chờ đã cho, thì sẽ kích hoạt chế độ dự phòng là khởi động lại cứng.
  • init.userspace_reboot.userdata_remount.timeoutmillis kiểm soát thời gian chờ tính bằng mili giây để huỷ gắn userdata. Nếu một thiết bị không tháo userdata trong thời gian chờ đã cho, thì hệ thống sẽ kích hoạt chế độ dự phòng để khởi động lại thiết bị.
  • 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ì quá trình khôi phục về trạng thái ban đầu sẽ được kích hoạt.

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

Việc triển khai tham chiếu của một thao tác khởi động lại phần mềm bao gồm khả năng tuỳ chỉnh ảnh động xuất hiện trong quá trình khởi động lại phần mềm.

Khi kết thúc 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 hoạt ảnh sau (theo thứ tự được liệt kê) và phát tệp đầu tiên mà dịch vụ tìm thấy:

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

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

Thử nghiệm

Android 11 có một phương thức triển khai tham chiếu cho tính năng khởi động lại mềm. Ngoài ra, bạn có thể xác minh thao tác khởi động lại mềm bằng các kiểm thử CTS trong UserspaceRebootHostTest.