lifecycleScope: What It Is, Lifecycle Binding, and How It Works in Android

What Is lifecycleScope in Android?

lifecycleScope is an extension property on the LifecycleOwner interface (Activity, Fragment, Service) that provides a ready-made CoroutineScope tied to the full lifecycle of the component. When the LifecycleOwner reaches the DESTROYED state, lifecycleScope automatically cancels all active coroutines.

// In Fragment or Activity
lifecycleScope.launch {
    delay(1000)
    showSnackbar("Hello!")
}

Unlike viewModelScope, lifecycleScope is cancelled every time the LifecycleOwner is destroyed — including screen rotation. This makes it ideal for operations that should only live while a specific screen is visible.

Where lifecycleScope Is Available

lifecycleScope is available everywhere there is a LifecycleOwner:

• Activity — AppCompatActivity inherits LifecycleOwner
• Fragment — Fragment inherits LifecycleOwner
• LifecycleService — a service with a lifecycle
• ProcessLifecycleOwner — the lifecycle of the entire application
• Custom LifecycleOwner — any object implementing LifecycleOwner

How lifecycleScope Works: Lifecycle and Automatic Cancellation

The automatic cancellation mechanism of lifecycleScope is based on subscribing to Lifecycle events. When the Lifecycle drops below CREATED to DESTROYED, the scope is cancelled.

Lifecycle States

Internal Structure of lifecycleScope

lifecycleScope is created as CoroutineScope(SupervisorJob() + Dispatchers.Main.immediate) and stored inside the Lifecycle. When the Lifecycle transitions to the DESTROYED state, scope.cancel() is called. The mechanism is implemented via LifecycleEventObserver, which subscribes to lifecycle events on the first access to the scope.

Behavior on Rotation

When the screen is rotated, the Activity is destroyed (onDestroy) and recreated. lifecycleScope is cancelled together with the old Activity, and a new scope instance is created for the new Activity. This is a fundamental difference from viewModelScope, which survives rotation.

lifecycleScope API: launch, launchWhen, and repeatOnLifecycle

The lifecycle library provides several ways to launch coroutines through lifecycleScope. Let’s look at the evolution of the API from deprecated methods to modern ones.

lifecycleScope.launch — Basic Launch

The simplest way is lifecycleScope.launch { ... }. The coroutine starts immediately and is cancelled at DESTROYED. However, it can execute code even when the UI is not visible (e.g., in the background after onStop). This is not always desirable.

Deprecated: launchWhenCreated / launchWhenStarted / launchWhenResumed

These methods paused the coroutine execution when the Lifecycle dropped below the specified state and resumed it upon return. However, they were marked as @Deprecated in lifecycle-runtime-ktx 2.6.0 because:

• They did not cancel the coroutine — only paused it
• They led to an accumulation of suspended coroutines consuming memory
• They created race conditions during fast state switching

Modern API: repeatOnLifecycle

repeatOnLifecycle is Google’s recommended way to launch coroutines synchronized with the lifecycle. It cancels and restarts the coroutine every time the Lifecycle reaches the specified state.

lifecycleScope.launch {
    repeatOnLifecycle(Lifecycle.State.STARTED) {
        viewModel.uiState.collect { state ->
            updateUI(state)
        }
    }
}

The coroutine passed to repeatOnLifecycle starts when the Lifecycle reaches STARTED and cancels when it drops below STARTED. When it returns to STARTED, the coroutine restarts from scratch. This is safe and efficient — no coroutines are left suspended.

flowWithLifecycle — For Flow

For collecting data from Flow with lifecycle awareness, there is the flowWithLifecycle operator. It automatically stops and resumes collection when the Lifecycle state changes:

viewModel.uiState
    .flowWithLifecycle(lifecycle, Lifecycle.State.STARTED)
    .onEach { state -> updateUI(state) }
    .launchIn(lifecycleScope)

