Process death

Lifecycle and app components Senior Kotlin 2.0+ API 24+ Reviewed By Best Latest Apps

Predict the output

A user fills in step 2 of a sign-up flow, switches apps, and Android kills the process. They return from Recents. What do they see?

class SignUpViewModel(private val handle: SavedStateHandle) : ViewModel() {
    var email: String = ""                         // set on step 1
    val step = handle.getStateFlow("step", 1)
    fun next() { handle["step"] = step.value + 1 }
}
Options
Hint 1 of 1

Which values were written to SavedStateHandle?

Choose an answer, then open Show answer below to check it.

Show answer

Answer: A Step 2, but the email from step 1 is empty

Correct. The step is in SavedStateHandle and is restored; the plain field is lost with the process.

Why not the others?
  • B Step 1 with everything empty. The step number was saved, so the flow is restored at step 2.
  • C Step 2 with the email intact. A plain ViewModel field doesn't survive process death.
  • D The launcher screen, because the task was removed. Recents restores the task and its saved state.
Two scenarios: going home and coming back without process death, and with process death in between.

Illustrative, based on Compose and Android rules; not a device recording

Text version

Home, then back

  1. A onPause
  2. A onStop
  3. A onSaveInstanceState
  4. A onRestart
  5. A onStart
  6. A onResume

Home, killed, back

  1. A onPause
  2. A onStop
  3. A onSaveInstanceState
  4. (process killed: no more callbacks)
  5. A' onCreate (with saved Bundle)
  6. A' onStart
  7. A' onResume
What survives
StateHome, then backHome, killed, back
local var✓ kept✕ lost
remember✓ kept✕ lost
rememberSaveable✓ kept✓ kept
ViewModel✓ kept✕ lost
SavedStateHandle✓ kept✓ kept
Room / disk✓ kept✓ kept

30-second answer

When an app is in the background, Android can kill its process to free memory. When the user returns, Android creates a new process and recreates the last Activity with its saved instance state, so it looks as if the app never left. ViewModels, singletons and in-memory caches are gone. Only saved state (SavedStateHandle, rememberSaveable) and disk survive.

Practise saying it · 45 s. No recording, just a timer

Explain process death and how to survive it.

Say your answer out loud, then check which of these points you covered:

  • The process is killed in the background
  • The Activity stack and saved state are restored
  • ViewModels and singletons are lost
  • Save IDs in SavedStateHandle
  • Test with adb shell am kill

Deep dive

Test it: put the app in the background and run adb shell am kill <package>, then return from Recents.

Save small UI state (IDs, input, scroll position) in SavedStateHandle; reload data from disk or the network using those IDs.

Back stacks of Activities and Navigation entries are restored too, which can recreate screens whose dependencies are no longer in memory.

Don't rely on a static field set in a previous screen; it will be null after process death.

Common mistakes

  • Assuming the ViewModel survives process death.
  • Testing only with rotation and calling it done.
  • Storing whole objects in saved state instead of IDs.

Senior take & follow-ups

Seniors give the adb test and the ID-not-object rule. Few candidates know Recents restores the stack.

Follow-up questions

Think of your answer first, then open the hint.

  1. How do you simulate process death?

    Show hint

    Background the app and run adb shell am kill, then reopen from Recents.

  2. What's restored automatically?

    Show hint

    The task's Activity stack, their saved instance state, and the Navigation back stack.

Similar on iOS: Restoring navigation after the system kills the app iOS state restoration is opt-in per scene; Android always tries to restore the task.

Suggest a fix if something here is wrong or out of date.