Handle Android Process Death vs. Configuration Changes
Tests your grasp of Android's lifecycle for state restoration. A good answer explains that onCreate(savedInstanceState) is called in both cases, but process death recreates everything. Use ViewModel with SavedStateHandle.
What's really being asked
This question tests your ability to design robust Android apps that handle system-initiated process termination. It's not about reciting lifecycle methods, but about understanding the practical difference between a configuration change (where the process survives) and process death (where it doesn't). The interviewer is looking for your strategy to preserve UI state for a seamless user experience, separating you from engineers who only test the happy path.
The full answer
First, clarify the lifecycle path. After process death, the system creates a new process and a new Activity instance. The lifecycle starts from scratch with onCreate(savedInstanceState). The savedInstanceState Bundle, populated from data saved in onSaveInstanceState before the kill, is the key to restoration. Second, explain the key difference from a configuration change. During a config change, the process and Application object persist, so ViewModel instances survive. In process death, the entire process is gone, so standard ViewModels and singletons are destroyed and recreated. Third, describe the modern solution. Use a ViewModel to hold UI state and inject a SavedStateHandle. Data written to the SavedStateHandle is automatically persisted through the onSaveInstanceState mechanism and restored upon recreation, surviving process death. Finally, specify what to save: only minimal, transient UI state like user input or scroll position, not large data sets that can be re-fetched.
The mistakes people make
Stating that onStop() or onDestroy() are guaranteed to be called. The system can kill a background process at any time without further callbacks. Believing a standard ViewModel survives process death on its own; it does not. Its data is lost without a SavedStateHandle. Confusing the savedInstanceState Bundle with persistent storage like SharedPreferences or a database. The Bundle is for transient UI state and has a size limit (around 1MB) which can cause a TransactionTooLargeException if exceeded.
What usually comes next
How does SavedStateHandle work under the hood? What is the size limit of the savedInstanceState Bundle? How would you test for process death? (Answer: Use the "Don't keep activities" developer option or the ADB command adb shell am kill <your.package.name>).
A concrete example
A user is on a checkout screen. They switch apps to get a discount code. The OS kills your app's process. When they return, a poor implementation shows an empty checkout screen. A robust implementation using ViewModel and SavedStateHandle restores all their entered shipping info and the items in their cart, making the process death completely invisible to the user.
Interview question
When an Android app recovers from process death, what is the key difference in state restoration compared to a configuration change, and what is the recommended solution?
- a.Both scenarios primarily rely on onSaveInstanceState to store all necessary UI state, with no significant difference in ViewModel behavior.
- b.Process death destroys the entire application process, including standard ViewModels, making SavedStateHandle essential for transient UI state restoration.Correct
- c.Process death requires restoring state from persistent storage like SharedPreferences, as the savedInstanceState Bundle is too small for meaningful UI state.
- d.Standard ViewModels automatically persist across both configuration changes and process death, as they are managed by the system.
Why? this is the answer
Process death recreates the entire process, destroying standard ViewModels, which is why SavedStateHandle is needed to persist transient UI state. In contrast, configuration changes preserve the process and existing ViewModel instances. Option D is incorrect because standard ViewModels do not survive process death.
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