Android Fundamentals with Java

Activities & the Activity Lifecycle

18 min Lesson 4 of 12

Activities & the Activity Lifecycle

An Activity is the fundamental building block of an Android user interface. Every screen the user sees — a login form, a map, a settings page — is almost always backed by an Activity. But unlike a desktop window that simply stays open until the user closes it, an Android Activity is at the mercy of the operating system. The OS can pause it, stop it, or even destroy it and recreate it, at any time and for many reasons: an incoming phone call, the user rotating the screen, the system needing RAM. The Activity Lifecycle is Android's formal contract for exactly when each of these transitions happens and what you are expected to do in response.

Understanding this contract is not optional. Get it wrong and your app leaks memory, loses user data on rotation, plays audio in the background when it should be silent, or crashes with a NullPointerException because you referenced a UI widget that no longer exists. Get it right and your app feels solid and professional regardless of what the OS throws at it.

The Six Core Lifecycle Callbacks

Android calls a set of template methods on your Activity subclass as it moves through its states. You override the ones you need. The six you must know are:

onCreate(Bundle savedInstanceState) — Called once when the Activity is first created (or re-created after being killed). This is where you inflate your layout, bind views, restore saved state, and do one-time setup. Always call super.onCreate() first.
onStart() — The Activity is about to become visible. Lightweight initialization that should run every time the screen becomes visible goes here.
onResume() — The Activity is in the foreground and receiving user input. Animations, camera streams, sensors, and anything that consumes power should be started here.
onPause() — Another Activity is about to take focus (e.g. a dialog, an incoming call). This is the last guaranteed callback if the system kills your process. Commit critical unsaved data here. Keep it fast — the new Activity cannot start until onPause() returns.
onStop() — The Activity is no longer visible. Release heavier resources (database cursors, broadcast receivers, network connections). Note: on API 28+ the system can kill the process without calling onDestroy() after this.
onDestroy() — The Activity is being torn down, either because the user finished it or because the system needs memory. Release any remaining resources. Do not rely on this being called.

There are also two re-entry callbacks:

onRestart() — Called after onStop() when the user navigates back to the Activity (before onStart()). Rare but useful for resetting transient state.
onSaveInstanceState(Bundle outState) — Called before the Activity may be destroyed so you can save lightweight UI state (scroll position, text field contents). The bundle is passed back to onCreate() when the Activity is recreated.

Lifecycle State Machine

Think of the Activity as moving through three nested zones:

Entire lifetime: onCreate → … → onDestroy
Visible lifetime: onStart → … → onStop
Foreground lifetime: onResume → … → onPause

The most important pair is onResume / onPause. Everything that must run only while the Activity has the user's full attention is acquired in onResume and released in onPause. If you acquire a resource in onCreate but forget to release it in onPause, you will hold it even when another Activity is in the foreground.

A Concrete Activity Skeleton

package com.example.lifecycle;

import android.os.Bundle;
import android.util.Log;
import androidx.appcompat.app.AppCompatActivity;

public class MainActivity extends AppCompatActivity {

    private static final String TAG = "MainActivity";

    // Called once when the Activity is created (or re-created after kill)
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);          // ALWAYS first
        setContentView(R.layout.activity_main);      // inflate the layout

        if (savedInstanceState != null) {
            // Restore state saved in onSaveInstanceState()
            String restoredText = savedInstanceState.getString("user_input", "");
            Log.d(TAG, "Restored: " + restoredText);
        }

        Log.d(TAG, "onCreate");
    }

    @Override
    protected void onStart() {
        super.onStart();
        Log.d(TAG, "onStart -- Activity visible");
    }

    @Override
    protected void onResume() {
        super.onResume();
        Log.d(TAG, "onResume -- Activity in foreground, start sensors / animation");
        // e.g. startCamera(); startLocationUpdates();
    }

    @Override
    protected void onPause() {
        super.onPause();
        Log.d(TAG, "onPause -- about to lose focus, commit critical data");
        // e.g. saveUserProgress(); stopCamera();
    }

    @Override
    protected void onStop() {
        super.onStop();
        Log.d(TAG, "onStop -- no longer visible, release heavy resources");
        // e.g. unregisterReceiver(); closeDatabase();
    }

    @Override
    protected void onDestroy() {
        super.onDestroy();
        Log.d(TAG, "onDestroy");
        // final cleanup — not guaranteed to be called!
    }

    // Save lightweight UI state before the Activity may be killed
    @Override
    protected void onSaveInstanceState(Bundle outState) {
        super.onSaveInstanceState(outState);
        outState.putString("user_input", "some text the user typed");
        Log.d(TAG, "onSaveInstanceState");
    }
}

Always call the super version of every lifecycle callback. The framework wires up its own logic (ViewModel stores, Fragment managers, WindowDecor) inside the super calls. Skipping them causes subtle, hard-to-debug failures — and in some cases an immediate exception.

The Rotation Problem — Why Recreate Matters

Screen rotation is the scenario that trips up most Android beginners. When the user rotates the device, Android destroys and re-creates your Activity by default. The call sequence is:

onPause()
onStop()
onSaveInstanceState() (your chance to save UI state)
onDestroy()
onCreate(savedInstanceState) — with the bundle you filled in step 3
onStart()
onResume()

This means any data you stored in a field on the Activity object is gone after rotation unless you save it. The Bundle mechanism handles small, serializable values. For larger objects (network responses, ViewModels), use ViewModel from the AndroidX Lifecycle library — ViewModel survives rotation and is covered in depth in the data management tutorial.

Do not set android:configChanges to suppress rotation handling. Many tutorials suggest adding android:configChanges="orientation|screenSize" to the manifest to prevent recreation. This bypasses the system and makes your layout stale on fold/unfold events, multi-window transitions, and font-scale changes. Learn to handle recreation correctly instead.

Practical Rules for Each Callback

onCreate: inflate layout, bind views, restore Bundle state, set up one-time listeners. Do not start ongoing work here.
onResume / onPause: camera, GPS, sensors, media playback, anything that drains the battery or must be exclusive to the foreground app.
onStart / onStop: broadcast receivers tied to visible UI, timers that update the display.
onDestroy: last-resort cleanup only; treat it as unreliable. Use onStop() for anything important.
onSaveInstanceState: primitive values and Parcelables only — keep it small. For anything large, use ViewModel.

Logging Lifecycle Events

While building any new Activity, add Log.d(TAG, "onXxx") calls to every callback and watch Logcat in Android Studio. Seeing the actual sequence while you rotate, background, and return to the app is worth more than any diagram. Filter Logcat by your TAG and the transitions become completely transparent.

Summary

Every Android Activity lives inside a formal lifecycle managed by the operating system. The six callbacks — onCreate, onStart, onResume, onPause, onStop, and onDestroy — form a state machine that tells you exactly when your screen is visible, in focus, or gone. Pair resource acquisition with release: start the camera in onResume, stop it in onPause; register a receiver in onStart, unregister in onStop. Save lightweight UI state in onSaveInstanceState and restore it in onCreate. Respect this contract and your Activity will behave correctly regardless of rotation, incoming calls, or low-memory conditions.