Mulai ulang sementara

Android 11 mendukung soft restart, yang {i>runtime<i} memulai ulang proses di ruang pengguna yang digunakan untuk menerapkan pembaruan yang memerlukan {i>reboot<i} (misalnya, pembaruan ke paket APEX). Saat ini, lembut mulai ulang terbatas untuk proses yang dimulai setelah userdata terpasang.

Mulai ulang di latar belakang dapat dilakukan dengan cara berikut:

  • Dari PowerManager, dengan menelepon PowerManager.reboot(PowerManager.REBOOT_USERSPACE)

  • Dari shell, menggunakan adb shell svc power reboot userspace atau adb reboot userspace

Setelah soft restart, penyimpanan yang dienkripsi dengan kredensial akan tetap tidak terkunci.

Jika perangkat mendukung {i>soft restart<i}, maka Metode API PowerManager.isRebootingUserspace() menampilkan true, dan nilainya dari properti sistem init.userspace_reboot.is_supported sama dengan 1.

Jika perangkat tidak mendukung {i>soft restart<i}, maka panggil ke PowerManager.reboot(PowerManager.REBOOT_USERSPACE), adb reboot userspace, dan adb shell svc power reboot userspace gagal.

Eksekusi mulai ulang di latar belakang

Setelah soft restart diminta (melalui PowerManager atau dari shell), init melakukan langkah-langkah berikut:

  1. Menerima sys.powerctl=reboot,userspace.

  2. Buat terpisah UserspaceRebootWatchdogThread() untuk memantau soft restart.

  3. Memicu tindakan userspace-reboot-requested, yang mereset semua sistem yang mungkin memengaruhi soft restart. Properti yang terpengaruh:

    • 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

    Properti di atas harus disetel lagi selama urutan booting. Jika diperlukan, Anda dapat mereset properti tambahan. Misalnya, lihat on userspace-reboot-requested tindakan di rootdir/init.rc.

  4. Menjalankan DoUserspaceReboot , yang akan melakukan tindakan berikut:

    1. Mengirim SIGTERM ke proses yang dimulai setelah userdata dipasang dan dan menunggu mereka berhenti.
    2. Setelah waktu tunggu habis, mengirim SIGKILL untuk menghentikan semua yang berjalan proses-proses tersebut.
    3. Memanggil /system/bin/vdc volume reset.
    4. Melepas perangkat pendukung zRAM.
    5. Melepaskan paket APEX aktif.
    6. Beralih kembali ke namespace pemasangan bootstrap.
    7. Memicu userspace-reboot-resume tindakan.

Jika {i>checkpointing<i} sistem file diminta sebelum {i>soft restart<i}, userdata dipasang kembali ke mode checkpoint selama Tindakan userspace-reboot-fs-remount (lihat bagian berikut untuk detailnya). J soft restart dipertimbangkan setelah sys.boot_completed property disetel ke 1. Di akhir {i>soft restart<i}, layar akan tetap dimatikan dan interaksi pengguna yang eksplisit diperlukan untuk mengaktifkannya.

Pemeriksaan sistem file

Jika {i>checkpoint<i} sistem file diminta sebelum {i>soft restart<i}, userdata dipasang kembali dalam mode checkpoint selama soft restart. Logika pemasangan ulang diimplementasikan di fs_mgr_remount_userdata_into_checkpointing fungsi, dan berbeda-beda di antara metode {i>checkpointing<i}. Khususnya, ketika userdata mendukung:

  • Checkpoint tingkat sistem file (misalnya, f2fs), userdata adalah dipasang kembali dengan opsi checkpoint=disable.

  • Checkpoint tingkat blok (misalnya, ext4), lalu /data dilepas dan semua perangkat {i>mapper <i}perangkat induk yang dipasang di atasnya adalah dihancurkan. Selanjutnya, userdata dipasang menggunakan jalur kode yang sama seperti yang digunakan di proses {i>checkpointing <i}yang normal.

