An Android activity is a self-standing component of an Android application that can be started, stopped, paused, restarted, or reclaimed depending on various events including user-initiated and system-initiated ones.
onCreate (bundle savedInstanceState)
The activity’s life cycle starts with this method. In this method you should load your view hierarchies by loading the layouts into the content view of the activity. You also initialize any activity level variables that may be used during the lifetime of the activity. Like many of the callbacks you also call the parent’s
onCreate() method first.
onCreate is called, an activity may be in one of three states. The activity may have been a brand-new activity starting out its life for the first time. Or it may be an activity that is automatically restarted because of a configuration change such a device rotating from one orientation to another. Or it is an activity that is restarted following a previous process shutdown due to low-memory conditions and being in the background. In the
onCreate callback, you should take these scenarios into account if what you need to do in each scenario is different.
After being created, this method pushes the activity into a visible state. In other words this method starts the visible life cycle of the activity. This method is called right after
onCreate(). This method assumes that the view hierarchies are loaded and available from the
If the system choses to close the activity, because there is a change in orientation, then the user will expect that transitory (instance) state right back when the activity is restarted. To facilitate this, Android calls this
onRestoreInstanceState method with a bundle that contains the saved instance state.
The callback method
onResume is the precursor to having the activity fully visible. This is also the start of the foreground cycle for the activity. In this foreground cycle the activity can move between
onPause() multiple times as other activities, notifications, or dialogs with more urgency come on top and go.
By the time this method is called, we can expect the views and their state fully restored. You can take this opportunity to tweak final state changes. As this method doesn’t have a bundle, you need to rely on the information from
onRestoreInstanceState methods to fine-tune state if further needed.
This callback indicates that the activity is about to go into background. You should stop any counters or animations that were running when the activity was fully visible. The activity may go to
onResume or proceed to
onStop. Going to
onResume will bring the activity to the foreground. Going to
onStop will take the activity into a background state.
The callback method
onStop() moves the activity from partially visible to the background state while keeping all of the view hierarchies intact. This is the counterpart of
onStart. The activity can be taken back to the visible cycle by calling
onStart. This state transition of going from
onStart during the same activity life cycle goes through the
The control goes to
onDestroy() coming out of
onStop if the process is still in memory. However, if Android realizes that activity is being closed without the user’s expectation then it would call the
onSaveInstanceState() before calling
onDestroy(). Orientation change is a very concrete example of this. The SDK warns that the timing of
onSaveInstanceState() is not predictable whether before or after
This method is called when the activity transitions from background state to partially visible state, i.e., going from
onStart. You can use this knowledge in
onStart if you want to optimize code there based on whether it is a fresh start or a restart. When it is a restart the view and their state are fairly intact.
onDestroy() is the counterpart ofonCreate()
. The activity is going to finish afteronDestroy``. An activity can finish for two primary reasons. One is an explicit close. The second reason an activity can close is involuntary.
Android Application Launch