Activities and the lifecycle

The thing that happens when you rotate

Open your app from Part 0. Turn the phone sideways. The screen redraws.

What actually happened is much more violent than it looked. Android destroyed your screen — threw the whole object away — built a brand new one, and drew that instead. Everything the old one was holding in memory went in the bin.

If your app had a score, a half-typed message, or a scroll position, it is gone. Not hidden. Gone.

This is not a bug and it is not going to be fixed. It is the single most important consequence of the lifecycle, and once you understand why Android does it, an entire category of "why did my app forget things?" questions answers itself.

What an Activity actually is

An Activity is two things at once, and beginners usually only hear about the first.

1. One screen. A thing with a window, that the user sees.
2. A doorway. The unit Android is able to start from outside — from the launcher, from a notification, from another app's share sheet.

That second job is why an Activity has to be declared in the manifest: Android needs a public list of the doors it is allowed to knock on.

In the old days apps had dozens of Activities — one per screen. Modern Compose apps usually have one. Dice Duel has one. Pocket Notes has one. Focus Flow has one, with several screens inside it, switched by Navigation in Part 4. So an Activity is best thought of as "the window your app lives in", not "a page".

The six moments

Android announces every stage of the shop's day by calling a function on your Activity. You override the ones you care about, and ignore the rest.

Here is an Activity with all six, printing as it goes. Everything is real; you can paste it.

1class MainActivity : ComponentActivity() {
2
3  override fun onCreate(state: Bundle?) {
4    super.onCreate(state)
5    println("LIFE onCreate")
6    setContent { AppRoot() }
7  }
8
9  override fun onStart() {
10    super.onStart()
11    println("LIFE onStart")
12  }
13
14  override fun onResume() {
15    super.onResume()
16    println("LIFE onResume")
17  }
18
19  override fun onPause() {
20    super.onPause()
21    println("LIFE onPause")
22  }
23
24  override fun onStop() {
25    super.onStop()
26    println("LIFE onStop")
27  }
28
29  override fun onDestroy() {
30    super.onDestroy()
31    println("LIFE onDestroy")
32  }
33}

Two rules apply to every one of these:

• Always call super. The parent class has real work to do in each of them. Forget it and Android throws SuperNotCalledException and closes your app — see the Error Doctor.
• Never do anything slow. Every one of these runs on the main thread. A slow onCreate is a slow launch, and a slow onPause is a phone that feels sticky when you press Home.

The paths through the lifecycle

There are only three journeys worth memorising.

Starting up

onCreate -> onStart -> onResume

Leaving and coming back

onPause -> onStop -> onRestart -> onStart -> onResume

Note what is missing: no onCreate. Pressing Home and returning does not rebuild anything. The Activity was alive the whole time, just hidden.

Rotating

1onPause -> onStop -> onDestroy
2onCreate -> onStart -> onResume

Destroyed and rebuilt, in one continuous motion, in under a frame or two.

Why rotation destroys your screen

This looks insane until you know the reason, and then it is obviously right.

Turning the phone is a configuration change. So is switching to dark mode, changing the system language, or making the system font bigger. Every one of those may mean different resources apply. A different layout for landscape. A different theme for night. Different text for French.

Android's answer is brutally simple: rather than trying to patch a live screen, throw it away and build a new one, which will naturally pick up the right resources on its way up. One code path, no special cases, nothing half-updated.

The price is that anything held in your Activity's memory dies with it.

Process death — the bigger version of the same problem

Rotation destroys one screen. Process death destroys everything.

When you leave your app and go and use three other apps, Android may need the memory. It quietly kills your entire process. Your app is gone. No warning, no callback you can rely on.

Then the user taps your icon expecting to be back where they were, and Android tries to fake it: it starts a fresh process and hands your onCreate a small parcel called saved instance state — the state: Bundle? parameter you have been passing to super this whole time.

That is why the parameter is nullable. null means "brand new". Not null means "you have been here before, here is what I kept".

The Bundle is for small things only: a scroll position, a selected tab, a few characters of text. Real data belongs in a database or a file. Part 4 builds this properly with ViewModel and Room, and Lesson 4.8 comes back to process death specifically.

Where Compose fits

setContent { } installs a Compose screen inside the Activity's window. From that point on, the inside of your app is Compose's business — but the Activity's lifecycle still rules everything.

The practical consequence you will feel first: a value held in a Compose remember block survives recomposition, but not the Activity being destroyed. Rotate, and it resets.

1// Survives recomposition. Does NOT survive rotation.
2var score by remember { mutableStateOf(0) }
3
4// Survives rotation too — Android saves it in the
5// Bundle for you.
6var score by rememberSaveable { mutableStateOf(0) }

One extra word, rememberSaveable, and the counter survives. Lesson 3.5 explains both properly. For now the important thing is knowing why the first one forgets: the Activity died.