Trace an Activity's lifecycle when a user navigates away and returns

What's really being asked

This question tests your understanding of resource management, not just rote memorization. The interviewer wants to know if you can build a stable, battery-efficient app. They are listening for your ability to connect lifecycle methods to concrete actions, like releasing a camera in onStop or pausing an animation in onPause. It's a fundamental concept that separates developers who write apps that work from those who write apps that work well and don't crash.

The full answer

A strong answer walks through the specific sequence and explains the purpose of each step. First, the 'away' path: onPause() is called when the Activity is partially obscured (e.g., by a dialog). This is for pausing UI updates or animations. Then, onStop() is called when the Activity is no longer visible. This is the signal to release heavy resources like network connections, sensors, or a video player. The system may also call onSaveInstanceState() around this time to preserve UI state. Second, the 'return' path: onRestart() is called, indicating the Activity is coming back from a stopped state. This is followed by onStart(), where you should re-acquire resources released in onStop(). Finally, onResume() is called right before the Activity becomes interactive again, where you resume anything paused in onPause().

The mistakes people make

The most common mistake is simply listing the methods without explaining their purpose. A major red flag is forgetting onRestart() in the return sequence; many candidates incorrectly jump from a stopped state directly to onStart(). Another error is confusing the roles of onPause() and onStop(). A senior candidate should know that heavy resource cleanup belongs in onStop(), not onPause(), because onPause() execution needs to be extremely fast. Finally, treating onSaveInstanceState as a general-purpose persistence mechanism is wrong; it's for small amounts of transient UI state to survive configuration changes and process death, not for saving user data permanently.

What usually comes next

Expect follow-ups like: "When might onDestroy() not be called?" (Answer: When the system kills the process for memory). "How does a ViewModel change how you handle this?" (Answer: It survives configuration changes, simplifying state management). "What's the difference in lifecycle between launching a new Activity versus pressing the home button?" (Answer: Home button calls onStop, a new Activity might just call onPause if it's translucent).

A concrete example

In a video streaming app, when the user navigates away, onPause() should pause the video playback (player.pause()). Then, onStop() must fully release the video player and its associated decoders (player.release()), as these are very resource-intensive. When the user returns, onRestart() is called, followed by onStart(), where you would re-initialize the player. Finally, onResume() would be the place to call player.play() to resume playback from where it was paused.