page.title=Tasks and Back Stack
parent.title=Activities
parent.link=activities.html
@jd:body

<div id="qv-wrapper">
<div id="qv">
<h2>Quickview</h2>
<ul>
  <li>All activities belong to a task</li>
  <li>A task contains a collection of activities in the order in which the user interacts with
them</li>
  <li>Tasks can move to the background and retain the state of each activity in order for the user
to perform other tasks without loosing their work</li>
</ul>

<h2>In this document</h2>
<ol>
<li><a href="#ActivityState">Saving Activity State</a></li></li>
<li><a href="#ManagingTasks">Managing Tasks</a>
  <ol>
    <li><a href="#TaskLaunchModes">Defining launch modes</a></li>
    <li><a href="#Affinities">Handling affinities</a></li>
    <li><a href="#Clearing">Clearing the back stack</a></li>
    <li><a href="#Starting">Starting a task</a></li>
  </ol>
</li>
</ol>

<h2>See also</h2>
<ol>
  <li><a><a href="{@docRoot}videos/index.html#v=fL6gSd4ugSI">Application Lifecycle video</a></li>
  <li><a
href="{@docRoot}guide/topics/manifest/activity-element.html">{@code &lt;activity&gt;} manifest
element</a></li>
</ol>
</div>
</div>


<p>An application usually contains multiple <a
href="{@docRoot}guide/topics/fundamentals/activities.html">activities</a>. Each activity
should be designed around a specific kind of action the user can perform and can start other
activities. For example, an email application might have one activity to show a list of new email.
When the user selects an email, a new activity opens to view that email.</p>

<p>An activity can even start activities that exist in other applications on the device. For
example, if your application wants to send an email, you can define an intent to perform a "send"
action and include some data, such as an email address and a message. An activity from another
application that declares itself to handle this kind of intent then opens. In this case, the intent
is to send an email, so an email application's "compose" activity starts (if multiple activities
support the same intent, then the system lets the user select which one to use). When the email is
sent, your activity resumes and it seems as if the email activity was part of your application. Even
though the activities may be from different applications, Android maintains this seamless user
experience by keeping both activities in the same <em>task</em>.</p>

<p>A task is a collection of activities that users interact with
when performing a certain job. The activities are arranged in a stack (the "back stack"), in the
order in which each activity is opened.</p>

<!-- SAVE FOR WHEN THE FRAGMENT DOC IS ADDED
<div class="sidebox-wrapper">
<div class="sidebox">
<h3>Adding fragments to a task's back stack</h3>

<p>Your activity can also include {@link android.app.Fragment}s to the back stack. For example,
suppose you have a two-pane layout using fragments, one of which is a list view (fragment A) and the
other being a layout to display an item from the list (fragment B). When the user selects an item
from the list, fragment B is replaced by a new fragment (fragment C). In this case, it might be
desireable for the user to navigate back to reveal fragment B, using the BACK key.</p>
<p>In order to add fragment B to the back stack so that this is possible, you must call {@link
android.app.FragmentTransaction#addToBackStack addToBackStack()} before you {@link
android.app.FragmentTransaction#commit()} the transaction that replaces fragment B with fragment
C.</p>
<p>For more information about using fragments and adding them to the back stack, see the {@link
android.app.Fragment} class documentation.</p>

</div>
</div>
-->

<p>The device Home screen is the starting place for 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.</p>

<p>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 retains the current state of its user interface. When the user presses the BACK
key, 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&mdash;pushed onto the stack when started by
the current activity and popped off when the user leaves it using the BACK key. As such, the back
stack operates as a "last in, first out" object structure. Figure 1 visualizes
this behavior with a timeline showing the progress between activities along with the current back
stack at each point in time.</p>

<img src="{@docRoot}images/fundamentals/diagram_backstack.png" alt="" />
<p class="img-caption"><strong>Figure 1.</strong> A representation of how each new activity in a
task adds an item to the back stack. When the user presses the BACK key, the current activity is
destroyed and the previous activity resumes.</p>


<p>If the user continues to press BACK, then each activity in the stack is popped off to reveal the
previous one, until the user returns to the Home screen (or to whichever activity was running when
the task began). When all activities are removed from the stack, the task no longer exists.</p>

<div class="figure" style="width:369px">
<img src="{@docRoot}images/fundamentals/diagram_multitasking.png" alt="" /> <p
class="img-caption"><strong>Figure 2.</strong> Two tasks: Task A is in the background, waiting
to be resumed, while Task B receives user interaction in the foreground.</p>
</div>
<div class="figure" style="width:178px">
  <img src="{@docRoot}images/fundamentals/diagram_multiple_instances.png" alt="" /> <p
class="img-caption"><strong>Figure 3.</strong> A single activity is instantiated multiple times.</p>
</div>

<p>A task is a cohesive unit that can move to the "background" when users begin a new task or go
to the Home screen, via the HOME key. While in the background, all the activities in the task are
stopped, but the back stack for the task remains intact&mdash;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&mdash;two under the current activity. The user presses the HOME key, then
starts a new application from the application launcher. When the Home screen appears, Task A goes
into the background. When the 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&mdash;all three activities in its stack are intact and the activity at the top of the
stack 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 touching and holding the HOME key to reveal recent tasks and selecting
one). This is an example of multitasking on Android.</p>