Jika {i>keyring<i} tingkat sistem file digunakan untuk mengelola enkripsi kredensial (CE) dan kunci yang dienkripsi perangkat (DE), lalu kunci akan hilang setelah userdata dilepas. Kepada mengaktifkan pemulihan kunci, saat menginstal kunci ke keyring sistem file, vold juga menginstal kunci yang sama dari jenis fscrypt-provisioning ke tingkat sesi keyring. Saat init_user0 dipanggil, vold akan menginstal ulang kunci dalam file keyring sistem.

Penggantian ke reboot keras

Untuk memastikan bahwa {i>soft restart<i} tidak membuat perangkat dalam keadaan tidak dapat digunakan, Android 11 menyertakan penggantian ke reboot keras yang dipicu saat salah satu kondisi berikut terpenuhi:

  • Perangkat gagal memulai soft restart (yaitu, sys.init.userspace_reboot.in_progress=1) dalam waktu tunggu yang ditentukan.
  • Sebuah proses gagal berhenti dalam waktu tunggu yang ditentukan.
  • Operasi /system/bin/vdc volume reset gagal.
  • Pelepasan perangkat zRAM gagal.
  • Paket APEX aktif dilepas dengan tidak benar.
  • Upaya untuk memasang kembali userdata ke mode checkpointing gagal.
  • Perangkat gagal melakukan booting (yaitu, sys.boot_completed=1) dalam waktu tunggu yang diberikan.

Konfigurasi per perangkat

Beberapa aspek soft restart dapat disesuaikan dengan mengubah nilai berikut properti:

  • init.userspace_reboot.is_supported mengontrol kapan perangkat dapat melakukan soft restart. Jika nilai properti ini adalah false, 0, atau tidak ditentukan, maka upaya untuk memulai ulang akan ditolak.
  • init.userspace_reboot.sigkill.timeoutmillis mengontrol waktu tunggu di milidetik untuk proses yang menerima sinyal SIGKILL untuk berhenti. Jika salah satu dari proses gagal berhenti dalam waktu tunggu yang diberikan, lalu kembali ke hard akan dipicu.
  • init.userspace_reboot.sigterm.timeoutmillis mengontrol waktu tunggu di milidetik untuk proses yang menerima sinyal SIGTERM untuk dihentikan. Semua proses yang gagal dihentikan dalam waktu tunggu yang ditentukan akan menerima Sinyal SIGKILL.
  • init.userspace_reboot.started.timeoutmillis mengontrol waktu tunggu di milidetik sampai soft restart untuk dimulai (yaitu, sys.init.userspace_reboot.in_progress=1). Jika perangkat gagal memulai soft mulai ulang dalam waktu tunggu yang ditentukan, penggantian ke {i>hard reboot<i} akan dipicu.
  • init.userspace_reboot.userdata_remount.timeoutmillis mengontrol waktu tunggu di dalam milidetik untuk melepas userdata. Jika perangkat gagal melepas userdata dalam waktu tunggu yang ditentukan, penggantian ke {i>hard reboot<i} akan dipicu.
  • init.userspace_reboot.watchdog.timeoutmillis mengontrol waktu tunggu untuk perangkat agar berhasil melakukan booting (yaitu, sys.boot_completed=1). Jika perangkat gagal booting dalam waktu tunggu yang ditentukan, maka fallback ke {i>hard reboot<i} dipicu.

Sesuaikan animasi selama soft restart

Implementasi referensi soft restart mencakup kemampuan untuk menyesuaikan animasi yang ditampilkan selama soft restart.

Di akhir tindakan userspace-reboot-fs-remount, init memulai Layanan bootanim. Layanan ini mencari keberadaan hal berikut file animasi, dalam urutan yang tercantum, dan memutar yang pertama ditemukannya:

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

Jika tidak ada file animasi khusus soft restart yang ditentukan, bootanim akan menampilkan animasi android default.

Pengujian

Android 11 menyertakan implementasi referensi soft restart. Selain itu, Anda dapat memverifikasi soft restart menggunakan CTS tes di UserspaceRebootHostTest