Android's Activity Lifecycle: A Screen's Journey

Why it exists

Android runs on resource-constrained devices where the OS must aggressively manage memory. It can terminate background apps at any time. The Activity Lifecycle provides a predictable contract for your app to save its state before being killed and restore it gracefully when the user returns, ensuring a seamless experience despite system-level interruptions.

The mental model

Think of an Activity as a single screen in your app. Its lifecycle is a state machine with a series of states: Created, Started, Resumed, Paused, Stopped, and Destroyed. The Android OS pushes your Activity through these states in response to user actions and system events. You don't control the transitions, but you can react to them by overriding callback methods like onCreate() or onPause().

How it works

When an Activity launches, the OS calls a sequence of methods: onCreate() for one-time setup, then onStart() to make it visible, and finally onResume() to bring it to the foreground and make it interactive. If another Activity partially obscures it (like a permission dialog), onPause() is called. If the user navigates away entirely, onPause() and then onStop() are called. If the user returns, the OS calls onRestart(), onStart(), and onResume(). If the app is finished by the user or killed by the system, onPause(), onStop(), and finally onDestroy() are called to clean up resources.

When to use it

You use the lifecycle constantly; it's not optional. The key is overriding the right method for the right job. Use onCreate() for essential, one-time initializations like setting the layout view and creating ViewModels. Use onStart() and onStop() to manage resources that are only needed when the UI is visible, like registering a broadcast receiver. Use onResume() and onPause() for tasks that require exclusive access, like using the camera.

When not to use it

Do not use lifecycle callbacks to store user data or complex UI state directly in Activity properties. When the screen rotates, the Activity is destroyed and recreated by default, wiping out that data. Instead, use a ViewModel, which is designed to survive these configuration changes. Crucially, never perform long-running operations like network requests or heavy database queries in any lifecycle callback on the main thread, as this will freeze the app and trigger an 'Application Not Responding' (ANR) error.

One canonical example

Consider a video player app. In onCreate(), you would initialize the player library. In onStart(), you might prepare the video source. In onResume(), you begin playback. If a phone call interrupts the app, onPause() is called, and you must pause the video. When the user returns after the call, onResume() is called again, and you resume playback. When the user navigates to another screen, onStop() is called, and you should release the player's hardware resources. Finally, in onDestroy(), you clean up any remaining connections or listeners.