The flowWithLifecycle operator is the most concise way to safely subscribe to a Flow in the UI layer.

lifecycleScope Usage Examples

Let’s look at three real-world scenarios for using lifecycleScope in an Android application with Kotlin.

Example 1: Subscribing to Location Updates Only When the Screen Is Visible

class MapFragment : Fragment() {

    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        super.onViewCreated(view, savedInstanceState)

        lifecycleScope.launch {
            repeatOnLifecycle(Lifecycle.State.STARTED) {
                locationProvider.observeLocation().collect { loc ->
                    updateMapMarker(loc)
                }
            }
        }
    }
}

The coroutine starts when the fragment becomes visible (STARTED) and cancels when it leaves the screen (STOPPED). If the user switches to another app, Location updates do not drain the battery.

Example 2: Starting an Animation on Fragment Start

lifecycleScope.launch {
    repeatOnLifecycle(Lifecycle.State.RESUMED) {
        animateFadeIn(titleView)
        delay(200)
        animateSlideUp(contentView)
    }
}

The animation runs only when the fragment is in the foreground (RESUMED). If the user minimizes the app during the animation, the coroutine is cancelled, and when they return, the animation starts over.

Example 3: Periodic Data Sync on a Visible Screen

lifecycleScope.launch {
    repeatOnLifecycle(Lifecycle.State.STARTED) {
        while (isActive) {
            syncData()
            delay(30_000L)
        }
    }
}

Data is synchronized every 30 seconds, but only when the screen is visible. isActive checks whether the coroutine has been cancelled, providing a safe way to exit the loop when leaving the screen.

lifecycleScope vs viewModelScope: Use Cases

Both scopes are tied to the lifecycle, but to different aspects of it. Understanding the difference is critical for building a proper Android application architecture.

Key Difference

viewModelScope is tied to the ViewModel, which survives screen rotation. lifecycleScope is tied to the LifecycleOwner (Activity/Fragment), which is destroyed and recreated on rotation. This determines their use cases.

When to Use lifecycleScope

• Subscribing to system events (Location, sensors, camera)
• Animations and UI effects tied to a specific screen
• Chunked data loading based on screen visibility
• Operations that should stop when leaving the screen

When to Use viewModelScope

• Loading data from a Repository
• Business logic that should survive rotation
• Caching and data processing
• Any operation whose result is needed after rotation

Combined Usage

In practice, a combination of both scopes is common: viewModelScope loads data and manages state, while lifecycleScope subscribes to Flow from the ViewModel with lifecycle awareness. This separation of responsibilities is considered best practice in modern Android development.

Common Mistakes When Working with lifecycleScope

Let’s look at four of the most common mistakes developers make when using lifecycleScope.

Mistake 1: Using lifecycleScope Instead of viewModelScope for Data Loading

If you launch data loading in lifecycleScope.launch, the coroutine will be cancelled on screen rotation, and the data will have to be reloaded. Use viewModelScope for long-lived operations. lifecycleScope is only for UI-bound tasks.

Mistake 2: Collecting Flow Without repeatOnLifecycle

Directly calling viewModel.someFlow.collect { ... } inside lifecycleScope.launch continues collecting data even when the screen is not visible. This can lead to UI updates in the background and unnecessary overhead. Always use repeatOnLifecycle or flowWithLifecycle.

Mistake 3: Forgetting About Cancellation When Leaving the Screen

Although lifecycleScope is cancelled at DESTROYED, code after a suspend point may not execute on sudden cancellation. Do not rely on post-code execution after a suspend call unless you use NonCancellable.

Mistake 4: Using the Deprecated launchWhenStarted Instead of repeatOnLifecycle

launchWhenStarted and its counterparts do not cancel the coroutine, they only pause it. If the screen switches between foreground and background multiple times, the coroutine accumulates deferred calls. Switch to repeatOnLifecycle — this is the only correct way to synchronize with the Lifecycle.