Android is designed to empower users and let them use apps in a intuitive way. For example, users of an app might rotate the screen, respond to a notification, or switch to another task, and they should be able to continue using the app seamlessly after such an event.
To provide this user experience, you should know how to manage component lifecycles. A component can be an Activity, a Fragment, a Service, the Application itself and even the underlying process. The component has a lifecycle, during which it transitions through states. Whenever a transition happens, the system notifies you via a lifecycle callback method.
To help us explain how lifecycles work, we’ve defined a series of scenarios which are grouped according to the components that are present:
Part I: Activities — single activity lifecycle (this post)
The diagrams are also available as a cheat sheet in PDF format for quick reference.
Note: these diagrams apply to Android P / Jetpack 1.0 behavior.
The following scenarios showcase the default behavior of the components, unless otherwise noted.
If you find errors or you think something important is missing, report it in the comments.
Part I: Activities
Single Activity — Scenario 1: App is finished and restarted
- The user presses the Back button, or
Activity.finish()method is called
The simplest scenario shows what happens when a single-activity application is started, finished and restarted by the user:
Single Activity — Scenario 2: User navigates away
- The user presses the Home button
- The user switches to another app (via Overview menu, from a notification, accepting a call, etc.)
In this scenario the system will stop the activity, but won’t immediately finish it.
When your activity enters the Stopped state, the system uses onSaveInstanceState to save the app state in case the system kills the app’s process later on (see below).
Assuming the process isn’t killed, the activity instance is kept resident in memory, retaining all state. When the activity comes back to the foreground, the activity recalls this information. You don’t need to re-initialize components that were created earlier.
Single Activity — Scenario 3: Configuration changes
- Configuration changes, like a rotation
- User resizes the window in multi-window mode
Configuration changes like rotation or a window resize should let users continue exactly where they left off.
- The activity is completely destroyed, but the state is saved and restored for the new instance.
- The Bundle in
onRestoreInstanceStateis the same.
Single Activity — Scenario 4: App is paused by the system
- Enabling Multi-window mode (API 24+) and losing the focus
- Another app partially covers the running app (a purchase dialog, a runtime permission dialog, a third-party login dialog…)
- An intent chooser appears, such as a share dialog
This scenario doesn’t apply to:
- Dialogs in the same app. Showing an
DialogFragmentwon’t pause the underlying activity.
- Notifications. User receiving a new notification or pulling down the notification bar won’t pause the underlying activity.