The Activity Lifecycle

Welcome to the Intermediate level. Up to now your apps have been small and forgiving. From here on you build apps that behave like the real ones on a phone: they survive a screen rotation, they cope when the user switches to WhatsApp and comes back, and they do not lose a half-typed message because the system needed memory.

All of that depends on one idea: the Activity lifecycle. In this lesson you will learn what happens between the moment the user taps your icon and the moment the system destroys your screen, and you will prove it by building Dessert Clicker, an app that counts how many desserts you have sold and shows a different dessert as sales grow.

This lesson covers the first two items of Unit 4 of Google's official Android Basics with Compose course: Welcome to Unit 4 and Stages of the Activity lifecycle.

By the end you will be able to:

• Name the lifecycle callbacks of an Activity and say when each runs.
• Log lifecycle events with Log.d and read them in Logcat.
• Explain what a configuration change is and why it restarts your Activity.
• Use rememberSaveable to keep state through rotation.
• Explain process death and how it differs from rotation.
• Describe how lifecycle-aware code (collecting data only while the screen is visible) saves battery and data.

Big idea: your app does not control when it starts, pauses or dies. The system does. Your job is to respond to these events correctly and to keep important state somewhere safe.

• State and recomposition (lessons 17 and 18). A composable that reads state redraws when the state changes. remember keeps a value across recompositions but not across the Activity being destroyed.
• MainActivity and setContent (lesson 15). The Activity is the Android component that hosts your Compose UI.
• Logging. Log.d("TAG", "message") writes a debug line you can read in the Logcat window. Android Studio filters it by tag, package and level. You will learn the Logcat window properly in lesson 43, but you only need to type a filter today.
• Kotlin lambdas (lesson 12). Compose callbacks are lambdas.

An Activity is one screen of your app that the system can create, show, hide and destroy. Because phones have little memory and users jump between apps all the time, the system moves your Activity through a set of states. Each move triggers a callback, a function you can override to react.

Think of a shop assistant in a busy market stall. When a customer arrives, the stall is opened (onCreate). The assistant stands ready (onStart), then actively serves (onResume). If another customer walks in front, the assistant pauses (onPause), steps back out of view (onStop) and might eventually be sent home if space is needed (onDestroy).

          app launched
               |
          [ onCreate ]      Activity is created. Build UI, set content.
               |
          [ onStart ]       Visible, but the user cannot interact yet.
               |
          [ onResume ]      In the foreground. Interactive. "Resumed".
               |
   another app / dialog covers part of the screen
               |
          [ onPause ]       Partly visible, not focused.
               |
   completely hidden (user pressed Home, opened another app)
               |
          [ onStop ]        Not visible. Release what you do not need.
               |
        +------+-------------------------+
        |                                |
   user returns                    finish() / system kills
        |                                |
   [ onRestart ]                    [ onDestroy ]
        |                                
   back to onStart

The callbacks at a glance

Two helpful pairs to remember:

• onCreate / onDestroy bracket the entire life of the Activity.
• onStart / onStop bracket the time it is visible.
• onResume / onPause bracket the time it is in the foreground and interactive.

On a modern phone with multi-window mode (two apps side by side), an Activity can be visible but not focused, which is exactly why onStart and onResume are separate.

You will not memorise the diagram by reading it. You learn it by watching it happen. Create a new Empty Activity project called Dessert Clicker (package com.example.dessertclicker).

Open MainActivity.kt and replace its contents with the following. It overrides every callback and logs one line for each.

