How does a ViewModel survive configuration changes?
Tests understanding of ViewModel's scope, separate from the Activity lifecycle. A ViewModel is retained by a ViewModelStore, which persists across configuration changes. The new Activity instance then reconnects to the same ViewModel.
What's really being asked
This question tests your understanding of the mechanics behind the Android Architecture Components, specifically how a ViewModel's lifecycle is decoupled from the UI controller's (Activity/Fragment) lifecycle. The interviewer wants to know if you understand the underlying objects like ViewModelStore and ViewModelStoreOwner, not just that "it survives rotation."
The full answer
First, clarify that a ViewModel is scoped to a ViewModelStoreOwner (like an Activity or Fragment), not the UI controller instance itself. Second, explain that when a configuration change happens, the system retains a special non-configuration instance object that holds the ViewModelStore. Third, the new Activity instance created after the change connects to this pre-existing ViewModelStore and retrieves the same ViewModel instance. Finally, state the ViewModel's scope: it is destroyed only when its owner is permanently destroyed (e.g., Activity.finish() is called), at which point its onCleared() method is invoked. It does not survive process death on its own.
The mistakes people make
Confusing ViewModel with onSaveInstanceState is a major red flag. ViewModels hold complex objects in memory across configuration changes. onSaveInstanceState serializes a small amount of data to a Bundle to survive system-initiated process death. They solve different problems. Another mistake is giving a vague answer like "the system handles it" without mentioning ViewModelStore. Finally, incorrectly stating that a ViewModel survives process death is a common error; for that, you need the Saved State module for ViewModel.
What usually comes next
Expect questions like: "How would you make state survive process death within a ViewModel?" (Answer: Use SavedStateHandle). "What is the purpose of the onCleared() method?" (Answer: To free up resources, like cancelling coroutines in viewModelScope or detaching listeners). "How do you pass parameters like a user ID to a ViewModel?" (Answer: By implementing a ViewModelProvider.Factory).
A concrete example
Imagine a ViewModel fetches user data via a network call that takes 2 seconds. The user rotates their phone 1 second into the call. Without a ViewModel, the Activity is destroyed, the network call's context is lost, and the new Activity would start the call all over again. With a ViewModel, the ViewModel instance and its viewModelScope survive the rotation. The network call continues uninterrupted. When the new Activity connects to the existing ViewModel, it can immediately observe the data, which will arrive 1 second later without re-fetching. This saves network, battery, and provides a seamless user experience.
Interview question
Which statement accurately describes how an Android ViewModel maintains its state during configuration changes, such as screen rotation?
- a.The Android system internally caches the ViewModel instance and injects it into the new Activity instance after a configuration change.
- b.The ViewModel's data is automatically saved into the Activity's onSaveInstanceState() Bundle and then restored when the Activity is recreated.
- c.ViewModels are designed to persist across both configuration changes and process death, making them suitable for long-term data storage.
- d.The ViewModel is associated with a ViewModelStore that is retained across configuration changes, allowing the new ViewModelStoreOwner instance to retrieve the same ViewModel.Correct
Why? this is the answer
The correct answer is C because a ViewModel is scoped to a ViewModelStoreOwner, and its ViewModelStore is retained across configuration changes, enabling the new UI controller to retrieve the existing ViewModel instance. Option B is incorrect as onSaveInstanceState() is for serializing small data to a Bundle to survive process death, not for retaining complex ViewModel objects in memory across configuration changes.
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