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

Android 11 hỗ trợ tính năng khởi động lại mềm. Đây là tính năng khởi động lại thời gian chạy của các quy trình 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ỉ áp dụng cho các quy trình bắt đầu sau khi userdata được gắn kết.

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, bằng cách 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 sẽ vẫn được mở khoá.

Nếu một thiết bị hỗ trợ tính năng 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ợ tính năng 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 tính năng 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ừ 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 riêng biệt UserspaceRebootWatchdogThread() để theo dõi quá trình khởi động lại mềm.

3. Kích hoạt hành động userspace-reboot-requested, hành động này sẽ đặt lại tất 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 thuộc tính 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 ở 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 khác. Để xem ví dụ, hãy tham khảo hành động on userspace-reboot-requested trong rootdir/init.rc.

4. Chạy hàm DoUserspaceReboot, hàm này sẽ thực hiện các hành động sau:

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

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, thì userdata sẽ được gắn kết lại vào chế độ tạo điểm kiểm tra trong hành động 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 kết thúc quá trình khởi động lại mềm, màn hình sẽ tắt và bạn cần tương tác rõ ràng với người dùng để bật màn hình.

Tạo điểm kiểm tra hệ thống tệp

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, thì userdata sẽ được gắn kết lại ở chế độ tạo điểm kiểm tra trong quá trình khởi động lại mềm. Logic gắn kết 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 tạo điểm kiểm tra. Cụ thể, khi userdata hỗ trợ:

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

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

Nếu bạn sử dụng 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à khoá được mã hoá bằng thiết bị (DE), thì các khoá sẽ bị mất sau khi userdata bị huỷ gắn kết. Để cho phép khôi phục khoá, khi cài đặt khoá vào chuỗi 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 chuỗi khoá ở cấp phiên. Khi init_user0 được gọi, vold sẽ cài đặt lại các khoá trong chuỗi khoá hệ thống tệp.

Dự phòng cho quá trình khởi động lại cứng

Để đảm bảo rằng quá trình 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 bao gồm tính năng dự phòng cho quá trình khởi động lại cứng. Tính năng này sẽ đượ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 quy trình không dừng được 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 huỷ gắn kết đượ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 gắn kết lại được 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 quá trì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ể thực hiện quá trình 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 được trong khoảng thời gian chờ nhất định, thì tính năng dự phòng cho quá trình khởi động lại cứ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 chấm dứt được trong khoảng thời gian chờ nhất định 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 quá trình 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 được quá trình khởi động lại mềm trong khoảng thời gian chờ nhất định, thì tính năng dự phòng cho 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 để huỷ gắn kết userdata. Nếu thiết bị không huỷ gắn kết được userdata trong khoảng thời gian chờ nhất định, thì tính năng 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 khoảng thời gian chờ nhất định, thì tính năng dự phòng cho quá trình khởi động lại cứng 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 quá trình khởi động lại 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 mềm.

Khi kết thúc hành động userspace-reboot-fs-remount, init sẽ khởi động dịch vụ bootanim. Dịch vụ này sẽ tìm sự tồn tại của các tệp ảnh động sau theo thứ tự được liệt kê và phát tệp đầu tiên mà dịch vụ này 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 ảnh động cụ thể cho quá trình khởi động lại mềm, thì bootanim sẽ hiển thị ảnh động android mặc định.

Thử nghiệm

Android 11 bao gồm một cách triển khai tham chiếu quá trình 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.