Config Changes & Process Death Interview Questions
ANDROID › Lifecycle
Walk me through the practical difference between a configuration change and system-initiated process death from the app's point of view. Why does conflating the two lead to bugs?
What a strong answer covers: A configuration change destroys and recreates the same process and Activity instance in place, quickly and in memory, and ViewModel survives it because it's retained by the ViewModelStore; process death is the OS killing the whole process to reclaim memory while the user is elsewhere, so everything in memory including the ViewModel is gone, and only what was explicitly serialized via onSaveInstanceState/SavedStateHandle or persisted to disk comes back. Conflating the two causes bugs like assuming ViewModel state survives indefinite backgrounding, or treating a rotation test as equivalent to a real process-death test when rotation never exercises the Bundle serialization path at all.
A junior dev adds android:configChanges="orientation|screenSize" to 'fix' a bug where a video player restarts on rotation. What's the real trade-off they're making, and when, if ever, would you actually recommend that flag?
What a strong answer covers: Setting configChanges tells the system not to recreate the Activity for that config change at all, which means the app now has to manually handle every affected UI concern itself in onConfigurationChanged, layout resources, string resources for locale changes and so on, reintroducing exactly the bug class the recreate-and-restore model exists to prevent; it also does nothing for process death, since that's a full kill, not a config change. This flag is basically never the right general fix for state resetting on rotation, that's what ViewModel is for; the rare legitimate use is something like an active video or camera surface where a full teardown and recreate is genuinely expensive and disruptive and the app can cheaply reposition itself instead.
You've got a screen with a large in-memory list backed by network results. Where do you draw the line between what lives in ViewModel/SavedStateHandle versus what you just refetch or reload from a local cache after process death, and why?
What a strong answer covers: Keep in ViewModel, which survives config change only, anything cheap to hold for the current session; put a small identifier or minimal state in SavedStateHandle, which survives process death, that's enough to redrive a refetch, like a query string, a scroll position, or a selected id, not the fetched list itself. Rely on re-fetching from network or a local Room/DataStore cache to reconstruct the list after process death, since stuffing the whole list into SavedStateHandle would blow past the Bundle's roughly 1MB TransactionTooLargeException ceiling and forces main-thread serialization on every save; a weak answer either serializes the whole list or drops the query entirely and returns the user to a blank state.