Activity Lifecycle

The Android Activity lifecycle defines the sequence of states an Activity transitions through from creation to destruction. The system invokes specific callback methods at each transition, giving the application an opportunity to initialize resources, save state, release resources, and respond to visibility changes. Mismanaging these callbacks leads to memory leaks, lost user state, and crashes on configuration changes. By the end of this lesson, you will be able to:

• Trace the complete callback sequence from onCreate() through onDestroy().
• Explain what each callback signals about the Activity's visibility and interactivity.
• Handle multi window and Picture in Picture lifecycle transitions correctly.
• Describe how configuration changes trigger destruction and recreation.
• Identify the correct callbacks for acquiring and releasing resources.
• Apply onSaveInstanceState() to preserve transient UI state across recreation.

Creation and Initialization

When the system creates an Activity, it calls onCreate() exactly once per instance. This is where you inflate the layout, bind views or set the Compose content, initialize ViewModels, and restore any state from a previous instance via the savedInstanceState Bundle.

override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    setContentView(R.layout.activity_main)

    val restoredQuery = savedInstanceState?.getString("search_query")
    viewModel.initialize(restoredQuery)
}

After onCreate(), the system calls onStart(). At this point the Activity is visible but not yet in the foreground. The window is drawn, but another Activity may still be covering part of the screen. onStart() is the right place to register UI related observers or begin animations that should run whenever the Activity is visible.

onResume() follows onStart() and marks the Activity as fully interactive. The Activity is in the foreground, receiving user input. This is where you resume camera previews, start sensor listeners, or begin playback that should only happen when the user is actively interacting.

It is important to note that onStart() and onResume() both run before any view is drawn to the screen. If you need to perform work after the first frame is rendered (measuring view sizes, starting animations from actual positions), use View.post() or View.doOnLayout() rather than relying on lifecycle callbacks alone.

override fun onResume() {
    super.onResume()
    binding.root.doOnLayout {
        startEnterAnimation()
    }
}

Pausing, Stopping, and Restarting

When a dialog, a translucent Activity, or a multi window split partially obscures the Activity, the system calls onPause(). The Activity is still visible but no longer in the foreground. You should pause operations that should not continue when the user is not directly interacting, such as video playback or intensive animations.

override fun onPause() {
    super.onPause()
    videoPlayer.pause()
}

If the Activity becomes completely invisible (the user navigates to another Activity or presses Home), the system calls onStop(). At this point, the Activity is no longer visible at all. Release resources that are not needed while invisible, such as broadcast receivers registered for UI updates, or large bitmaps held for display.

When the user returns to a stopped Activity (via the back stack or recents), the system calls onRestart() followed by onStart() and onResume(). onRestart() is only called when the Activity is coming back from the stopped state, not after initial creation. This distinction allows you to handle reconnection logic that only applies to returning from the background.