<p class="note"><strong>Note:</strong> Multiple tasks can be held in the background at once.
However, if the user is running many background tasks at the same time, the system might begin
destroying background activities in order to recover memory, causing the activity states to be lost.
See the following section about <a href="#ActivityState">Activity state</a>.</p>

<p>Because the activities in the back stack are never rearranged, if your application allows
users to start a particular activity from more than one activity, a new instance of
that activity is created and popped onto the stack (rather than bringing any previous instance of
the activity to the top). As such, one activity in your application might be instantiated multiple
times (even from different tasks), as shown in figure 3. As such, if the user navigates backward
using the BACK key, each instance of the activity is revealed in the order they were opened (each
with their own UI state). However, you can modify this behavior if you do not want an activity to be
instantiated more than once. How to do so is discussed in the later section about <a
href="#ManagingTasks">Managing Tasks</a>.</p>


<p>To summarize the default behavior for activities and tasks:</p>

<ul>
  <li>When Activity A starts Activity B, Activity A is stopped, but the system retains its state
(such as scroll position and text entered into forms).
If the user presses the BACK key while in Activity B, Activity A resumes with its state
restored.</li>
  <li>When the user leaves a task by pressing the HOME key, the current activity is stopped and
its task goes into the background. The system retains the state of every activity in the task. If
the user later resumes the task by selecting the launcher icon that began the task, the task comes
to the foreground and resumes the activity at the top of the stack.</li>
  <li>If the user presses the BACK key, the current activity is popped from the stack and
destroyed. The previous activity in the stack is resumed. When an activity is destroyed, the system
<em>does not</em> retain the activity's state.</li>
  <li>Activities can be instantiated multiple times, even from other tasks.</li>
</ul>


<h2 id="ActivityState">Saving Activity State</h2>

<p>As discussed above, the system's default behavior preserves the state of an activity when it is
stopped. This way, when users navigate back to a previous activity, its user interface appears
the way they left it. However, you can&mdash;and <strong>should</strong>&mdash;proactively retain
the state of your activities using callback methods, in case the activity is destroyed and must
be recreated.</p>

<p>When the system stops one of your activities (such as when a new activity starts or the task
moves to the background), 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 stack, 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 loosing the user's work, you should proactively retain it by implementing the {@link
android.app.Activity#onSaveInstanceState onSaveInstanceState()} callback
methods in your activity.</p>

<p>For more information about how to save your activity state, see the <a
href="{@docRoot}guide/topics/fundamentals/activities.html#SavingActivityState">Activities</a>
document.</p>


<h2 id="ManagingTasks">Managing Tasks</h2>

<p>The way Android manages tasks and the back stack, as described above&mdash;by placing all
activities started in succession in the same task and in a "last in, first out" stack&mdash;works
great for most applications and you shouldn't have to worry about how your activities are associated
with tasks or how they exist 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 within the current task); or, when you start an activity, you want
to bring forward an existing instance of it (instead of creating a new
instance on top of the back stack); or, you want your back stack to be cleared of all
activitiesstart an activity except for the root activity when the user leaves the task.</p>

