Describe the Android Activity lifecycle and callback order

WHAT THIS TESTS: This question probes whether you understand the Android Activity lifecycle contract and can distinguish between transient stops and full destruction. Interviewers want to see that you know which callbacks the system guarantees and what work belongs in each one, rather than treating the activity as a simple always-running screen. They also care if you recognize that lifecycle boundaries exist so the OS can reclaim resources and that your code must cooperate with those boundaries to avoid crashes and memory leaks.

A GOOD ANSWER COVERS: First, the full launch sequence from onCreate through onStart to onResume when the activity first becomes visible and interactive. Second, the away sequence: onPause when the activity loses focus and should release exclusive resources like the camera, then onStop when it is no longer visible and should tear down heavy UI observers or location updates. Third, the return sequence: onRestart when coming back from the stopped state, followed by onStart and onResume. Fourth, the critical distinction that onCreate and onDestroy only happen if the activity instance is being created or torn down, not during a routine navigation away and back. Fifth, practical responsibilities such as saving transient UI state in onSaveInstanceState and using ViewModel to survive configuration changes without relying solely on the saved instance state Bundle.

COMMON WRONG ANSWERS: A major red flag is claiming that onDestroy always runs when the user presses the home button or navigates to another app; it does not. Another error is saying onCreate runs every time the user returns; that only happens after the activity was destroyed. Candidates also stumble by placing long-running work in onPause, which should complete quickly to avoid janking the next activity, or by confusing onRestart with onRestoreInstanceState. Some also incorrectly believe that onStop is optional or that they can safely ignore it for resource cleanup.

LIKELY FOLLOW-UPS: Expect the interviewer to ask what happens if the system kills your process while the activity is stopped, how onSaveInstanceState relates to ViewModel and saved state, or how the lifecycle changes with multi-window mode and picture-in-picture where onPause may fire without onStop. They may also ask how the Activity lifecycle maps to Compose or Fragment lifecycles and whether you should use lifecycle-aware components to avoid manual callback bookkeeping.

ONE CONCRETE EXAMPLE: Suppose a user opens a photo gallery activity. onCreate inflates the layout and initializes a ViewModel, onStart begins loading thumbnails from the repository, and onResume attaches the scroll listener. The user taps a thumbnail to open a detail activity. The gallery receives onPause, where you pause any video autoplay, then onStop, where thumbnail loading is canceled and the observer is removed to free memory. The user presses back from the detail screen. The gallery receives onRestart, onStart reloads thumbnails if the dataset changed, and onResume reattaches the listener. If the user had pressed home and the system later killed the process to reclaim memory, returning to the app would call onCreate again with a saved Bundle rather than onRestart, which is why you must persist essential state through ViewModel and onSaveInstanceState.