Android 11은 조용히 다시 시작 기능을 지원합니다. 조용히 다시 시작 기능은 재부팅이 필요한 업데이트(예: APEX 패키지 업데이트)를 적용하는 데 사용되는 사용자 공간에서 프로세스가 런타임 재시작하는 것을 말합니다. 현재 조용히 다시 시작은 userdata가 마운트된 이후에 시작된 프로세스로 제한됩니다.
조용히 다시 시작 전에 파일 시스템 체크포인트가 요청되었다면 userspace-reboot-fs-remount 작업 중에 userdata가 체크포인트 모드로 다시 마운트됩니다(세부정보는 다음 섹션 참고). sys.boot_completed property가 1로 설정되면 조용히 다시 시작이 고려됩니다. 조용히 다시 시작이 끝나면 디스플레이는 꺼진 상태로 유지되고 명시적인 사용자 상호작용이 있어야 디스플레이의 절전 모드를 해제할 수 있습니다.
파일 시스템 체크포인트
조용히 다시 시작 전에 파일 시스템 체크포인트가 요청되었다면 조용히 다시 시작 중에 userdata가 체크포인트 모드로 다시 마운트됩니다.
재마운트 로직은 fs_mgr_remount_userdata_into_checkpointing 함수에 구현되며 체크포인트 메서드마다 다릅니다. 특히 userdata가 다음을 지원하는 경우:
파일 시스템 수준 체크포인트(예: f2fs) - userdata가 checkpoint=disable 옵션으로 다시 마운트됩니다.
블록 수준 체크포인트(예: ext4) - /data가 마운트 해제되고 이 항목이 마운트된 모든 상위 기기의 매퍼 기기가 삭제됩니다. 그다음으로 userdata가 일반 체크포인트 부팅에 사용된 것과 동일한 코드 경로를 사용하여 마운트됩니다.
사용자 인증 정보가 암호화(CE)된 키와 기기가 암호화(DE)된 키를 파일 시스템 수준의 키링으로 관리하는 경우에는 userdata가 마운트 해제되면 키가 손실됩니다. 파일 시스템 키링에 키를 설치할 때 키 복원을 허용하기 위해 vold는 fscrypt-provisioning 유형의 동일한 키를 세션 수준 키링에도 설치합니다. init_user0가 호출되면 vold는 파일 시스템 키링에 키를 재설치합니다.
하드 재부팅으로 대체
조용히 다시 시작으로 인해 기기가 사용 불가한 상태가 되지 않도록 Android 11에서는 다음 조건 중 하나에 해당할 때 하드 재부팅으로 대체됩니다.
지정된 제한 시간 내에 기기가 조용히 다시 시작을 시작하지 못합니다(즉, sys.init.userspace_reboot.in_progress=1).
지정된 제한 시간 내에 프로세스가 중지되지 못합니다.
/system/bin/vdc volume reset 작업이 실패합니다.
zRAM 기기의 마운트 해제가 실패합니다.
활성 APEX 패키지가 올바르지 않게 마운트 해제됩니다.
userdata를 체크포인트 모드로 다시 마운트하려는 시도가 실패합니다.
지정된 제한 시간 내에 기기가 부팅되지 못합니다(즉, sys.boot_completed=1).
기기별 구성
다음 속성 값을 변경하여 조용히 다시 시작의 일부 속성을 조정할 수 있습니다.
init.userspace_reboot.is_supported는 기기가 조용히 다시 시작을 실행할 수 있는 시점을 제어합니다. 이 속성 값이 false 또는 0이거나 지정되지 않은 경우 다시 시작 시도가 거부됩니다.
init.userspace_reboot.sigkill.timeoutmillis는 SIGKILL 신호를 수신한 프로세스가 중지하기 위한 제한 시간(단위: 밀리초)을 제어합니다. 프로세스 중 하나가 지정된 제한 시간 내에 중지되지 않으면 하드 재부팅으로 대체됩니다.
init.userspace_reboot.sigterm.timeoutmillis는 SIGTERM 신호를 수신한 프로세스가 종료하기 위한 제한 시간(단위: 밀리초)을 제어합니다. 지정된 제한 시간 내에 종료되지 않은 모든 프로세스는 SIGKILL 신호를 수신합니다.
init.userspace_reboot.started.timeoutmillis는 조용히 다시 시작을 시작하기 위한 제한 시간(단위: 밀리초)을 제어합니다(즉, sys.init.userspace_reboot.in_progress=1). 기기가 지정된 제한 시간 내에 조용히 다시 시작을 시작하지 못하면 하드 재부팅으로 대체됩니다.
init.userspace_reboot.userdata_remount.timeoutmillis는 userdata 마운트 해제를 위한 제한 시간(단위: 밀리초)을 제어합니다. 기기가 지정된 제한 시간 내에 userdata를 마운트 해제하지 못하면 하드 재부팅으로 대체됩니다.
init.userspace_reboot.watchdog.timeoutmillis는 기기가 성공적으로 부팅하기 위한 제한 시간을 제어합니다(즉, sys.boot_completed=1). 기기가 지정된 제한 시간 내에 부팅하지 못하면 하드 재부팅으로 대체됩니다.
조용히 다시 시작 중 애니메이션 맞춤설정
조용히 다시 시작의 참조 구현에는 조용히 다시 시작 중에 표시되는 애니메이션을 맞춤설정할 수 있는 기능이 들어 있습니다.
userspace-reboot-fs-remount 작업이 끝나면 init가 bootanim 서비스를 시작합니다. 이 서비스는 다음 애니메이션 파일이 있는지 나열된 순서대로 검색하여 찾아낸 첫 번째 파일을 재생합니다.
/product/media/userspace-reboot.zip
/oem/media/userspace-reboot.zip
/system/media/userspace-reboot.zip
조용히 다시 시작을 위한 특정 애니메이션 파일이 지정되지 않으면 bootanim에서 기본 android 애니메이션을 표시합니다.
테스트
Android 11에는 조용히 다시 시작의 참조 구현이 포함되어 있습니다. 또한 UserspaceRebootHostTest에서 CTS 테스트를 사용하여 조용히 다시 시작을 확인할 수 있습니다.
이 페이지에 나와 있는 콘텐츠와 코드 샘플에는 콘텐츠 라이선스에서 설명하는 라이선스가 적용됩니다. 자바 및 OpenJDK는 Oracle 및 Oracle 계열사의 상표 또는 등록 상표입니다.
최종 업데이트: 2025-07-27(UTC)
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["필요한 정보가 없음","missingTheInformationINeed","thumb-down"],["너무 복잡함/단계 수가 너무 많음","tooComplicatedTooManySteps","thumb-down"],["오래됨","outOfDate","thumb-down"],["번역 문제","translationIssue","thumb-down"],["샘플/코드 문제","samplesCodeIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-07-27(UTC)"],[],[],null,["# Soft restarts (<= AOSP 14)\n\n| **Note:** Soft restart is deprecated in Android 15.\n\nAndroid 11 supports soft restarts, which are\nruntime restarts of processes in the user space used to apply updates that\nrequire a reboot (for example, updates to APEX packages). Currently, soft\nrestart is limited to processes that started after `userdata` has been mounted.\n\nA soft restart is requested in the following ways:\n\n- From `PowerManager`, by calling\n `PowerManager.reboot(PowerManager.REBOOT_USERSPACE)`\n\n- From shell, using `adb shell svc power reboot userspace` or `adb reboot\n userspace`\n\nAfter a soft restart, credential encrypted storage remains unlocked.\n\nIf a device supports soft restarts, then the\n`PowerManager.isRebootingUserspace()` API method returns `true`, and the value\nof the system property `init.userspace_reboot.is_supported` is equal to `1`.\n\nIf device doesn't support soft restarts, then calls to\n`PowerManager.reboot(PowerManager.REBOOT_USERSPACE)`, `adb reboot\nuserspace`, and `adb shell svc power reboot userspace` fail.\n\nSoft restart execution\n----------------------\n\n| **Note:** If the `PowerManager` API requests the soft restart, the framework runs the regular reboot sequence.\n\nAfter a soft restart is requested (through `PowerManager` or from a shell),\n`init` performs the following steps:\n\n1. Receives `sys.powerctl=reboot,userspace`.\n\n2. Forks a separate\n [`UserspaceRebootWatchdogThread()`](https://cs.android.com/android/_/android/platform/system/core/+/01c8eccca3f7c7ed9f08fdc7bb641ab40ac833d1:init/reboot.cpp;l=823;drc=802864c7826ea79f8cc29c52801e08bcfc15db76)\n process to monitor the soft restart.\n\n3. Triggers a `userspace-reboot-requested` action, which resets all system\n properties that might impact the soft restart. Affected properties:\n\n - `sys.usb.config`\n - `sys.usb.state`\n - `sys.boot_completed`\n - `dev.bootcomplete`\n - `sys.init.updatable_crashing`\n - `sys.init.updatable_crashing_process_name`\n - `apexd.status`\n - `sys.user.0.ce_available`\n - `sys.shutdown.requested`\n - `service.bootanim.exit`\n\n The above properties should be set again during boot sequence. If needed, you\n can reset additional properties. For examples, refer to the\n `on userspace-reboot-requested` action in\n [`rootdir/init.rc`](https://cs.android.com/android/_/android/platform/system/core/+/01c8eccca3f7c7ed9f08fdc7bb641ab40ac833d1:rootdir/init.rc;l=1047;drc=843f46e674e3f9d424144aa91c51777d66c9692c).\n4. Runs the\n [`DoUserspaceReboot`](https://cs.android.com/android/_/android/platform/system/core/+/01c8eccca3f7c7ed9f08fdc7bb641ab40ac833d1:init/reboot.cpp;l=735;drc=802864c7826ea79f8cc29c52801e08bcfc15db76)\n function, which performs the following actions:\n\n 1. Sends `SIGTERM` to processes started after `userdata` has been mounted and waits for them to stop.\n 2. After the timeout is reached, sends `SIGKILL` to kill any running processes.\n 3. Calls `/system/bin/vdc volume reset`.\n 4. Unmounts the zRAM backing device.\n 5. Unmounts active APEX packages.\n 6. Switches back to the bootstrap mount namespace.\n 7. Triggers the [`userspace-reboot-resume`](https://cs.android.com/android/_/android/platform/system/core/+/01c8eccca3f7c7ed9f08fdc7bb641ab40ac833d1:rootdir/init.rc;l=1068;drc=843f46e674e3f9d424144aa91c51777d66c9692c) action.\n\nIf file system checkpointing was requested before the soft restart,\n`userdata` is remounted into checkpointing mode during the\n`userspace-reboot-fs-remount` action (see the following section for details). A\nsoft restart is considered after the `sys.boot_completed property` is set\nto `1`. At the end of the soft restart, the display is kept off and\nexplicit user interaction is required to wake it.\n\nFile system checkpointing\n-------------------------\n\nIf a file system checkpoint was requested before the soft restart,\n`userdata` is remounted in checkpointing mode during the soft restart.\nRemounting logic is implemented in the\n[`fs_mgr_remount_userdata_into_checkpointing`](https://cs.android.com/android/_/android/platform/system/core/+/01c8eccca3f7c7ed9f08fdc7bb641ab40ac833d1:fs_mgr/fs_mgr.cpp;l=1647;drc=17824f0590785adc77181ad5f937aa5c50ebf2fe)\nfunction, and differs between checkpointing methods. Specifically, when\n`userdata` supports:\n\n- **Filesystem level checkpointing** (for example, `f2fs`), `userdata` is\n remounted with the `checkpoint=disable` option.\n\n- **Block level checkpointing** (for example, `ext4`), then `/data` is unmounted\n and all the parent device mapper devices it was mounted on top of are\n destroyed. Next, `userdata` is mounted using the same code path as used in\n normal checkpointing boot.\n\nIf a file system level keyring is used to manage credential-encrypted (CE) and\ndevice-encrypted (DE) keys, then keys are lost after `userdata` is unmounted. To\nallow key restoration, when installing a key to a file system keyring, `vold`\nalso installs the same key of type `fscrypt-provisioning` to session-level\nkeyring. When `init_user0` is called, `vold` reinstalls the keys in the file\nsystem keyring.\n\nFallback to hard reboot\n-----------------------\n\nTo ensure that a soft restart doesn't leave a device in an unusable state,\nAndroid 11 includes a fallback to hard reboot that's\ntriggered when one of the following conditions is met:\n| **Note:** This list isn't exhaustive.\n\n- A device fails to start soft restart (that is, `sys.init.userspace_reboot.in_progress=1`) within a given timeout.\n- A process fails to stop within a given timeout.\n- The `/system/bin/vdc volume reset` operation fails.\n- The unmounting of the zRAM device fails.\n- An active APEX package unmounts incorrectly.\n- An attempt to remount `userdata` into checkpointing mode fails.\n- A device fails to successfully boot (that is, `sys.boot_completed=1`) within a given timeout.\n\nPer-device configuration\n------------------------\n\nSome soft restart aspects can be tuned by changing values of the following\nproperties:\n\n- `init.userspace_reboot.is_supported` controls when a device can perform a soft restart. If value of this property is `false`, `0`, or not specified, then attempts to restart are rejected.\n- `init.userspace_reboot.sigkill.timeoutmillis` controls the timeout in milliseconds for processes that received a `SIGKILL` signal to stop. If one of the processes fails to stop in the given timeout, then a fallback to hard reboot is triggered.\n- `init.userspace_reboot.sigterm.timeoutmillis` controls the timeout in milliseconds for processes that received a `SIGTERM` signal to terminate. All the processes that failed to terminate in the given timeout receive a `SIGKILL` signal.\n- `init.userspace_reboot.started.timeoutmillis` controls the timeout in milliseconds for soft restart to start (that is, `sys.init.userspace_reboot.in_progress=1`). If a device fails to start soft restart within the given timeout, a fallback to hard reboot is triggered.\n- `init.userspace_reboot.userdata_remount.timeoutmillis` controls the timeout in milliseconds to unmount `userdata`. If a device fails to unmount `userdata` within the given timeout, a fallback to hard reboot is triggered.\n- `init.userspace_reboot.watchdog.timeoutmillis` controls the timeout for a device to successfully boot (that is, `sys.boot_completed=1`). If a device fails to boot within the given timeout, a fallback to hard reboot is triggered.\n\n| **Note:** Changing value of the above properties requires `root` access.\n\nCustomize animation during soft restart\n---------------------------------------\n\nThe reference implementation of a soft restart includes an ability to customize\nanimation shown during the soft restart.\n\nAt the end of the `userspace-reboot-fs-remount` action, `init` starts the\n`bootanim` service. This service looks for the existence of the following\nanimation files, in the order listed, and plays the first one it finds:\n\n- `/product/media/userspace-reboot.zip`\n- `/oem/media/userspace-reboot.zip`\n- `/system/media/userspace-reboot.zip`\n\n| **Note:** Animation files must adhere to the following [format](https://cs.android.com/android/platform/superproject/+/android-latest-release:frameworks/base/cmds/bootanimation/FORMAT.md)\n\nIf no soft restart specific animation files are specified, `bootanim` shows a\ndefault `android` animation.\n\nTesting\n-------\n\nAndroid 11 includes a reference implementation of a\nsoft restart. In addition, you can verify a soft restart using CTS\ntests in\n[`UserspaceRebootHostTest`](https://cs.android.com/android/_/android/platform/cts/+/7d2209956506ccca386863526b00160739d11062:hostsidetests/userspacereboot/src/com/android/cts/userspacereboot/host/UserspaceRebootHostTest.java;l=38;drc=5023f0c980728da99188e216269e498730c4476c)."]]