package com.example.dessertclicker
import android.os.Bundle
import android.util.Log
import androidx.activity.ComponentActivity
import androidx.activity.compose.setContent
import androidx.compose.material3.Text
private const val TAG = "MainActivity"
class MainActivity : ComponentActivity() {
 override fun onCreate(savedInstanceState: Bundle?) {
 super.onCreate(savedInstanceState)
 Log.d(TAG, "onCreate called")
 setContent {
 Text("Dessert Clicker")
 }
 }
 override fun onStart() {
 super.onStart()
 Log.d(TAG, "onStart called")
 }
 override fun onResume() {
 super.onResume()
 Log.d(TAG, "onResume called")
 }
 override fun onPause() {
 super.onPause()
 Log.d(TAG, "onPause called")
 }
 override fun onStop() {
 super.onStop()
 Log.d(TAG, "onStop called")
 }
 override fun onRestart() {
 super.onRestart()
 Log.d(TAG, "onRestart called")
 }
 override fun onDestroy() {
 super.onDestroy()
 Log.d(TAG, "onDestroy called")
 }
}

Every override calls super first. That is mandatory: the parent class does essential work and Android throws an exception if you forget.

Reading the Logcat

1. Run the app on an emulator or a phone.
2. Open View > Tool Windows > Logcat (it is usually a tab at the bottom).
3. In the filter box type tag:MainActivity (the exact query syntax changes between Android Studio versions, but typing the tag usually works).

Experiments

Perform each action and write down what you see:

1. Launch the app. You should see onCreate, onStart, onResume in that order.
2. Press Home. You should see onPause then onStop. The app is not destroyed; it sits in the background.
3. Reopen it from recents. You should see onRestart, onStart, onResume. Note there is no onCreate: the same Activity instance came back.
4. Press Back on the main screen. You should see onPause, onStop, onDestroy. The Activity is finished.
5. Rotate the device (on the emulator use the rotate buttons in the side panel). You will see the full tear-down and a fresh start: onPause, onStop, onDestroy, then onCreate, onStart, onResume.

That fifth result surprises most beginners. Rotating the phone destroys and recreates your Activity. We will fix the consequences shortly.

Experiment: pull down the notification shade without covering the app completely. On many versions you will see only onPause but no onStop, because the app is still partly visible. Compare that to opening a full-screen dialog.

The official course gives you the starting art and layout. We will build our own simple version with text only, so you do not need any downloads.

The rules of the app:

• A big button shows the current dessert's name.
• Each tap sells one dessert and earns the dessert's price.
• As the number sold passes certain thresholds, the dessert changes.

The data

Create Dessert.kt:

package com.example.dessertclicker
data class Dessert(
 val name: String,
 val price: Int,
 val startProductionAmount: Int
)
val desserts = listOf(
 Dessert("Cupcake", price = 5, startProductionAmount = 0),
 Dessert("Donut", price = 10, startProductionAmount = 5),
 Dessert("Eclair", price = 15, startProductionAmount = 20),
 Dessert("Froyo", price = 30, startProductionAmount = 50),
 Dessert("Gingerbread", price = 50, startProductionAmount = 100)
)
fun determineDessertToShow(dessertsSold: Int): Dessert {
 var dessertToShow = desserts.first()
 for (dessert in desserts) {
 if (dessertsSold >= dessert.startProductionAmount) {
 dessertToShow = dessert
 } else {
 break
 }
 }
 return dessertToShow
}

determineDessertToShow walks the list; the last dessert whose startProductionAmount has been reached wins. With dessertsSold = 7 the answer is Donut. With dessertsSold = 120 it is Gingerbread.

The screen

Now write the composable. It keeps two numbers in state:

import androidx.compose.foundation.layout.Arrangement
import androidx.compose.foundation.layout.Column
import androidx.compose.foundation.layout.fillMaxSize
import androidx.compose.foundation.layout.padding
import androidx.compose.material3.Button
import androidx.compose.material3.MaterialTheme
import androidx.compose.material3.Text
import androidx.compose.runtime.Composable
import androidx.compose.runtime.getValue
import androidx.compose.runtime.mutableIntStateOf
import androidx.compose.runtime.remember
import androidx.compose.runtime.setValue
import androidx.compose.ui.Alignment
import androidx.compose.ui.Modifier
import androidx.compose.ui.unit.dp
@Composable
fun DessertClickerScreen(modifier: Modifier = Modifier) {
 var revenue by remember { mutableIntStateOf(0) }
 var dessertsSold by remember { mutableIntStateOf(0) }
 val currentDessert = determineDessertToShow(dessertsSold)
 Column(
 modifier = modifier
 .fillMaxSize()
 .padding(24.dp),
 verticalArrangement = Arrangement.Center,
 horizontalAlignment = Alignment.CenterHorizontally
 ) {
 Button(
 onClick = {
 revenue += currentDessert.price
 dessertsSold++
 }
 ) {
 Text(
 text = currentDessert.name,
 style = MaterialTheme.typography.headlineMedium
 )
 }
 Text(
 text = "Desserts sold: $dessertsSold",
 modifier = Modifier.padding(top = 24.dp),
 style = MaterialTheme.typography.titleLarge
 )
 Text(
 text = "Total revenue: ₦$revenue",
 style = MaterialTheme.typography.titleLarge
 )
 }
}

