Config Changes & Process Death Flashcards
ANDROID › Lifecycle
- Name four things that trigger a configuration change.
- Screen rotation/orientation, locale (language) change, dark/light (night) mode toggle, and app/window size change (multi-window, foldable). Also font scale and hardware keyboard availability.
- What does the system do by default on a configuration change?
- It destroys the current Activity (onDestroy) and creates a fresh instance (onCreate) with the updated Configuration, clearing any state held in Activity/instance fields. Compose recomposes with the new values.
- How is configuration-change recreation different from process death?
- Recreation kills only the Activity instance while the process and its memory live on, so a ViewModel survives. Process death kills the whole app process for memory; the ViewModel is gone and only serialized saved state or disk survives.
- Which state-holder survives a config change but NOT process death, and why?
- ViewModel. It outlives recreation because it is scoped to the retained ViewModelStore in memory, but it lives in the process, so a process kill destroys it.
- What survives system-initiated process death, and how do you persist small UI state across it?
- onSaveInstanceState Bundle, SavedStateHandle (in a ViewModel), and rememberSaveable in Compose all survive because they are serialized to a Bundle the system restores. Real/large data must live in Room or DataStore.
- What state does NOT survive when the user swipes the app away from Recents?
- Neither the ViewModel nor saved instance state survive a user-initiated dismissal (swipe, force-stop, finish()). Only persistent storage (Room/DataStore/files) does; the user expects a clean start.
- Why must saved instance state stay small?
- It is serialized into a Bundle delivered via a Binder transaction; exceeding roughly 1MB throws TransactionTooLargeException. Serialization runs on the main thread, so large payloads cause jank. Store IDs, not whole objects.
- What does android:configChanges do, and why is it not a state-saving solution?
- It tells the system not to recreate the Activity for the listed changes; instead onConfigurationChanged() is called and Compose recomposes. It does nothing for process death, so you still need ViewModel + saved state.
- How do you reproduce system-initiated process death for testing?
- Background the app (Home), then run adb shell am kill <package> (or enable Developer Options > Don't keep activities), and relaunch from Recents. The ViewModel should be gone but SavedStateHandle/rememberSaveable values restored.