Config Changes & Process Death Quiz
ANDROID › Lifecycle
An Activity holds a counter in a plain field. After the user rotates the device, the counter resets to zero. What happened?
- The process was killed for low memory, so the counter never survived
- Rotation recreated the Activity, so its instance field was cleared
- Rotation caused no lifecycle change, so the same Activity kept running
- onSaveInstanceState restored a stale zero, overwriting the field value
Answer: Rotation recreated the Activity, so its instance field was cleared
Rotation is a configuration change; by default the system destroys and recreates the Activity, so any state kept only in instance fields is lost.
Which storage option survives a configuration change but is destroyed by system-initiated process death?
- SavedStateHandle
- Room database
- ViewModel
- rememberSaveable
Answer: ViewModel
A ViewModel is retained across recreation in memory but lives inside the process, so killing the process for memory destroys it. SavedStateHandle, rememberSaveable, and Room all survive process death.
Why does the framework limit onSaveInstanceState / SavedStateHandle to small, simple data?
- It is written asynchronously out to an encrypted on-disk cache, which is far too slow to ever block on
- Serialized into a Bundle over a Binder, so oversized data throws TransactionTooLargeException
- The saved-state Bundle can only ever hold one String value under a single key
- It is stored inside the ViewModelStore, which enforces a hard 64KB serialized cap
Answer: Serialized into a Bundle over a Binder, so oversized data throws TransactionTooLargeException
Saved instance state is serialized into a Bundle on the main thread and crosses a Binder transaction (~1MB limit), so large payloads cause jank or TransactionTooLargeException. Store IDs, not whole objects.
A user swipes your app away from the Recents screen and reopens it. What does the user (and Android) expect to be restored?
- The full ViewModel and saved instance state, as after rotation
- Only saved instance state, with the ViewModel recreated later
- Nothing transient; only persistent storage should remain
- Everything, because swiping away is treated like simple backgrounding
Answer: Nothing transient; only persistent storage should remain
Swiping from Recents is a user-initiated dismissal: both ViewModel and saved instance state are discarded. Only persistent storage survives, and the user expects a clean start.
You add android:configChanges="orientation|screenSize" to an Activity. What is the correct expectation?
- Your UI state is now fully safe from system-initiated process death and recreation as well
- Rotation won't recreate it, but process death still needs ViewModel and saved state
- The Activity will simply never be recreated again for any reason whatsoever
- ViewModel is no longer needed since configuration changes are now fully handled
Answer: Rotation won't recreate it, but process death still needs ViewModel and saved state
configChanges only suppresses recreation for the listed changes (you get onConfigurationChanged and recomposition). It does nothing for process death, so you still need ViewModel plus saved state.
What is the most reliable way to reproduce system-initiated process death while testing?
- Rotate the device several times quickly to force repeated view teardown and recreation
- Call finish() to end the Activity, then immediately relaunch it fresh
- Background the app, run adb shell am kill <package>, relaunch from Recents
- Toggle the system dark-mode setting on and off many times in a row
Answer: Background the app, run adb shell am kill <package>, relaunch from Recents
Backgrounding then killing the process via adb (or the Don't keep activities developer option) simulates the OS reclaiming memory, restoring saved state while discarding the ViewModel. Rotation and finish() are different events.
In an MVVM screen, where should the canonical list of items shown to the user live so it survives both a config change and process death without serialization limits?
- In Room or DataStore, then cached in a ViewModel
- All inside one rememberSaveable Bundle for the screen
- In Activity fields restored later from onCreate only
- In a companion object static field shared by the app
Answer: In Room or DataStore, then cached in a ViewModel
Real data belongs in persistent storage (Room/DataStore) which survives everything; the ViewModel caches it in memory for fast access, and saved state holds only a tiny key like a query or scroll position.
The user presses Back to finish your Activity, then relaunches the app from the launcher. Was onSaveInstanceState() called during that finish?
- Yes, it is always called immediately before onDestroy() runs.
- Yes, but only when a ViewModel is attached to the Activity.
- Only on Android 12 and higher, when back navigation is used.
- No, because an explicit finish means nothing needs restoring.
Answer: No, because an explicit finish means nothing needs restoring.
onSaveInstanceState runs when the system might recreate or reclaim the Activity, not when the user explicitly finishes it (Back/finish()); there is nothing the user expects restored, so the framework skips it.
After system-initiated process death, how does a value held in a ViewModel's SavedStateHandle come back?
- It was put in the saved-instance-state Bundle and re-injected on rebuild
- The ViewModel object itself is serialized to disk and restored on restart
- Android keeps the dead process paused in memory and simply resumes it later
- It is quietly reloaded from a Room database by the framework after death
Answer: It was put in the saved-instance-state Bundle and re-injected on rebuild
SavedStateHandle is backed by the Activity's saved-state registry, so its contents ride in the restored Bundle and are re-injected into a freshly created ViewModel after the process is rebuilt.
In Jetpack Compose, what is the practical difference between remember and rememberSaveable?
- There is none at all; rememberSaveable is merely a deprecated alias kept for source compatibility
- remember survives process death, whereas rememberSaveable is cleared on recreation
- Only rememberSaveable also survives recreation and process death, via the saved-state Bundle
- rememberSaveable only works when it is called from inside a ViewModel scope
Answer: Only rememberSaveable also survives recreation and process death, via the saved-state Bundle
remember only outlives recomposition and is lost on recreation; rememberSaveable additionally stores its value in the saved-instance-state Bundle, so it is restored across config changes and process death.
You wrap a custom data class in rememberSaveable and it crashes at runtime saying the value cannot be saved. What is the fix?
- rememberSaveable can only hold Int, Boolean, and String values
- Make it Bundle-saveable, like Parcelable, or add a custom Saver
- Annotate the data class with @Composable so it can be saved
- Add the @Stable annotation to the class to make it saveable
Answer: Make it Bundle-saveable, like Parcelable, or add a custom Saver
rememberSaveable serializes into a Bundle, so the value must be a Bundle-compatible type such as Parcelable, or you must supply a custom Saver that maps it to and from a saveable form.
When is your app's process most likely to be killed by the system specifically to reclaim memory?
- While it is in the foreground and the app is actively open
- Immediately after each screen rotation or configuration change
- Only when the device is rebooted or powered fully off
- While it is in the background and the system needs memory
Answer: While it is in the background and the system needs memory
The OS reclaims memory by killing low-priority background processes; a foreground app is near the top of the priority list and is rarely targeted, which is why process death almost always strikes a backgrounded app.
Inside onStop()/onDestroy(), how can you tell whether the Activity is going away because of a configuration change rather than a real teardown?
- Check whether savedInstanceState is non-null
- Call isChangingConfigurations()
- Compare the current ViewModelStore size to the previous one
- There is no API, so you must infer it from how quickly onCreate runs again
Answer: Call isChangingConfigurations()
Activity.isChangingConfigurations() returns true when the teardown is caused by a configuration change, letting you distinguish it from a genuine finish or process-reclaim destroy.
Why is the 'Don't keep activities' developer option a handy but imperfect way to test process-death restoration?
- It only works on emulators, and physical devices ignore the setting entirely.
- It wipes your app's persisted data each time, so every launch starts completely fresh.
- It finishes the Activity and clears its ViewModel, but the process stays alive.
- It restores even more state than a real kill, so bad code looks correct in testing.
Answer: It finishes the Activity and clears its ViewModel, but the process stays alive.
The option finishes each backgrounded Activity (clearing its ViewModel and forcing a saved-state restore) but leaves the process alive, so anything held at process scope persists and masks real process-death bugs that an actual kill would expose.