Android Lifecycle

Activity Lifecycle

An Activity is the fundamental building block of any Android application. When a user interacts with your app—switching activities, closing the app, or replacing one Activity with another—various lifecycle events occur. Android provides lifecycle callbacks so you can properly manage resources, user interactions, and data persistence.

Activity States

1. Created
2. Started
3. Resumed
4. Paused
5. Stopped
6. Destroyed

onCreate

Triggered when: The Activity is first created.

Typical usage:

• Inflate or set up UI elements (setContentView(...)).
• Initialize class-scope variables.
• Retrieve any Bundle data passed through the Intent.
• Connect to a ViewModel (Jetpack Architecture Components).
• Other one-time setup tasks.

override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    // Example: setContentView(R.layout.main_activity)
    // Initialize variables, bind data, etc.
}

After onCreate completes, the Activity is in the CREATED state.

onStart

Triggered when: The Activity moves into the STARTED state.

Typical usage:

• Final preparations before the Activity becomes visible.
• Start or resume visual elements such as animations or camera previews.

onResume

Triggered when: The Activity is fully visible and the user can interact with it.

Typical usage:

• Resume operations needed for an interactive UI (e.g., camera preview, location updates).
• Refresh data or UI elements.

onResume can be called multiple times during the app’s lifetime, for example:

1. onCreate → onStart → onResume
2. onPause → onResume
3. onStop → onRestart → onStart → onResume

onPause

Triggered when: The Activity is about to go into the background (partially or fully).

Typical usage:

• Release or pause resources that don’t need to run in the background (e.g., camera, sensors).
• Save any transient UI state in case the system kills the process.

onStop

Triggered when: The Activity is no longer visible to the user.

Typical usage:

• Persist user data or state (e.g., to a database or shared preferences).
• Cancel unnecessary jobs like API calls or file I/O.
• Free system resources or references (unbind from services, etc.).

onDestroy

Triggered when: The Activity is finishing or the system is destroying it to free up resources.

Typical usage:

• Final cleanup for resources that haven’t already been released in onStop.
• Occurs when:
  • The user presses the back button to exit.
  • finish() is called explicitly.
  • The system restarts the Activity due to configuration changes (e.g., rotation, multi-window).

Common Scenarios

• Opening another app from a notification: onPause() → onStop()
• Coming back from another app: onRestart() → onStart() → onResume()
• Incoming phone call: onPause() → onResume() (if quickly dismissed), or possibly onStop() (if fully covered)
• Turning screen off: onPause() → onStop()
• Turning screen on and returning: onRestart() → onStart() → onResume()
• Pressing back to exit: onPause() → onStop() → onDestroy()
• Pressing Home: onPause() → onStop()
• Returning from Home: onRestart() → onStart() → onResume()

Fragment Lifecycle

Fragments, similar to Activities, have their own lifecycle callbacks and states. However, a Fragment’s lifecycle is always tied to the lifecycle of its host Activity.

1. onAttach: Called when the Fragment is attached to its host Activity.
2. onCreate: Called right after attaching to the Activity; initializes the Fragment.
3. onCreateView: Inflates the Fragment’s layout and sets up UI components.
4. onActivityCreated: Called after the Activity finishes its own onCreate.
5. onStart: The Fragment becomes visible.
6. onResume: The Fragment is now fully visible and interactive.
7. onPause: The Fragment is about to be paused (e.g., replaced or the Activity is pausing).
8. onStop: The Fragment is no longer visible.
9. onDestroyView: The view and resources created in onCreateView are removed from the Activity.
10. onDestroy: The Fragment is being fully destroyed.
11. onDetach: The Fragment is detached from its Activity.

Activity–Fragment Relationship

A Fragment’s lifecycle depends heavily on the Activity’s lifecycle. If the Activity is paused or stopped, its Fragments follow suit.

Latest Updates & Best Practices

1. ViewModel & LiveData (or StateFlow / Flow)

   • Use ViewModel to store data; it survives configuration changes.
   • Observe data changes using LiveData or Kotlin’s Flow for reactive updates.

2. Jetpack Navigation

   • Simplify in-app navigation with the Navigation component.
   • Manage the back stack and deep links cleanly.

3. SavedStateHandle

   • Combine ViewModel with SavedStateHandle to survive process death or configuration changes automatically.

4. Lifecycle Observers

   • Use LifecycleOwner and LifecycleObserver to keep code modular and respond to lifecycle changes without cluttering Activities or Fragments.

5. Avoid Memory Leaks

   • Clean up references in onDestroyView() (Fragments) and onDestroy() (Activities).
   • Cancel coroutines, threads, and listeners to avoid leaks.

6. Configuration Changes

   • Handle changes like orientation or multi-window by using ViewModel and onSaveInstanceState().

7. Permissions & Foreground Services

   • Request and handle run-time permissions in a lifecycle-aware manner.
   • Stop services that aren’t needed while in the background.

Conclusion

Understanding and correctly using the Activity and Fragment lifecycles is key to building stable and responsive Android applications. Adopt modern practices such as ViewModel, LiveData/Flow, and Navigation to simplify lifecycle management and ensure a clean architecture.

Learn More

• Official Android Docs: Activities
• Official Android Docs: Fragments
• Jetpack Components Overview

Thanks for reading!