Android Activity Lifecycle 101 – What an Android Developer Should Know

Android app developers need to understand Activity instances to be able to control the product’s performance. The good news is, the way activities function abides by clear logic and is predictable. It is called the Activity Lifecycle.

In this post, you will out what the stages of the cycle are, what methods a mobile system uses to transition between different Activity states, what these callbacks mean for app users and developers.

What’s an Android Activity?

Whenever a user opens an app and navigates the interface, he interacts with an activity. In mobile app development, activities are referred to as classes that offer a tab where a UI will be shown to a user.

In terms of functionality, Android activities correspond to windows or frames in Java. Mobile app developers use them to place multiple interface elements on a single screen. Taxonomically, activities are a subclass of the class called ContextThemeWrapper.

Introduction to Activity States

When a mobile developer builds an app, he creates a set of activities users will switch between when navigating the ready tool. The placement of activities inside the stack depends on whether or not they are running at the moment. If there’s a running activity, it’s located at the top of the stack.

Overall, there are four activity states developers usually operate with:

  • Created activity – the first state a new activity enters.
  • Running activity – a task that’s currently executed. A user can see a running activity, it also has the highest priority in the app.
  • Paused activity – a task is interrupted by the execution of a different one. These activities are second-tier and visible in the technology stack.
  • Restarted activity – a task that has been paused or stopped is running again. In that case, it regains the highest priority and is visible to a user.
  • Stopped activity – a task is hidden from the stack. A silenced activity has the lowest priority and is the first one to be deleted if the system lacks memory or needs new memory resources.

Managing Activity Callback Methods

Activities are connected to the system thanks to callbacks. These methods are used to communicate the change of state and specify the app’s future actions – starting, stopping a task, or removing it from the system altogether.

Thanks to callbacks, activities receive instructions on how to behave once a user interacts with them. For instance, when a user exits the activity, the network connection can be terminated and restarted when an app visitor interacts with the task again.

Knowing how to handle activity callbacks improves the performance of the app, increases the system’s robustness, and facilitates maintenance. Here is how these methods impact mobile applications:

  • Saving system resources when a user is no longer interacting with an activity;
  • Keeping track of a user’s progress in the interaction and saving it for when a person returns to the system;
  • Performing stably when a user changes the screen orientation from portrait to landscape and vice versa;
  • Preventing system crashes if there’s a switch between smartphone tabs.

Six Activity Lifecycle Callbacks to Know

Since methods are needed to manage activities, it’s natural that there’s more than one callback needed to dismantle tasks. Developers use callback methods to perform operations when the activity is in the transition state.

Here the methods Android software engineers implement:

  • onCreate() – used to create an activity;
  • onStart()– used to make a created task visible to app users
  • onResume() – used to re-start running a paused activity;
  • onPause() – used to hide the activity from the user;
  • onStop() – used to stop the activity and release the resources it consumes;
  • onDestroy() is called to remove the activity from the system 

Let’s take a closer look at the way each of these methods operates one by one:


onCreate() sets the startup logic for activity in motion. The callback can be called only once in the activity lifecycle. After the method is applied, the activity enters the ‘Created’ state.

There are multiple actions onCreate() can trigger – data binding, class-scope variable instantiation, attaching an activity to a ViewModel, and os on. The method has a SavedInstanceState parameter attached to it, with an object that contains the activity’s previously specified state. If the activity didn’t exist before, the object value will be null.


The callback is required to transfer the activity to the Started state. As soon as a developer calls onStart(), a user will be able to see the activity. The system assigns the top priority to the activity and pushes it to the foreground.

The onStart() callback allows the activity to become interactive. When the task is on, the component, a system will send an ON_START event to the lifecycle-aware component.

onStart() is extremely convenient to call is it compiles quickly. However, it is more of a transient than a permanent state since the activity will quickly move to onResume() and change the state to Resumed.


After onStart() is compiled, the activity will move from Started to Resumed – the interactive state that allows the app visitor to navigate the interface. The state of the activity doesn’t change until the user shifts away from the app – switches tabs, accepts a phone call, etc.

When a distracting event happens, the system switches states between Resumed and Paused. The system will issue an onPause() callback.

To restart an activity, the system invokes onResume() again. Developers need to use the callback to start using components that were released when the activity was paused and restart initializations.


The callback is invoked when a user is no longer interacts with an activity. Although it’s no longer in the foreground, the activity is not necessarily invisible and is still located second at the top of the tech stack.

Using onPause() helps developers save system resources and makes it easier for end users to navigate the system. There are three main scenarios that trigger the onPause() callback:

  • An external event – a text or an incoming call – interrupts the execution of a foreground activity;
  • When many apps are running in the background in the multi-window mode, only one screen is on the foreground. The rest will be paused.
  • If a new activity opens, leaving the previous activity out of focus (although visible).

The activity’s switch to the paused state will trigger an ON_PAUSE event. All the functionality that is running when the element is in the foreground will be stopped, system resources are released.

Keep in mind, however, that onPause() doesn’t offer a full release of system resources – for that, you will need to use onStop().


The callback is invoked when a user can no longer see an activity. In that case, an activity has entered the Stopped state. onStop() is called for any task that is complete and up for termination. Also, if a new activity that occupies the entire screen is started, the previous one will be stopped.

onStop() callback triggers the reception of the ON_STOP event for the lifecycle-aware component. Then, system resources will be released and the activity will be hidden from the stack.

onStop() helps developers optimize the CPU usage of Android apps. Also, unlike during onPause(), UI related tasks will be continued even when a user sees an app via a multi-window mode.


onDestroy() is a method that signals the destruction of an activity. There are several scenarios resulting in this system feedback:

  • In conjunction with the finish() method or if a user dismisses an activity;
  • If due to a system configuration change – switching between screen orientations or choosing the multi-window mode – the activity can no longer resume.

The destruction can be either permanent or temporary.

After onDestroy() is called, a lifecycle-aware component receives an ON_DESTROY event and triggers the release of resources an activity uses and the clean-up of the system. If you want to recreate an activity after destruction, be sure to save all the relevant data as a ViewModel object. If you don’t recreate the activity, use onCleared() to remove its components from the system.

onDestroy() releases all resources that were conserved after calling onPause() or onStop().


The concept of activity is fundamental in Android development. Knowing how to create activities and manage them takes a lot of theoretical learning and solving practice problems. However, if you understand the activity lifecycle, you will have a better idea of how the application operates, what the ways to optimize RAM and CPU usage are.

To get to know more about Activities and Activity Lifecycle, don’t miss out on going through official documentation. Here are some tutorials on Activities and Activity Lifecycle developers often use as reference points.

Good luck practicing Android app development – with enough perseverance, getting the hang of the basics will not take long.

You may also like...

Leave a Reply

Your email address will not be published. Required fields are marked *