Your app is killed for memory; what runs when the user returns?

WHAT THIS TESTS: Whether you understand the difference between the system reclaiming a process and a configuration change, and whether you architect state restoration defensively rather than relying on memory.

A GOOD ANSWER COVERS: First, the OS terminates the process silently when under memory pressure; no Activity or Fragment lifecycle callback is guaranteed beforehand, so onDestroy does not run. When the user later returns, the system creates a new process, calls Application.onCreate, then reconstructs the Activity with onCreate passing a non-null savedInstanceState Bundle, followed by onStart and onResume. Second, contrast this with a configuration change like rotation: there the process stays alive, the Activity is destroyed and recreated, but ViewModel instances survive in memory. After process death, ViewModels are gone entirely unless you use the Saved State module for ViewModel. Third, design guidance: persist lightweight UI state such as scroll position or form input via SavedStateHandle or onSaveInstanceState, keep business data and large objects in repositories backed by persistent storage or disk cache, never store bitmaps or large lists in a Bundle to avoid TransactionTooLargeException, and test process death explicitly with adb shell am kill or by enabling background process limits rather than only using Do Not Keep Activities.

COMMON WRONG ANSWERS: Saying onStop or onDestroy is called before the OS kills the process. Asserting that ViewModels automatically survive process death without SavedState. Treating process death and configuration changes as identical scenarios. Storing heavy objects in savedInstanceState. Relying on static singletons to hold user progress across process recreation.

LIKELY FOLLOW-UPS: How does SavedStateHandle interact with ViewModel scoping? What are the exact Bundle size limits and what happens when you exceed them? How do you handle this in Jetpack Compose with rememberSaveable versus ViewModel? What happens to a foreground service or WorkManager task when its hosting process is killed? How would you restore navigation stack state after process death?

ONE CONCRETE EXAMPLE: A ride-sharing app displays a route map with user-selected pickup and drop-off pins. If the process dies, the app should not cache the decoded route bitmap or large place objects in savedInstanceState. Instead it stores only the two place IDs and camera position in SavedStateHandle. On recreation, the Activity reads those IDs, fetches route data from the repository or network, and re-renders the map.

Source: developer.android.com