Previously we have discussed about action bar styling and overlaying effect, now in this post we are going to look inside the Android life-cycle

Unlike other programming languages in which apps are launched with a main() method, the Android system initiates code in an Activity instance by invoking specific callback  methods that corresponds to specific stage  of its lifecycle.

There is sequence of callback methods that start up an activity and a sequence of callback methods that tear down an activity.

Understanding the Lifecycle callbacks



During the life of an activity, the system calls a core set of lifecycle methods in a sequence similar to a step pyramid. That is, each stage of the activity lifecycle is a separate step on the pyramid. As the system creates a new activity instance, each callback method moves the activity state one step toward the top. The top of the pyramid is the point at which the activity is running in the foreground and the user can interact with it.

As the user begins to leave the activity, the system calls other methods that moves the activity state back down the pyramid in order to dismantle the activity. In some cases, the activity will move only part way down the pyramid and wait (such as when the user switches to another app), from which point the activity can move back to the top (if the user returns to the activity) and resume where the user left off.

Depending on the complexity of our activity, we probably don't need to implement all the lifecycle methods. However, it's important that we understand each one and implement those that ensure our app behaves the way users expect. Implementing our activity lifecycle methods properly ensures our app behaves well in several ways, including that it:

  •       Does not crash if the user receives a phone call or switches to another app while using your app.
  •       Does not consume valuable system resources when the user is not actively using it.
  •       Does not lose the user's progress if they leave your app and return to it at a later time.
  •       Does not crash or lose the user's progress when the screen rotates between landscape and portrait orientation.

Only three of these states can be static. That is, the activity can exist in one of only three states for an extended period of time:


In this state, the activity is in the foreground and the user can interact with it. (Also sometimes referred to as the "running" state.)


In this state, the activity is partially obscured by another activity—the other activity that's in the foreground is semi-transparent or doesn't cover the entire screen. The paused activity does not receive user input and cannot execute any code.


In this state, the activity is completely hidden and not visible to the user; it is considered to be in the background. While stopped, the activity instance and all its state information such as member variables is retained, but it cannot execute any code.

The other states (Created and Started) are transient and the system quickly moves from them to the next state by calling the next lifecycle callback method. That is, after the system calls onCreate() , it quickly calls onStart(), which is quickly followed by onResume().

Specify Your App's Launcher Activity

When the user selects our app icon from the Home screen, the system calls the onCreate() method for the Activity in your app that you've declared to be the "launcher" (or "main") activity. This is the activity that serves as the main entry point to your app's user interface.

You can define which activity to use as the main activity in the Android manifest file, AndroidManifest.xml, which is at the root of your project directory.

The main activity for your app must be declared in the manifest with an <intent-filter> that includes the MAIN action and LAUNCHER category. For example:

<activity android:name=".MainActivity" android:label="@string/app_name">

        <action android:name="android.intent.action.MAIN" />
        <category android:name="android.intent.category.LAUNCHER" />

If either the MAIN action or LAUNCHER category are not declared for one of your activities, then your app icon will not appear in the Home screen's list of apps.

Create a New Instance

Most apps include several different activities that allow the user to perform different actions. Whether an activity is the main activity that's created when the user clicks our app icon or a different activity that our app starts in response to a user action, the system creates every new instance of Activity by calling its onCreate() method. 

You must implement the onCreate() method to perform basic application startup logic that should happen only once for the entire life of the activity. For example, your implementation of onCreate() should define the user interface and possibly instantiate some class-scope variables. 

For example, the following example of the onCreate() method shows some code that performs some fundamental setup for the activity, such as declaring the user interface (defined in an XML layout file), defining member variables, and configuring some of the UI.

TextView mTextView; // Member variable for text view in the layout
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);     // Set the user interface layout for this Activity     // The layout file is defined in the project res/layout/main_activity.xml file
// Initialize member TextView so we can manipulate it later
= (TextView) findViewById(;   
// Make sure we're running on Honeycomb or higher to use ActionBar APIs     if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.HONEYCOMB) {         // For the main activity, make sure the app icon in the action bar         // does not behave as a button         ActionBar actionBar = getActionBar();

Once the onCreate() finishes execution, the system calls the onStart() and onResume() methods in quick succession. Our activity never resides in the Created or Started states. Technically, the activity becomes visible to the user when onStart() is called, but onResume() quickly follows and the activity remains in the Resumed state until something occurs to change that, such as when a phone call is received, the user navigates to another activity, or the device screen turns off.

Destroy the Activity

While the activity's first lifecycle callback is onCreate(), its very last callback is onDestroy(). The system calls this method on your activity as the final signal that your activity instance is being completely removed from the system memory. 

Most apps don't need to implement this method because local class references are destroyed with the activity and your activity should perform most cleanup during onPause() and onStop(). However, if our activity includes background threads that we created during onCreate() or other long-running resources that could potentially leak memory if not properly closed, you should kill them during onDestroy().

public void onDestroy() {
    super.onDestroy();  // Always call the superclass    
// Stop method tracing that the activity started during onCreate()     android.os.Debug.stopMethodTracing();


This post is referred from Google docs Managing the Activity Lifecycle

In my next post,we are going to see how to pause and resume an activity : Activity Life Cycle in Android: Pausing and resuming an activity

  Modified On Nov-30-2017 12:50:49 AM
  1. Awesome article. Thanks for sharing useful information. It's good of you to stay open for your readers.

Leave Comment