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

اندروید 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 مراحل زیر را انجام می دهد:

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

اگر کنترل سیستم فایل قبل از راه‌اندازی مجدد نرم‌افزار درخواست شده باشد، 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 ، راه‌اندازی مجدد نرم را تأیید کنید.