Android Activity Lifecycle: The Definitive Reference

By •  • tagged android

If you're an Android developer, I'm sure you have the activity lifecycle burned into your memory by now:

Activity lifecycle

Now, Android's reference documentation and training guides are excellent in general, but the rules of thumb to follow for the different lifecycle methods are scattered across the Activity lifecycle training and Activity documentation, and in some places the documentation is confusing to the point where it seems self-contradictory[1]. This post aims to collate the recommended guidelines in a clear, concise, readable format for quick reference purposes, along with links to relevant documentation (each heading links to the method's documentation).

If you're new to Android in general, this post is not a good place to start reading about the Activity lifecycle. Start here instead and perhaps bookmark this page for future reference.

onCreate

Called when the Activity is being created for the first time. The Activity never simply rests in the Created state, it quickly moves on to the Started and Resumed states (or, if finish() is called from onCreate, the Activity moves to the Destroyed state directly, without being Started).

Guidelines:

onStart

Called when the Activity is being brought to the foreground. For example: (1) the user presses the Back button which brings them back to your Activity, or, (2) the user selects your backgrounded app from the Recent apps screen. After this method executes, the Activity is in the foreground but not yet focused and ready for user interaction. The Activity never simply rests in the Started state, it quickly moves on to the Resumed state.

Guidelines:

onResume

Called when the Activity is completely visible, focused and ready for user interaction. At this point it is said to be Resumed or running.

Guidelines:

  • Start (or resume) animations / CPU intensive actions
  • Acquire battery-intensive or exclusive-access system resources (Camera, BroadcastReceivers, GPS, etc)

onPause

Called when the Activity is still partially visible, but the user is probably navigating away from your Activity entirely (in which case onStop will be called next). For example, when the user taps the Home button, the system calls onPause and onStop in quick succession on your Activity. However, the next Activity to be displayed is not even created until this one's onPause returns, so make sure you don't do anything lengthy here (like a database write).

A valid question to ask at this point would be: "Why can't I just move all my cleanup work to onStop instead?" The answer is that: (1) CPU-intensive tasks (like animations) should be stopped here to ensure the next Activity is started quickly, (2) battery-intensive resources like GPS should be released here, because the Activity is no longer in focus, and, (3) exclusive-access resources like the Camera should be released here, because the next Activity might acquire them in its onResume, which is called before this Activity's onStop.

Guidelines:

  • Stop animations and other CPU-intensive actions
  • Release battery-intensive system resources (GPS, BroadcastReceivers, etc)
  • Release shared system resources (e.g., Camera)

onStop

Called when the Activity is about to be completely hidden from the user. Note that this is the last method in the lifecycle that is guaranteed to be called[2] before the Activity can be killed; onDestroy may not be called in low memory situations, so make sure you release resources that might leak memory in onStop.

Guidelines:

  • Write to database
  • Perform CPU-intensive shutdown operations
  • Release resources that might leak memory

onDestroy

Called when the Activity is being permanently or temporarily destroyed. Since most resources are already released in onStop, and member references are automatically cleaned up on object destruction, there's usually not much to do here.

Guidelines:

  • Release resources acquired in onCreate (e.g., background threads)

Bonus: onSaveInstanceState

Called to persist the Activity's UI state in a Bundle, so it can be restored in onCreate or onRestoreInstanceState later. A couple of things to note for this method:

  1. Not really a lifecycle method, so not guaranteed to be called every time.
  2. If called, it will be called before onStop, but there are no guarantees about whether it will be called before or after onPause.

Guidelines:

  • Save only the state of the user interface (as opposed to persistent data), such as the selected item in a Spinner, text entered in an EditText, the current tab in a tab strip, etc. However, Android automatically saves the state of all Views that have an ID by calling onSaveInstanceState on each of them. This is the reason why you must call through to super.onSaveInstanceState() from your Activity if you override it. Watch Cyril Mottier's great talk from Droidcon Paris 2014, Deep Dive Into Android State Restoration, for more.

Feel free to ask questions, point out mistakes, or suggest changes in the comments section below.

  1. For instance, the training page says: "Generally, you should not use onPause() to store user changes (such as personal information entered into a form) to permanent storage. The only time you should persist user changes to permanent storage within onPause() is when you're certain users expect the changes to be auto-saved (such as when drafting an email). However, you should avoid performing CPU-intensive work during onPause(), such as writing to a database, because it can slow the visible transition to the next activity (you should instead perform heavy-load shutdown operations during onStop())." On the other hand, the Activity documentation simply states, "you should use the onPause() method to write any persistent data (such as user edits) to storage." I don't know about you, but it confused the hell out of me. My interpretation of this whole mess is summarized in the rest of this article. ↩︎

  2. Ctrl+F "not in the killable state" on http://developer.android.com/reference/android/app/Activity.html. This is considering only Android 4.0 Ice Cream Sandwich and above, as they account for > 90% of all Android devices today. Check here for the latest numbers. ↩︎