راه اندازی مجدد نرم (<= AOSP 14)

اندروید ۱۱ از راه‌اندازی مجدد نرم پشتیبانی می‌کند، که در واقع راه‌اندازی مجدد در زمان اجرا (runtime) فرآیندهایی در فضای کاربر است که برای اعمال به‌روزرسانی‌هایی که نیاز به راه‌اندازی مجدد دارند (به عنوان مثال، به‌روزرسانی‌های بسته‌های APEX) استفاده می‌شود. در حال حاضر، راه‌اندازی مجدد نرم محدود به فرآیندهایی است که پس از نصب userdata شروع شده‌اند.

درخواست راه‌اندازی مجدد نرم به روش‌های زیر انجام می‌شود:

  • از PowerManager ، با فراخوانی PowerManager.reboot(PowerManager.REBOOT_USERSPACE)

  • از طریق شل، با استفاده از adb shell svc power reboot userspace یا adb reboot userspace

پس از یک راه‌اندازی مجدد نرم، فضای ذخیره‌سازی رمزگذاری‌شده‌ی اعتبارنامه‌ها قفل‌گشایی نشده باقی می‌ماند.

اگر دستگاهی از راه‌اندازی مجدد نرم پشتیبانی کند، متد PowerManager.isRebootingUserspace() API true را برمی‌گرداند و مقدار ویژگی سیستمی init.userspace_reboot.is_supported برابر با 1 است.

اگر دستگاه از راه‌اندازی مجدد نرم پشتیبانی نکند، فراخوانی‌های PowerManager.reboot(PowerManager.REBOOT_USERSPACE) ، adb reboot userspace و adb shell svc power reboot userspace با شکست مواجه می‌شوند.

اجرای راه اندازی مجدد نرم

پس از درخواست راه‌اندازی مجدد نرم‌افزاری (از طریق PowerManager یا از طریق یک shell)، init مراحل زیر را انجام می‌دهد:

  1. sys.powerctl=reboot,userspace دریافت می‌کند.

  2. یک فرآیند جداگانه‌ی UserspaceRebootWatchdogThread() ‎ را برای نظارت بر راه‌اندازی مجدد نرم، منشعب می‌کند.

  3. یک اقدام 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 مراجعه کنید.

  4. تابع DoUserspaceReboot را اجرا می‌کند که اقدامات زیر را انجام می‌دهد:

    1. SIGTERM به فرآیندهایی که پس از mount شدن userdata آغاز شده‌اند ارسال می‌کند و منتظر توقف آنها می‌ماند.
    2. پس از رسیدن به زمان انقضا، SIGKILL را برای از بین بردن هرگونه فرآیند در حال اجرا ارسال می‌کند.
    3. /system/bin/vdc volume reset .
    4. دستگاه پشتیبان zRAM را از حالت اتصال خارج می‌کند.
    5. بسته‌های فعال APEX را از حالت نصب خارج می‌کند.
    6. به فضای نام mount بوت‌استرپ برمی‌گردد.
    7. عمل userspace-reboot-resume را فعال می‌کند.

اگر قبل از راه‌اندازی مجدد نرم، درخواست بررسی مجدد سیستم فایل داده شده باشد، userdata در طول عمل userspace-reboot-fs-remount به حالت بررسی مجدد بازگردانده می‌شود (برای جزئیات بیشتر به بخش زیر مراجعه کنید). راه‌اندازی مجدد نرم پس از تنظیم sys.boot_completed property روی 1 در نظر گرفته می‌شود. در پایان راه‌اندازی مجدد نرم، صفحه نمایش خاموش نگه داشته می‌شود و برای بیدار کردن آن، تعامل صریح کاربر لازم است.

بررسی سیستم فایل

اگر قبل از راه‌اندازی مجدد نرم، یک Checkpoint سیستم فایل درخواست شده باشد، userdata در حالت checkpointing در طول راه‌اندازی مجدد نرم، دوباره mount می‌شود. منطق remounting در تابع fs_mgr_remount_userdata_into_checkpointing پیاده‌سازی شده است و بین روش‌های checkpointing متفاوت است. به طور خاص، وقتی userdata از موارد زیر پشتیبانی می‌کند:

  • بررسی ایست بازرسی در سطح فایل سیستم (برای مثال، f2fs )، userdata با گزینه checkpoint=disable دوباره mount می‌شود.

  • در سطح بلوک (به عنوان مثال، ext4 )، سپس /data از حالت mount خارج می‌شود و تمام دستگاه‌های نگاشت‌کننده دستگاه والد که روی آن mount شده بودند، از بین می‌روند. در مرحله بعد، userdata با استفاده از همان مسیر کدی که در boot معمولی checkpointing استفاده می‌شود، mount می‌شود.

