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

Sử dụng bộ sưu tập để sắp xếp ngăn nắp các trang Lưu và phân loại nội dung dựa trên lựa chọn ưu tiên của bạn.

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 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.

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 một quy trình UserspaceRebootWatchdogThread() riêng để 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ơ 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 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 gắn và chờ các quy trình đó dừng.
   2. Sau khi hết thời gian chờ, hãy gửi SIGKILL để chấm dứt 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 thao tác 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 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, 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ợ:

• Kiểm tra điểm 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 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 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 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.
• Không dừng được một quy trình trong 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 tháo 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 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ột cách nhẹ nhàng. 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 được trong thời gian chờ đã cho, thì hệ thống sẽ kích hoạt phương án dự phòng là khởi động lại hoàn toàn.
• 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 lại mềm (tức là sys.init.userspace_reboot.in_progress=1). Nếu một thiết bị không khởi động lại mềm trong thời gian chờ đã cho, thì quá trình dự phòng để 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 một thiết bị không thể 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 hoàn toàn.
• 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ì tính năng dự phòng để khởi động lại hoàn toàn 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 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 không chỉ định tệp ảnh động cụ thể cho quá trình khởi động lại mềm, 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.