Call it in setContent, inside your theme and a Scaffold as in lesson 21:

setContent {
 DessertClickerTheme {
 Scaffold(modifier = Modifier.fillMaxSize()) { innerPadding ->
 DessertClickerScreen(modifier = Modifier.padding(innerPadding))
 }
 }
}

(Use your own theme name if you named the project differently, and add the Scaffold imports from lesson 21.)

Run it. Tap the button seven times. The button should read Donut and the counter 7.

Now rotate the phone. Everything resets to zero. Revenue and sales are gone, and the button says Cupcake again.

A configuration change is something about the device or environment that changes while your app is running, such as:

• screen rotation
• switching between light and dark theme
• changing the system language or font size
• plugging in a keyboard
• changing the window size in split-screen or on a foldable

By default, Android destroys and recreates the Activity so it can reload resources suited to the new configuration, for example a different layout for landscape. All your remembered values disappear with the old Activity. This default exists for good reasons, but it hurts if you do not plan for it.

Why does remember fail? remember stores a value in the composition, and the composition belongs to the Activity instance. A new Activity instance means a new, empty composition.

The fix for simple values: rememberSaveable

rememberSaveable works like remember, but it also stores the value in the saved instance state, a small Bundle that Android keeps for you across recreation. Change the two lines:

import androidx.compose.runtime.saveable.rememberSaveable
var revenue by rememberSaveable { mutableIntStateOf(0) }
var dessertsSold by rememberSaveable { mutableIntStateOf(0) }

Run, tap seven times, rotate. The counters now survive. The Activity still goes through onDestroy and onCreate, but the numbers are restored.

What can rememberSaveable store?

Anything that can go into a Bundle: numbers, strings, booleans, lists of those, and classes marked Parcelable or Serializable. For other types you write a custom saver (lesson 54). mutableIntStateOf is handled automatically.

Because a Bundle is held by the system, keep it small. The limit is around 1 MB for all saved state across the whole app and a transaction that is too large throws TransactionTooLargeException. Never put a bitmap or a 5,000-item list in saved state. Save an ID or a search query and reload the rest.

Rotation is not the only danger. Suppose the user opens Dessert Clicker, taps a few times, then switches to Facebook, YouTube and a game. The system is low on memory, so it kills your whole app process while it is in the background. Your Activity gets no onDestroy call in that case, because the process is simply removed.

When the user returns, Android recreates the Activity and hands back the saved instance state, so values saved with rememberSaveable return, but anything held only in remember or in ordinary variables is gone.

Testing process death

You can simulate it without waiting for low memory:

1. Run the app and tap a few times.
2. Press Home.
3. In Android Studio's Logcat or Running Devices toolbar, use Terminate Application (the red square), or run this in the terminal:

adb shell am kill com.example.dessertclicker

4. Reopen the app from the launcher or recents.

adb shell am kill only kills a background process, which is what makes it a realistic simulation. If the app is in the foreground it does nothing.

The summary:

The last row matters: saved state is for system-initiated recreation. If the user deliberately closes the app, they expect a fresh start.

Some things should only happen while the screen is visible: listening to location updates, refreshing a live score, playing a video. If you start them in onCreate and forget to stop them, they keep draining battery and mobile data in the background.

