Explain app restoration after Android process death
Tests your grasp of process death vs. configuration changes. A good answer explains that the entire app process is recreated, starting with onCreate, and state must be restored from the SavedStateHandle.
What's really being asked
This tests a senior-level understanding of the Android process model and state restoration. It probes whether you can differentiate between three scenarios: normal app backgrounding, configuration changes, and process death. Interviewers want to see that you design for the most destructive case (process death) by default, not as an afterthought. It's a key indicator of a robust, production-ready mindset.
The full answer
A precise answer hits four points in order. First, when the process is killed, no further lifecycle methods are called on the original Activity instance; onStop and onDestroy are NOT guaranteed to run. Second, when the user returns, the system creates a new process and a new Application object. Third, it recreates the Activity back stack, calling onCreate(savedInstanceState) for the top Activity. The savedInstanceState Bundle is the key, populated by a prior onSaveInstanceState call. Fourth, modern best practice is to handle this state using a ViewModel and its SavedStateHandle, which abstracts away the Bundle logic and survives configuration changes, while also providing the mechanism to persist/restore through process death.
The mistakes people make
The most common error is describing the lifecycle for an app returning from the background without process death, which is onRestart -> onStart -> onResume. Another major red flag is conflating process death with a configuration change. While both can trigger onCreate, a config change happens within the same living process, so a standard ViewModel instance survives. In process death, the ViewModel is also destroyed and must be recreated, restoring its state from the SavedStateHandle. Mentioning only SharedPreferences or a database for UI state is also a smell; those are for persistent data, not transient UI state.
What usually comes next
How do you test process death? (Use the "Don't keep activities" developer option, or the adb shell am kill <package> command). When is onSaveInstanceState called? (It's called when the system deems the Activity killable, typically after onStop. Before API 28, it was called before onStop). What's the size limit of the savedInstanceState Bundle? (Historically around 500KB to 1MB, but it's not a reliable contract. It's for small amounts of state, not large data). How does Jetpack Compose handle this? (Using rememberSaveable).
A concrete example
A user is filling out a complex form. They get a phone call, putting the app in the background. The OS, under memory pressure, kills the app's process. Without proper state handling, when the user returns, they'd see a blank form. The correct implementation uses a ViewModel with a SavedStateHandle. Each form field's content is saved to the handle as it changes. Upon process recreation, the ViewModel is re-initialized, its SavedStateHandle is automatically populated by the system from the savedInstanceState Bundle, and the UI observes this state to repopulate the form fields. The user's progress is seamlessly restored.
Interview question
After an app's process is killed by the OS and the user navigates back, which statement accurately describes the state restoration process?
- a.A new process, Activity, and ViewModel are created; the ViewModel restores its state from the SavedStateHandle.Correct
- b.A new Activity is created, but the existing ViewModel instance survives, preserving its state in memory.
- c.The existing Activity instance is resumed by calling onRestart(), onStart(), and onResume(), with all state intact.
- d.The system guarantees a call to onStop() and onDestroy(), then restores the UI state from SharedPreferences.
Why? this is the answer
Process death destroys the entire process, so a new process, Activity, and ViewModel are all created. The ViewModel restores its state from the SavedStateHandle. A common error is confusing this with a configuration change, where the ViewModel instance does survive.
Just read this? Test yourself on what you have been reading.
Read the original → developer.android.com
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on android — each one lists the topics its interview covers.
See open roles