<p>You can do these things and more, with attributes in the
<a href="{@docRoot}guide/topics/manifest/activity-element.html">{@code
&lt;activity&gt;}</a> manifest element and with flags in the intent that you pass to {@link
android.app.Activity#startActivity startActivity()}.</p>

<p>In this regard, the the principal <a
href="{@docRoot}guide/topics/manifest/activity-element.html">{@code &lt;activity&gt;}</a>
attributes you can use are:</p>

<ul class="nolist">
  <li><a href="{@docRoot}guide/topics/manifest/activity-element.html#aff">{@code
taskAffinity}</a></li>
  <li><a href="{@docRoot}guide/topics/manifest/activity-element.html#lmode">{@code
launchMode}</a></li>
  <li><a href="{@docRoot}guide/topics/manifest/activity-element.html#reparent">{@code
allowTaskReparenting}</a></li>
  <li><a href="{@docRoot}guide/topics/manifest/activity-element.html#clear">{@code
clearTaskOnLaunch}</a></li>
  <li><a href="{@docRoot}guide/topics/manifest/activity-element.html#always">{@code
alwaysRetainTaskState}</a></li>
  <li><a href="{@docRoot}guide/topics/manifest/activity-element.html#finish">{@code
finishOnTaskLaunch}</a></li>
</ul>

<p>And the principal intent flags you can use are:</p>

<ul class="nolist">
  <li>{@link android.content.Intent#FLAG_ACTIVITY_NEW_TASK}</li>
  <li>{@link android.content.Intent#FLAG_ACTIVITY_CLEAR_TOP}</li>
  <li>{@link android.content.Intent#FLAG_ACTIVITY_SINGLE_TOP}</li>
</ul>

<p>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.</p>


<p class="caution"><strong>Caution:</strong> Most applications should not interrupt the default
behavior for activities and tasks. If you determine that it's 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 key. Be sure 
to test for navigation behaviors that might conflict with the user's expected behavior.</p>


<h3 id="TaskLaunchModes">Defining launch modes</h3>

<p>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:</p>
<ul class="nolist">
  <li><a href="#ManifestForTasks">Using the manifest file</a>
    <p>When you declare an activity in your manifest file, you can specify how the activity
should associate with tasks when it starts.</li>
  <li><a href="#IntentFlagsForTasks">Using Intent flags</a>
    <p>When you call {@link android.app.Activity#startActivity startActivity()},
you can include a flag in the {@link android.content.Intent} that declares how (or
whether) the new activity should associate with the current task.</p></li>
</ul>

<p>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).</p>

<p class="note"><strong>Note:</strong> Some the launch modes available in the manifest
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.</p>


<h4 id="ManifestForTasks">Using the manifest file</h4>

<p>When declaring an activity in your manifest file, you can specify how the activity should
associate with a task using the <a
href="{@docRoot}guide/topics/manifest/activity-element.html">{@code &lt;activity&gt;}</a>
element's <a href="{@docRoot}guide/topics/manifest/activity-element.html#lmode">{@code
launchMode}</a> attribute.</p>

<p>The <a href="{@docRoot}guide/topics/manifest/activity-element.html#lmode">{@code
launchMode}</a> 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
<code><a href="{@docRoot}guide/topics/manifest/activity-element.html#lmode">launchMode</a></code>
attribute:</p>

<dl>
<dt>{@code "standard"} (the default mode)</dt>
  <dd>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 belong to different tasks, and one task can have multiple instances.</dd>
<dt>{@code "singleTop"}</dt>
  <dd>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 {@link
android.app.Activity#onNewIntent onNewIntent()} method, rather than creating a new instance of the
activity. The activity can be instantiated multiple times, each instance can
belong to different tasks, and one task can have multiple instances (but only if the the
activity at the top of the back stack is <em>not</em> an existing instance of the activity).
  <p>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 {@code "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 {@code "singleTop"}, the existing instance
of D is deliverd the intent through {@link
android.app.Activity#onNewIntent onNewIntent()}, because it's at the top of the stack&mdash;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 {@code "singleTop"}.</p>
  <p class="note"><strong>Note:</strong> When a new instance of an activity is created,
the user can press the BACK key to return to the previous activity. But when an existing instance of
an activity handles a new intent, the user cannot press the BACK key to return to the state of
the activity before the new intent arrived in {@link android.app.Activity#onNewIntent
onNewIntent()}.</p>
</dd>

<dt>{@code "singleTask"}</dt>
  <dd>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 exists in a separate task, the system routes the
intent to the existing instance through a call to its {@link
android.app.Activity#onNewIntent onNewIntent()} method, rather than creating a new instance. Only
one instance of the activity can exist at a time.
  <p class="note"><strong>Note:</strong> Although the activity starts in a new task, the
BACK key still returns the user to the previous activity.</p></dd>
<dt>{@code "singleInstance"}.</dt>
  <dd>Same as {@code "singleTask"}, except 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.</dd>
</dl>


<p>As another example, the Android Browser application declares that the web browser activity should
always open in its own task&mdash;by specifying the {@code singleTask} launch mode in the <a
href="{@docRoot}guide/topics/manifest/activity-element.html">{@code &lt;activity&gt;}</a> element.
This means that if your application issues an
intent to open the Android Browser, its activity is <em>not</em> 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.</p>

<p>Regardless of whether an activity starts in a new task or in the same task as the activity that
started it, the BACK key always takes the user to the previous activity. However, if you
start an activity from your task (Task A) that specifies the {@code singleTask} launch mode, then
that activity might have an instance in the background that belongs to a task with its own back
stack (Task B). In this
case, when Task B is brought forward to handle a new intent, the BACK key first navigates
backward through the activities in Task B before returning to
the top-most activity in Task A. Figure 4 visualizes this type of scenario.</p>

<img src="{@docRoot}images/fundamentals/diagram_backstack_singletask_multiactivity.png" alt="" />
<p class="img-caption"><strong>Figure 4.</strong> A representation of how an activity with
launch mode "singleTask" is added to the back stack. If the activity is already a part of a
background task with its own back stack (Task B), then the entire back stack also comes
forward, on top of the current task (Task A).</p>

<p>For more information about using launch modes in the manifest file, see the
<code><a href="{@docRoot}guide/topics/manifest/activity-element.html">&lt;activity&gt;</a></code>
element documentation, where the {@code launchMode} attribute and the accepted values are
discussed more.</p>

<p class="note"><strong>Note:</strong> The behaviors that you specify for your activity with the <a
href="{@docRoot}guide/topics/manifest/activity-element.html#lmode">{@code launchMode}</a> attribute
can be overriden by flags included with the intent that start your activity, as discussed in the
next section.</p>


<h4 id="#IntentFlagsForTasks">Using Intent flags</h4>

<p>When starting an activity, you can modify the default association of an activity to its task
by including flags in the intent that you deliver to {@link
android.app.Activity#startActivity startActivity()}. The flags you can use to modify the
default behavior are:</p>

<p>
  <dt>{@link android.content.Intent#FLAG_ACTIVITY_NEW_TASK}</dt>
    <dd>Start the activity in a new task. If a task is already running for the activity you are now
starting, that task is brought to the foreground with its last state restored and the activity
receives the new intent in {@link android.app.Activity#onNewIntent onNewIntent()}. 
    <p>This produces the same behavior as the {@code "singleTask"} <a
href="{@docRoot}guide/topics/manifest/activity-element.html#lmode">{@code launchMode}</a> value,
discussed in the previous section.</p></dd>
  <dt>{@link android.content.Intent#FLAG_ACTIVITY_SINGLE_TOP}</dt>
    <dd>If the activity being started is the current activity (at the top of the back stack), then
the existing instance receives a call to {@link android.app.Activity#onNewIntent onNewIntent()},
instead of creating a new instance of the activity.
    <p>This produces the same behavior as the {@code "singleTop"} <a
href="{@docRoot}guide/topics/manifest/activity-element.html#lmode">{@code launchMode}</a> value,
discussed in the previous section.</p></dd>
  <dt>{@link android.content.Intent#FLAG_ACTIVITY_CLEAR_TOP}</dt>
    <dd>If the activity being started is already running in the current task, then instead
of launching a new instance of that activity, all of the other activities on top of it are
destroyed and this intent is delivered to the resumed instance of the activity (now on top),
through {@link android.app.Activity#onNewIntent onNewIntent()}).
    <p>There is no value for the <a
href="{@docRoot}guide/topics/manifest/activity-element.html#lmode">{@code launchMode}</a>
attribute that produces this behavior.</p>
    <p>{@code FLAG_ACTIVITY_CLEAR_TOP} is most often used in conjunction with {@code
FLAG_ACTIVITY_NEW_TASK}.  When used together, these flags are a way of locating an existing activity
in another task and putting it in a position where it can respond to the intent. </p>
    <p class="note"><strong>Note:</strong> If the launch mode of the designated activity is {@code
"standard"}, it too is removed from the stack and a new instance is launched in its place to handle
the incoming intent.  That's because a new instance is always created for a new intent when the
launch mode is {@code "standard"}. </p>
</dd>
</dl>


<h3 id="Affinities">Handling affinities</h3>

<p>The <em>affinity</em> indicates which task an activity prefers to belong to. By default, all the
activities from the same application have an affinity for each other. So, by default, all
activities in the same application prefer to be in the same task. However, you can modify
the default affinity for an activity. Activities defined in
different applications can share an affinity, or activities defined in the same application can be
assigned different task affinities.</p>

<p>You can modify the affinity for any given activity with the <a
href="{@docRoot}guide/topics/manifest/activity-element.html#aff">{@code taskAffinity}</a> attribute
of the <a href="{@docRoot}guide/topics/manifest/activity-element.html">{@code &lt;activity&gt;}</a>
element.</p>

<p>The <a
href="{@docRoot}guide/topics/manifest/activity-element.html#aff">{@code taskAffinity}</a>
attribute takes a string value, which must be unique from the default package name
declared in the <a href="{@docRoot}guide/topics/manifest/manifest-element.html">{@code
&lt;manifest&gt;}</a> element, because the system uses that name to identify the default task
affinity for the application.</p>

<p>The affinity comes into play in two circumstances:</p>
<ul>
  <li>When the intent that launches an activity contains the {@link
android.content.Intent#FLAG_ACTIVITY_NEW_TASK} flag.

<p>A new activity is, by default, launched into the task of the activity
that called {@link android.app.Activity#startActivity startActivity()}. It's pushed onto the same
back stack as the caller.  However, if the intent passed to {@link
android.app.Activity#startActivity startActivity()} contains the {@link
android.content.Intent#FLAG_ACTIVITY_NEW_TASK}
flag, the system looks for a different task to house the new activity. Often, it's a new task. 
However, it doesn't have to be.  If there's already an existing task with the same affinity as the
new activity, the activity is launched into that task.  If not, it begins a new task.</p>

<p>If this flag causes an activity to begin a new task and the user presses the HOME key to leave
it, there must be some way for the user to navigate back to the task. Some entities (such as the
notification manager) always start activities in an external task, never as part of their own, so
they always put {@code FLAG_ACTIVITY_NEW_TASK} in the intents they pass to {@link
android.app.Activity#startActivity startActivity()}.  If you have an activity that can be invoked by
an external entity that might use this flag, take care that the user has a independent way to get
back to the task that's started, such as with a launcher icon (the root activity of the task
has a {@link android.content.Intent#CATEGORY_LAUNCHER} intent filter; see the <a
href="#Starting">Starting a task</a> section below).</p>
</li>

  <li>When an activity has its <a
href="{@docRoot}guide/topics/manifest/activity-element.html#reparent">{@code
allowTaskReparenting}</a> attribute set to {@code "true"}.
  <p>In this case, the activity can move from the task it starts to the task it has an affinity
for, when that task comes to the foreground.</p>
  <p>For example, suppose that an activity that reports weather conditions in selected cities is
defined as part of a travel application.  It has the same affinity as other activities in the same
application (the default application affinity) and it allows re-parenting with this attribute.
When one of your activities starts the weather reporter activity, it initially belongs to the same
task as your activity. However, when the travel application's task comes to the foreground, the
weather reporter activity is reassigned to that task and displayed within it.</p>
</li>
</ul>

<p class="note"><strong>Tip:</strong> If an {@code .apk} file contains more than one "application"
from the user's point of view, you probably want to use the <a
href="{@docRoot}guide/topics/manifest/activity-element.html#aff">{@code taskAffinity}</a>
attribute to assign different affinities to the activities associated with each "application".</p>


<h3 id="Clearing">Clearing the back stack</h3>

<p>If the user leaves a task for a long time, the system clears the task of all activities except
the root activity.  When the user returns to the task again, only the root activity is restored.
The system behaves this way, because, after an extended amount of time, users likely have abandoned
what they were doing before and are returning to the task to begin something new. </p>

<p>There are some activity attributes that you can use to modify this behavior: </p>

<dl>
<dt><code><a
href="{@docRoot}guide/topics/manifest/activity-element.html#always">alwaysRetainTaskState</a></code>
</dt>
<dd>If this attribute is set to {@code "true"} in the root activity of a task,
the default behavior just described does not happen.
The task retains all activities in its stack even after a long period.</dd>

<dt><code><a
href="{@docRoot}guide/topics/manifest/activity-element.html#clear">clearTaskOnLaunch</a></code></dt>
<dd>If this attribute is set to {@code "true"} in the root activity of a task,
the stack is cleared down to the root activity whenever the user leaves the task
and returns to it.  In other words, it's the opposite of <a
href="{@docRoot}guide/topics/manifest/activity-element.html#always">{@code
alwaysRetainTaskState}</a>.  The user always returns to the task in its
initial state, even after a leaving the task for only a moment.</dd>

<dt><code><a
href="{@docRoot}guide/topics/manifest/activity-element.html#finish">finishOnTaskLaunch</a></code>
</dt>
<dd>This attribute is like <a
href="{@docRoot}guide/topics/manifest/activity-element.html#clear">{@code clearTaskOnLaunch}</a>,
but it operates on a
single activity, not an entire task.  It can also cause any activity to go
away, including the root activity.  When it's set to {@code "true"}, the
activity remains part of the task only for the current session.  If the user
leaves and then returns to the task, it is no longer present.</dd>
</dl>


<h3 id="Starting">Starting a task</h3>

<p>You can set up an activity as the entry point for a task by giving it an intent filter with
{@code "android.intent.action.MAIN"} as the specified action and {@code
"android.intent.category.LAUNCHER"} as the specified category. For example:</p>

<pre>
&lt;activity ... &gt;
    &lt;intent-filter ... &gt;
        &lt;action android:name="android.intent.action.MAIN" /&gt;
        &lt;category android:name="android.intent.category.LAUNCHER" /&gt;
    &lt;/intent-filter&gt;
    ...
&lt;/activity&gt;
</pre>

<p>An intent filter of this kind causes an icon and label for the
activity to be displayed in the application launcher, giving users a way to launch the activity and
to return to the task that it creates any time after it has been launched.
</p>

<p>This second ability is important: Users must be able to leave a task and then come back to it
later using this activity launcher.  For this reason, the two <a href="#LaunchModes">launch
modes</a> that mark activities as always initiating a task, {@code "singleTask"} and "{@code
"singleInstance"}, should be used only when the activity has an {@link
android.content.Intent#ACTION_MAIN}
and a {@link android.content.Intent#CATEGORY_LAUNCHER}
filter. Imagine, for example, what could happen if the filter is missing: An intent launches a
{@code "singleTask"} activity, initiating a new task, and the user spends some time working in
that task.  The user then presses the HOME key. The task is now sent to the background and not
visible. Because it is not represented in the application launcher, the user has no way to return to
the task.
</p>

<p>For those cases where you don't want the user to be able to return to an activity, set the
  <code><a
href="{@docRoot}guide/topics/manifest/activity-element.html">&lt;activity&gt;</a></code> element's
<a href="{@docRoot}guide/topics/manifest/activity-element.html#finish">{@code
finishOnTaskLaunch}</a> to {@code "true"} (see <a
href="#Clearing">Clearing the stack</a>).</p>


<!--
<h2>Beginner's Path</h2>

<p>For more information about how to use intents to
activate other application components and publish the intents to which your components
respond, continue with the <b><a
href="{@docRoot}guide/topics/intents/intents-filters.html">Intents and Intent
Filters</a></b> document.</p>
-->