Quick answer: The Android lifecycle is the set of states your app’s screen passes through: created → visible → in the foreground → background → destroyed. Android calls specific methods (or Compose equivalents) as your screen moves between them, and the system may kill background apps to free memory at any time. Understanding this solves the two classic beginner bugs: data vanishing when you rotate the phone, and crashes from doing work at the wrong moment.
The lifecycle callbacks
| Callback | Fires when | What belongs here |
|---|---|---|
onCreate() | Screen created | One-time setup: layout, view models, intent data |
onStart() | Becoming visible | Light UI prep |
onResume() | Foreground, interactive | Start/resume playback, sensors, location updates |
onPause() | Losing focus (partially visible) | Pause animations, save quick state — be fast here |
onStop() | No longer visible | Release heavier resources, save data |
onDestroy() | Being torn down | Final cleanup (not guaranteed if the system kills you) |
See it yourself: open Logcat, add a Log.d("LIFE", "onCreate") line in each callback, run, and then rotate the phone. You will watch the whole teardown/rebuild happen live — rotation recreates the activity by design.
The two classic bugs, and the modern fixes
- Rotation wipes my screen data: activity recreation destroys instance fields. Fix with a ViewModel — it survives configuration changes and holds your screen’s data.
- Crash after leaving and returning: work started in one state (a camera handle opened in
onCreate) crashed when reused in another. Fix: acquire resources in the matching callback (onResume/release inonPause), or better, let lifecycle-aware components handle it.
class CounterViewModel : ViewModel() {
var count by mutableStateOf(0)
private set
fun increment() { count++ }
}With Compose, most lifecycle pain disappears: rememberSaveable keeps small values across rotation, and ViewModels hold the rest. The deeper rule to internalize: never trust the process to stay alive — save meaningful state as it happens (onStop at the latest), not in onDestroy, because the system can kill you without calling it.
If you want these habits reviewed as you build, Ampersand Academy teaches Android development one-to-one, from lifecycle to published apps.
Frequently asked questions
What is the Android activity lifecycle?
The sequence of states every screen passes through – created, started, resumed (foreground), paused, stopped, destroyed – with a callback method for each. Android calls them as the user navigates, rotates the device, or leaves the app.
Why does my app lose data when the screen rotates?
Rotation destroys and recreates the activity by design to load new resources. Store screen data in a ViewModel, which survives the recreation, or use rememberSaveable for small Compose values.
What is the difference between onPause and onStop?
onPause fires when the screen loses focus but may still be partly visible (a dialog on top); onStop fires when it is completely hidden. Put quick pauses in onPause and heavier releases in onStop.
Is onDestroy guaranteed to be called?
No. Android can kill a backgrounded process without any callbacks to free memory. Save important state in onStop or earlier – never rely on onDestroy for critical persistence.
What is a ViewModel in Android?
A lifecycle-aware holder for screen data that survives configuration changes like rotation. UI code observes it, so data outlives the activity being recreated.