از 27 مارس 2025، توصیه می کنیم از android-latest-release به جای aosp-main برای ساختن و کمک به AOSP استفاده کنید. برای اطلاعات بیشتر، به تغییرات AOSP مراجعه کنید.
با مجموعهها، منظم بمانید
ذخیره و طبقهبندی محتوا براساس اولویتهای شما.
اندروید 11 از راه‌اندازی‌های نرم‌افزار پشتیبانی می‌کند، که در زمان اجرا فرآیندهای موجود در فضای کاربر برای اعمال به‌روزرسانی‌هایی که نیاز به راه‌اندازی مجدد دارند استفاده می‌شود (مثلاً به‌روزرسانی‌های بسته‌های APEX). در حال حاضر، راه‌اندازی مجدد نرم محدود به فرآیندهایی است که پس از نصب userdata شروع شده‌اند.
یک راه اندازی مجدد نرم به روش های زیر درخواست می شود:
از PowerManager ، با فراخوانی PowerManager.reboot(PowerManager.REBOOT_USERSPACE)
از پوسته، با استفاده از adb shell svc power reboot userspace یا adb reboot userspace
پس از راه‌اندازی مجدد نرم، فضای ذخیره‌سازی رمزگذاری شده اعتبارنامه باز می‌ماند.
اگر دستگاهی از راه‌اندازی مجدد نرم‌افزار پشتیبانی می‌کند، متد API PowerManager.isRebootingUserspace()true را برمی‌گرداند و مقدار ویژگی سیستم init.userspace_reboot.is_supported برابر با 1 است.
اگر دستگاه از راه‌اندازی‌های نرم‌افزار پشتیبانی نمی‌کند، تماس‌ها به PowerManager.reboot(PowerManager.REBOOT_USERSPACE) ، adb reboot userspace و adb shell svc power reboot userspace با شکست مواجه می‌شوند.
اجرای راه اندازی مجدد نرم
پس از درخواست یک راه اندازی مجدد نرم (از طریق PowerManager یا از یک پوسته)، init مراحل زیر را انجام می دهد:
یک اقدام userspace-reboot-requested راه‌اندازی می‌کند، که تمام ویژگی‌های سیستم را که ممکن است بر راه‌اندازی مجدد نرم تأثیر بگذارد، بازنشانی می‌کند. خواص تحت تأثیر:
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
ویژگی های بالا باید در طول توالی بوت دوباره تنظیم شوند. در صورت نیاز، می توانید ویژگی های اضافی را بازنشانی کنید. برای مثال، به عمل on userspace-reboot-requested در rootdir/init.rc مراجعه کنید.
تابع DoUserspaceReboot را اجرا می کند که اقدامات زیر را انجام می دهد:
SIGTERM به فرآیندهایی که پس از نصب userdata شروع شده‌اند ارسال می‌کند و منتظر می‌ماند تا متوقف شوند.
پس از اتمام زمان، SIGKILL می فرستد تا فرآیندهای در حال اجرا را از بین ببرد.
اگر کنترل سیستم فایل قبل از راه‌اندازی مجدد نرم‌افزار درخواست شده باشد، userdata در طول عمل userspace-reboot-fs-remount مجدداً به حالت checkpointing سوار می‌شوند (برای جزئیات به بخش زیر مراجعه کنید). پس از تنظیم 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 کلیدها را در keyring سیستم فایل دوباره نصب می کند.
بازگشت به راه اندازی مجدد سخت
برای اطمینان از اینکه راه‌اندازی نرم‌افزار دستگاه را در حالت غیرقابل استفاده قرار نمی‌دهد، 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 را نشان می دهد.
تست کردن
اندروید 11 شامل اجرای مرجع یک راه اندازی مجدد نرم افزاری است. علاوه بر این، می‌توانید با استفاده از تست‌های CTS در UserspaceRebootHostTest ، راه‌اندازی مجدد نرم را تأیید کنید.
محتوا و نمونه کدها در این صفحه مشمول پروانههای توصیفشده در پروانه محتوا هستند. جاوا و OpenJDK علامتهای تجاری یا علامتهای تجاری ثبتشده Oracle و/یا وابستههای آن هستند.
تاریخ آخرین بهروزرسانی 2025-07-29 بهوقت ساعت هماهنگ جهانی.
[[["درک آسان","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-29 بهوقت ساعت هماهنگ جهانی."],[],[],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)."]]
