اعتبارًا من 27 آذار (مارس) 2025، ننصحك باستخدام android-latest-release بدلاً من aosp-main لإنشاء AOSP والمساهمة فيه. لمزيد من المعلومات، يُرجى الاطّلاع على التغييرات في AOSP.
تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
يتيح نظام التشغيل Android 11 عمليات إعادة التشغيل الناعمة، وهي تتمثّل في
إعادة تشغيل العمليات في مساحة المستخدم أثناء التشغيل، وذلك لتطبيق التحديثات التي
تتطلّب إعادة التشغيل (مثل تحديثات حِزم APEX). في الوقت الحالي، تقتصر عملية الصعق الكهربي الخفيف (
إعادة التشغيل) على العمليات التي بدأت بعد تركيب userdata.
يتم طلب إعادة التشغيل البسيطة بالطرق التالية:
من PowerManager، من خلال الاتصال بالرقم
PowerManager.reboot(PowerManager.REBOOT_USERSPACE)
من shell، باستخدام adb shell svc power reboot userspace أو adb reboot
userspace
بعد إعادة التشغيل البسيطة، تظل مساحة التخزين المشفَّرة لبيانات الاعتماد غير مقفلة.
إذا كان الجهاز يتيح إعادة التشغيل الناعم، ستعرض PowerManager.isRebootingUserspace()method في واجهة برمجة التطبيقات القيمة 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 الذي يعيد ضبط جميع ملفّات ملفّات System
التي قد تؤثّر في إعادة التشغيل البسيطة. المواقع المتأثرة:
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.
إذا تم طلب وضع نقطة فحص لنظام الملفات قبل إعادة التشغيل الناعمة، تتم إعادة تركيب ملف "userdata" في وضع نقطة الفحص أثناء تنفيذ الإجراء "userspace-reboot-fs-remount" (اطّلِع على القسم التالي للاطّلاع على التفاصيل). يتم إجراء عملية
إعادة تشغيل بسيطة بعد ضبط 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. تبحث هذه الخدمة عن توفّرملفّات الanimation التالية بالترتيب المدرَج، وتعرض أول ملف تعثر عليه:
/product/media/userspace-reboot.zip
/oem/media/userspace-reboot.zip
/system/media/userspace-reboot.zip
التالي:
في حال عدم تحديد ملفات متحركة خاصة بإعادة التشغيل البسيط، يعرض bootanim ملفًا متحركة
android تلقائيًا.
الاختبار
يتضمّن نظام التشغيل Android 11 عملية تنفيذ مرجعية لإعادة التشغيل الناعمة. بالإضافة إلى ذلك، يمكنك التحقّق من إعادة التشغيل البسيطة باستخدام اختبارات CTS
في
UserspaceRebootHostTest.
يخضع كل من المحتوى وعيّنات التعليمات البرمجية في هذه الصفحة للتراخيص الموضحّة في ترخيص استخدام المحتوى. إنّ Java وOpenJDK هما علامتان تجاريتان مسجَّلتان لشركة Oracle و/أو الشركات التابعة لها.
تاريخ التعديل الأخير: 2025-07-27 (حسب التوقيت العالمي المتفَّق عليه)
[[["يسهُل فهم المحتوى.","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 (حسب التوقيت العالمي المتفَّق عليه)"],[],[],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)."]]