اگر از یک حلقه کلید سطح سیستم فایل برای مدیریت کلیدهای رمزگذاری‌شده با اعتبارنامه (CE) و رمزگذاری‌شده با دستگاه (DE) استفاده شود، پس از unmount شدن userdata ، کلیدها از بین می‌روند. برای امکان بازیابی کلید، هنگام نصب یک کلید در یک حلقه کلید سیستم فایل، vold همان کلید از نوع fscrypt-provisioning را در حلقه کلید سطح جلسه نیز نصب می‌کند. هنگامی که init_user0 فراخوانی می‌شود، vold کلیدها را در حلقه کلید سیستم فایل دوباره نصب می‌کند.

بازگشت به راه‌اندازی مجدد سخت

برای اطمینان از اینکه ریستارت نرم، دستگاه را در حالت غیرقابل استفاده قرار نمی‌دهد، اندروید ۱۱ شامل یک حالت بازگشت به ریستارت سخت است که در صورت برآورده شدن یکی از شرایط زیر فعال می‌شود:

  • دستگاهی نتواند در مدت زمان مشخص شده، راه‌اندازی مجدد نرم (یعنی sys.init.userspace_reboot.in_progress=1 ) را آغاز کند.
  • یک فرآیند در یک مهلت زمانی مشخص متوقف نمی‌شود.
  • عملیات /system/bin/vdc volume reset با شکست مواجه می‌شود.
  • عملیات unmount کردن دستگاه zRAM با شکست مواجه می‌شود.
  • یک بسته فعال APEX به طور نادرست از حالت مانت خارج می‌شود.
  • تلاش برای بازگرداندن userdata به حالت checkpointing با شکست مواجه شد.
  • دستگاهی در مدت زمان مشخص شده نتواند با موفقیت بوت شود (یعنی sys.boot_completed=1 ).

پیکربندی به ازای هر دستگاه

برخی از جنبه‌های راه‌اندازی مجدد نرم را می‌توان با تغییر مقادیر ویژگی‌های زیر تنظیم کرد:

  • init.userspace_reboot.is_supported کنترل می‌کند که یک دستگاه چه زمانی می‌تواند راه‌اندازی مجدد نرم (soft restart) انجام دهد. اگر مقدار این ویژگی false ، 0 یا مشخص نشده باشد، تلاش برای راه‌اندازی مجدد رد می‌شود.
  • init.userspace_reboot.sigkill.timeoutmillis زمان توقف فرآیندهایی که سیگنال SIGKILL دریافت کرده‌اند را بر حسب میلی‌ثانیه کنترل می‌کند. اگر یکی از فرآیندها در زمان توقف داده شده متوقف نشود، یک راه اندازی مجدد سخت افزاری (hard reboot) آغاز می‌شود.
  • 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 زمان لازم برای unmount کردن userdata را بر حسب میلی‌ثانیه کنترل می‌کند. اگر دستگاهی در مدت زمان تعیین‌شده نتواند userdata unmount کند، یک فرآیند راه‌اندازی مجدد خودکار (hard reboot) آغاز می‌شود.
  • init.userspace_reboot.watchdog.timeoutmillis زمان لازم برای بوت شدن موفقیت‌آمیز یک دستگاه را کنترل می‌کند (یعنی sys.boot_completed=1 ). اگر دستگاهی در مدت زمان مشخص شده بوت نشود، یک راه اندازی مجدد سخت افزاری (hard reboot) انجام می‌شود.

سفارشی‌سازی انیمیشن در هنگام راه‌اندازی مجدد نرم

پیاده‌سازی مرجع یک راه‌اندازی مجدد نرم شامل قابلیتی برای سفارشی‌سازی انیمیشن نمایش داده شده در طول راه‌اندازی مجدد نرم است.

در پایان عملیات userspace-reboot-fs-remount ، init سرویس bootanim را اجرا می‌کند. این سرویس به دنبال فایل‌های انیمیشن زیر به ترتیب لیست شده می‌گردد و اولین فایلی را که پیدا می‌کند، پخش می‌کند:

  • /product/media/userspace-reboot.zip
  • /oem/media/userspace-reboot.zip
  • /system/media/userspace-reboot.zip

اگر هیچ فایل انیمیشن مخصوص راه‌اندازی مجدد نرم مشخص نشده باشد، bootanim یک انیمیشن پیش‌فرض android را نشان می‌دهد.

آزمایش

اندروید ۱۱ شامل پیاده‌سازی مرجعی از راه‌اندازی مجدد نرم است. علاوه بر این، می‌توانید با استفاده از تست‌های CTS در UserspaceRebootHostTest ، راه‌اندازی مجدد نرم را تأیید کنید.