Lifecycle cheat sheet

The lifecycle is where most Android bugs are born. This sheet is the reference; the pages explain why.

TL;DR#

An activity goes onCreate → onStart → onResume, and back down onPause → onStop → onDestroy.
A configuration change destroys and recreates the activity unless you declare otherwise.
onSaveInstanceState is the only state that survives process death.
A ViewModel survives configuration changes, not process death.
In Compose, use LaunchedEffect, DisposableEffect, rememberSaveable and repeatOnLifecycle.

Mental model#

The system owns your activity's lifetime; you own its state. Every callback is the system telling you what it is about to do, not asking permission.

Where the analogy breaks#

Unlike a desktop window, an activity can be destroyed while the user still considers the app open. The process is a cache entry, not a session.

The big picture#

Loading diagram…

Text description of this diagram

An interactive activity lifecycle state machine with event buttons — open, rotate, home, back, open a dialog, start another activity, split screen, and don't keep activities — a live callback log, and a saved-state panel showing what survives each transition.

Deep dive#

Activity#

Callback	When	What to do
`onCreate`	once per instance	inflate layout, set up ViewModel, restore saved state
`onStart`	becoming visible	register visible-only listeners
`onResume`	gaining focus	start camera, sensors, animations
`onPause`	losing focus	pause playback, commit unsaved edits
`onStop`	no longer visible	release heavy resources
`onDestroy`	instance ending	cancel scopes, unregister
`onSaveInstanceState`	before possible death	write small, serialisable state
`onRestoreInstanceState`	after `onStart` on recreation	read it back

What survives what#

State holder	Config change	Process death
Activity field	lost	lost
`onSaveInstanceState` bundle	kept	kept
ViewModel	kept	lost
`SavedStateHandle`	kept	kept
Room / DataStore / file	kept	kept

Fragment#

Fragments add onCreateView, onViewCreated, onDestroyView, and the view lifecycle that is separate from the fragment's own lifecycle. Bind views in onViewCreated and clear the binding in onDestroyView, or you leak the view hierarchy.

Compose#

API	Replaces
`LaunchedEffect(key)`	`onStart` + coroutine scope
`DisposableEffect(key)`	`onStart`/`onStop` pair
`rememberSaveable`	`onSaveInstanceState`
`repeatOnLifecycle(STARTED)`	manually adding/removing observers
`SideEffect`	post-composition work

How it evolved#

2008 →Activities onlyonCreate to onDestroy, one screen each.API 1

2011 →FragmentsA second lifecycle nested inside the first.API 11

2017 →Lifecycle-awareLifecycleOwner and observers make state sync automatic.API 21

2021 →ComposeEffects replace callbacks; the lifecycle becomes a dependency.API 21

Curiosity corner#

onPause returns before onResume of the next activity. It is a handoff, not an end.
Rotation destroys the activity but not the process, which is why a ViewModel survives it.

How long does a broadcast receiver have?Around ten seconds for a foreground broadcast and sixty for a background one. Exceeding it produces an ANR. The limits exist becau…Open card →Why does a link sometimes open in the browser and sometimes in the app?An App Link is verified: the app publishes an assetlinks.json file on its domain that names its signing certificate, and the syste…Open card →

Try it#

Enable "Don't keep activities" in developer options, then background the app. Every state loss you see is a process-death bug you would have shipped.