Even though the activities may be from different applications, Android maintains this seamless user experience by keeping both activities in the same task.
The device Home screen is the starting place for the most tasks. When the user touches an icon in the application launcher(or a shortcut on the Home screen), that application's task comes to the foreground. If no task exists for the application(the application has not been used recently), then a new task is created and the "main" activity for that application opens as the root activity in the stack.
When the current activity starts another, the new activity is pushed on the top of the stack and takes focus. The previous activity remains in the stack, but is stopped. When an activity stops, the system remains the current state of its user interface. When the user presses the Back button, the current activity is popped from the top of the stack(the activity is destroyed) and the previous activity resumes(the previous state of its UI is restored). Activities in the stack are never rearranged, only pushed and popped from the stack--pushed onto the stack when started by the current activity and popped off when the user leaves it using the Back button. As such, the back stack operates as a "last in, first out" object structure.
A task is a cohesive unit that can move to the "backgound" when users begin a new task or go to the Home screen, via the Home button. While in the backgound, all the activities in the task are stopped, but the back stack for the task remains intact-the task has simply lost focus while another task takes place, as shown in figure 2. A task can then return to the "foreground" so users can pick up where they left off. Suppose, for example, that the current task(Task A) has three activities in its stack-two under the current activity. The user presses the Home button, then starts a new application starts, the system starts a task for that application(Task B) with its own stack of activities. After interacting with that application, the user returns Home again and selects the application that originally started Task A. Now, Task A comes to the foreground-all three activities in its stack are intact and the activity at the top of the statck resumes. At this point, the user can also switch back to Task B by going Home and selecting the application icon that started that task(or by selecting the app's task from the recent apps screen).
Saving Activity State
As discussed above, the system's default behavior preserves the state of an activity when it is stopped. This way, when users navigating back to a previous activity, its user interface appares the way they left it. However, you can - and should - proactively retain the state of your activities using callback methods, in case the activity is destroyed and must be recreated.
When the system stops one of your activities(such as when a new activity starts or the task moves to the backgound), the system might destroy that activity completely if it needs to recover system memory. When this happens, information about the activity state is lost. If this happens, the system still knows that the activity has a place in the back statck, but when the activity is brought to the top of the stack the system must recreate it(rather than resume it). In order to avoid losing the user's work, you should proactively retain it by implementing the onSaveInstanceState() callback methods in your activity.
Managing Tasks
The way Android manages tasks and the back stack, as described above -- by placing all activities started in succession in the same task and in a "last in, first out" stack -- works great for most application and you shouldn't have to worry about how your activities are associated with tasks or how they exists in the back stack. However, you might decide that you want to interrupt the normal behavior. Perhaps you want an activity in your application to begin a new task when it is started(instead of being placed with the current task); or, when you start an activity, you want to bring foward an existing instance of it(instead of creating a new instance on the top of the back stack); or you want your back stack to be cleared of all activities expect for the root activity when the user leaves the task.
You can do these things and more, with attributes in the <activity> manifest element and with flags in the intent that you pass to startActivity().
In this regard, the principal <activity> attributes you can use are:
taskAffinity
launchMode
allowTaskReparenting
clearTaskOnLaunch
alwaysRetainTaskState
finishOnTaskLaunch
And the principal intent flags you can use are:
FLAG_ACTIVITY_NEW_TASK
FLAG_ACTIVITY_CLEAR_TOP
FLAG_ACTIVITY_SINGLE_TOP
In the following sections, you'll see how you can use these manifest attributes and intent flags to define how activities are associated with tasks and how the behave in the back stack.
Caution: Most applications should not interupt the default behavior for activities and tasks. If you determine that it is necessary for your activity to modify the default behaviors, use caution and be sure to test the usability of the activity during launch and when navigating back to it from other activities and tasks with the Back button. Be sure to test for navigation behaviors that might conflict with the user's expected behavior.
Define launch modes
Launch modes allow you to define how a new instance of an activity is associated with the current task. You can define different launch modes in two ways:
Using the manifest file
When you declare an activity in your manifest file, you can specify how the activity should associate with tasks when it starts.
Using Intent flags
When you call startActivity(), you can include a flag in the Intent that declares how (or whether) the new activity should associate with the current task.
As such, if Activity A starts Activity B, Activity B can define in its manifest how it should associate with the current task(if at all) and Activity A can also request how Activity B should associate with current task. If both Activities define how Activity B should associate with a task, then Activity A's request(as defined in the intent) is honored over Activity B's request(as defined in its manifest).
Some launch modes available for the manifest file are not available as flags for an intent and, likewise, some launch modes available as flags for an intent cannot be defined in the manifest.
Using the manifest file
When declaring an activity in your manifest file, you can specify how the activity should associate with a task using the <activity> element's launchMode attribute.
The launchMode attribute specifies an instruction on how the activity should be launched into a task. There are four different launch modes you can assign to the launchMode attribute:
"standard" (the default mode)
Default. The system creates a new instance of the activity in the task from which it was started and routes the intent to it. The activity can be instantiated multiple times, each instance can be belong to different tasks, and one task can have mutiple instances.
"singleTop"
If an instance of the activity already exists at the top of the current task, the system routes the intent to that instance through a call to its onNewInstance() method, rather than creating a new instance of the activity. The activity can be instantiated mutiple times, each instance can belong to different tasks, and one task can have mutiple instances.
For example, suppose a task's back stack consists of root activity A with activities B, C, and D on top(the stack is A-B-C-D; D is on top). An intent arrives for an activity of type D. If D has the default "standard" launch mode, a new instance of the class is launched and the stack becomes A-B-C-D-D. However, if D's launch mode is "singleTop", the existing instance of D receives the intent through onNewIntent(), because it's at the top of the stack -- the stack remains A-B-C-D. However, if an intent arrives for an activity of type B, then a new instance of B is added to the stack, even if its launch mode is "singleTop".
Note: When a new instance of an activity is created, the user can press the Back button to return to the previous activity. But when an existing instance of an activity handles a new intent, the user cannot press the Back button to return to the state of the activity before the new intent arrived in onNewIntent().
"singleTask"
The system creates a new task and instantiates the activity at the root of the new task. However, if an instance of the activity already existes in a separate task, the system routes the intent to the existing instance through a call to its onNewIntent() method, rather than creating a new instance. Only one instance of the activity can exist at a time.
Note: Although the activity starts in a new task, the Back button still returns the user to the previous activity.
"singleInstance"
Same as "singleTask", expect that the system doesn't launch any other activities into the task holding the instance. The activity is always the single and only member of its task; any activities started by this one open in a separate task.
As another example, the Android Browser application declares that the web browser activity should always open it its own task -- by specifying the singleTask launch mode in the <activity> element. This means that if your application issues an intent to open the Android Browser, its activity is not placed in the same task as your application. Instead, either a new task starts for the Browser or, if the Browser already has a task running in the background, that task is brought forward to handle the new intent.
Regardless of whether an activity starts in a new task or in the same task as the activity that started it, the Back button always takes the user to the previous activity. However, if you start an activity that specifies the singleTask launch mode, then if an instance of that activity exists in a background task, that whole task is brought to the forground. At this point, the back stack now includes all activities from the task brought forward, at the top of the stack.