You will use two tools for this throughout the course:

1. Lifecycle callbacks. Start in onStart, stop in onStop.
2. Lifecycle-aware components. Objects that watch the lifecycle for you.

In Compose, the simplest lifecycle-aware tool for data streams is collectAsStateWithLifecycle(), which collects a Kotlin Flow only while the screen is at least started:

import androidx.lifecycle.compose.collectAsStateWithLifecycle
val uiState by viewModel.uiState.collectAsStateWithLifecycle()

You will use it in lessons 24 and 25. It stops collecting when the app goes to the background (below the STARTED state) and resumes when it returns. Plain collectAsState() keeps collecting even when the app is hidden. For streams that touch the network, database or sensors, prefer the lifecycle-aware version.

For imperative code you can observe the lifecycle from a composable with LifecycleEventEffect, which runs a block when a given lifecycle event occurs:

import androidx.compose.runtime.Composable
import androidx.lifecycle.Lifecycle
import androidx.lifecycle.compose.LifecycleEventEffect
import android.util.Log
@Composable
fun LifecycleLogger() {
 LifecycleEventEffect(Lifecycle.Event.ON_START) {
 Log.d("LifecycleLogger", "Screen became visible")
 }
 LifecycleEventEffect(Lifecycle.Event.ON_STOP) {
 Log.d("LifecycleLogger", "Screen is hidden")
 }
}

This needs the androidx.lifecycle:lifecycle-runtime-compose dependency, which the Empty Activity template normally already includes through version-catalog entries. If Android Studio cannot resolve the import, add it (look up the latest stable version rather than copying a number from a tutorial, and see lesson 28 for how to add dependencies).

Mistake #1: Using remember for important state. What happens: counters, typed text and the selected tab reset on rotation. The fix: rememberSaveable for small simple values, or a ViewModel (lesson 24) for larger screen state.

Mistake #2: Forgetting super. The wrong code: an onStart override without super.onStart(). What happens: the app crashes with SuperNotCalledException. The fix: call super first in every lifecycle override.

Mistake #3: Doing slow work in onPause. What happens: the next screen appears late, because onPause must finish before the next Activity can resume. The fix: keep onPause fast. Do heavier clean-up in onStop.

Mistake #4: Assuming onDestroy always runs. What happens: saving data only in onDestroy loses it when the process is killed. The fix: save important data early (as the user works, or in onStop) and use saved instance state for UI state.

Mistake #5: Putting large objects in saved state. What happens: TransactionTooLargeException. The fix: save small identifiers and reload.

Mistake #6: Locking the orientation to avoid the problem. What happens: setting screenOrientation="portrait" hides rotation bugs, but font-size, language, dark-mode and window-resize changes still recreate the Activity, and on large screens the setting may be ignored. The fix: handle recreation properly.

Mistake #7: Starting work in onCreate and never stopping it. What happens: a location or network listener runs while the app is hidden, draining battery. The fix: tie work to onStart/onStop, use lifecycle-aware collection, or a LifecycleEventEffect.

Mistake #8: Testing only on a fast emulator with plenty of memory. What happens: process death never occurs while you test, and the bug appears on a budget phone. The fix: test with adb shell am kill and the Don't keep activities developer option (Settings > Developer options), which destroys each Activity as soon as you leave it.

Question 1. In what order do the callbacks run when an app is launched?

Question 2. The user presses Home. Which callbacks run, and is the Activity destroyed?

Question 3. Why does rotating the phone reset a counter stored with remember?

Question 4. What is the difference between rotation and process death for state saved with rememberSaveable?

Question 5. Why is collectAsStateWithLifecycle() preferred over collectAsState() for Android data streams?

Go deeper: official resources

• Android Basics with Compose, Unit 4, Pathway 1: Architecture and the ViewModel: the official pathway containing Welcome to Unit 4 and Stages of the Activity lifecycle.
• Android Basics with Compose course page: all units.
• App architecture guide: where lifecycle-aware design leads, which you will use in lessons 24 and 25.