This class was deprecated
in API level 13.
New applications should use Fragments instead of this class;
to continue to run on older devices, you can use the v4 support library
which provides a version of the Fragment API that is compatible down to
Build.VERSION_CODES.DONUT.

An activity is a single, focused thing that the user can do. Almost all
activities interact with the user, so the Activity class takes care of
creating a window for you in which you can place your UI with
setContentView(View). While activities are often presented to the user
as full-screen windows, they can also be used in other ways: as floating
windows (via a theme with R.attr.windowIsFloating set)
or embedded inside of another activity (using ActivityGroup).
There are two methods almost all subclasses of Activity will implement:

onCreate(Bundle) is where you initialize your activity. Most
importantly, here you will usually call setContentView(int)
with a layout resource defining your UI, and using findViewById(int)
to retrieve the widgets in that UI that you need to interact with
programmatically.

onPause() is where you deal with the user leaving your
activity. Most importantly, any changes made by the user should at this
point be committed (usually to the
ContentProvider holding the data).

Developer Guides

The Activity class is an important part of an application's overall lifecycle,
and the way activities are launched and put together is a fundamental
part of the platform's application model. For a detailed perspective on the structure of an
Android application and how activities behave, please read the
Application Fundamentals and
Tasks and Back Stack
developer guides.

You can also find a detailed discussion about how to create activities in the
Activities
developer guide.

Fragments

The FragmentActivity subclass
can make use of the Fragment class to better
modularize their code, build more sophisticated user interfaces for larger
screens, and help scale their application between small and large screens.

For more information about using fragments, read the
Fragments developer guide.

Activity Lifecycle

Activities in the system are managed as an activity stack.
When a new activity is started, it is placed on the top of the stack
and becomes the running activity -- the previous activity always remains
below it in the stack, and will not come to the foreground again until
the new activity exits.

An activity has essentially four states:

If an activity is in the foreground of the screen (at the top of
the stack),
it is active or running.

If an activity has lost focus but is still visible (that is, a new non-full-sized
or transparent activity has focus on top of your activity), it
is paused. A paused activity is completely alive (it
maintains all state and member information and remains attached to
the window manager), but can be killed by the system in extreme
low memory situations.

If an activity is completely obscured by another activity,
it is stopped. It still retains all state and member information,
however, it is no longer visible to the user so its window is hidden
and it will often be killed by the system when memory is needed
elsewhere.

If an activity is paused or stopped, the system can drop the activity
from memory by either asking it to finish, or simply killing its
process. When it is displayed again to the user, it must be
completely restarted and restored to its previous state.

The following diagram shows the important state paths of an Activity.
The square rectangles represent callback methods you can implement to
perform operations when the Activity moves between states. The colored
ovals are major states the Activity can be in.

There are three key loops you may be interested in monitoring within your
activity:

The entire lifetime of an activity happens between the first call
to onCreate(Bundle) through to a single final call
to onDestroy(). An activity will do all setup
of "global" state in onCreate(), and release all remaining resources in
onDestroy(). For example, if it has a thread running in the background
to download data from the network, it may create that thread in onCreate()
and then stop the thread in onDestroy().

The visible lifetime of an activity happens between a call to
onStart() until a corresponding call to
onStop(). During this time the user can see the
activity on-screen, though it may not be in the foreground and interacting
with the user. Between these two methods you can maintain resources that
are needed to show the activity to the user. For example, you can register
a BroadcastReceiver in onStart() to monitor for changes
that impact your UI, and unregister it in onStop() when the user no
longer sees what you are displaying. The onStart() and onStop() methods
can be called multiple times, as the activity becomes visible and hidden
to the user.

The foreground lifetime of an activity happens between a call to
onResume() until a corresponding call to
onPause(). During this time the activity is
in front of all other activities and interacting with the user. An activity
can frequently go between the resumed and paused states -- for example when
the device goes to sleep, when an activity result is delivered, when a new
intent is delivered -- so the code in these methods should be fairly
lightweight.

The entire lifecycle of an activity is defined by the following
Activity methods. All of these are hooks that you can override
to do appropriate work when the activity changes state. All
activities will implement onCreate(Bundle)
to do their initial setup; many will also implement
onPause() to commit changes to data and
otherwise prepare to stop interacting with the user. You should always
call up to your superclass when implementing these methods.

Called when the activity is first created.
This is where you should do all of your normal static set up:
create views, bind data to lists, etc. This method also
provides you with a Bundle containing the activity's previously
frozen state, if there was one.

Called when the system is about to start resuming a previous
activity. This is typically used to commit unsaved changes to
persistent data, stop animations and other things that may be consuming
CPU, etc. Implementations of this method must be very quick because
the next activity will not be resumed until this method returns.

Followed by either onResume() if the activity
returns back to the front, or onStop() if it becomes
invisible to the user.

Called when the activity is no longer visible to the user, because
another activity has been resumed and is covering this one. This
may happen either because a new activity is being started, an existing
one is being brought in front of this one, or this one is being
destroyed.

Followed by either onRestart() if
this activity is coming back to interact with the user, or
onDestroy() if this activity is going away.

The final call you receive before your
activity is destroyed. This can happen either because the
activity is finishing (someone called finish() on
it), or because the system is temporarily destroying this
instance of the activity to save space. You can distinguish
between these two scenarios with the isFinishing() method.

Yes

nothing

Note the "Killable" column in the above table -- for those methods that
are marked as being killable, after that method returns the process hosting the
activity may be killed by the system at any time without another line
of its code being executed. Because of this, you should use the
onPause() method to write any persistent data (such as user edits)
to storage. In addition, the method
onSaveInstanceState(Bundle) is called before placing the activity
in such a background state, allowing you to save away any dynamic instance
state in your activity into the given Bundle, to be later received in
onCreate(Bundle) if the activity needs to be re-created.
See the Process Lifecycle
section for more information on how the lifecycle of a process is tied
to the activities it is hosting. Note that it is important to save
persistent data in onPause() instead of onSaveInstanceState(Bundle)
because the latter is not part of the lifecycle callbacks, so will not
be called in every situation as described in its documentation.

Be aware that these semantics will change slightly between
applications targeting platforms starting with Build.VERSION_CODES.HONEYCOMB
vs. those targeting prior platforms. Starting with Honeycomb, an application
is not in the killable state until its onStop() has returned. This
impacts when onSaveInstanceState(Bundle) may be called (it may be
safely called after onPause()) and allows an application to safely
wait until onStop() to save persistent state.

For those methods that are not marked as being killable, the activity's
process will not be killed by the system starting from the time the method
is called and continuing after it returns. Thus an activity is in the killable
state, for example, between after onPause() to the start of
onResume().

Configuration Changes

If the configuration of the device (as defined by the
Resources.Configuration class) changes,
then anything displaying a user interface will need to update to match that
configuration. Because Activity is the primary mechanism for interacting
with the user, it includes special support for handling configuration
changes.

Unless you specify otherwise, a configuration change (such as a change
in screen orientation, language, input devices, etc) will cause your
current activity to be destroyed, going through the normal activity
lifecycle process of onPause(),
onStop(), and onDestroy() as appropriate. If the activity
had been in the foreground or visible to the user, once onDestroy() is
called in that instance then a new instance of the activity will be
created, with whatever savedInstanceState the previous instance had generated
from onSaveInstanceState(Bundle).

This is done because any application resource,
including layout files, can change based on any configuration value. Thus
the only safe way to handle a configuration change is to re-retrieve all
resources, including layouts, drawables, and strings. Because activities
must already know how to save their state and re-create themselves from
that state, this is a convenient way to have an activity restart itself
with a new configuration.

In some special cases, you may want to bypass restarting of your
activity based on one or more types of configuration changes. This is
done with the android:configChanges
attribute in its manifest. For any types of configuration changes you say
that you handle there, you will receive a call to your current activity's
onConfigurationChanged(Configuration) method instead of being restarted. If
a configuration change involves any that you do not handle, however, the
activity will still be restarted and onConfigurationChanged(Configuration)
will not be called.

Starting Activities and Getting Results

The startActivity(Intent)
method is used to start a
new activity, which will be placed at the top of the activity stack. It
takes a single argument, an Intent,
which describes the activity
to be executed.

Sometimes you want to get a result back from an activity when it
ends. For example, you may start an activity that lets the user pick
a person in a list of contacts; when it ends, it returns the person
that was selected. To do this, you call the
startActivityForResult(Intent, int)
version with a second integer parameter identifying the call. The result
will come back through your onActivityResult(int, int, Intent)
method.

When an activity exits, it can call
setResult(int)
to return data back to its parent. It must always supply a result code,
which can be the standard results RESULT_CANCELED, RESULT_OK, or any
custom values starting at RESULT_FIRST_USER. In addition, it can optionally
return back an Intent containing any additional data it wants. All of this
information appears back on the
parent's Activity.onActivityResult(), along with the integer
identifier it originally supplied.

If a child activity fails for any reason (such as crashing), the parent
activity will receive a result with the code RESULT_CANCELED.

Saving Persistent State

There are generally two kinds of persistent state that an activity
will deal with: shared document-like data (typically stored in a SQLite
database using a content provider)
and internal state such as user preferences.

For content provider data, we suggest that activities use an
"edit in place" user model. That is, any edits a user makes are effectively
made immediately without requiring an additional confirmation step.
Supporting this model is generally a simple matter of following two rules:

When creating a new document, the backing database entry or file for
it is created immediately. For example, if the user chooses to write
a new email, a new entry for that email is created as soon as they
start entering data, so that if they go to any other activity after
that point this email will now appear in the list of drafts.

When an activity's onPause() method is called, it should
commit to the backing content provider or file any changes the user
has made. This ensures that those changes will be seen by any other
activity that is about to run. You will probably want to commit
your data even more aggressively at key times during your
activity's lifecycle: for example before starting a new
activity, before finishing your own activity, when the user
switches between input fields, etc.

This model is designed to prevent data loss when a user is navigating
between activities, and allows the system to safely kill an activity (because
system resources are needed somewhere else) at any time after it has been
paused. Note this implies
that the user pressing BACK from your activity does not
mean "cancel" -- it means to leave the activity with its current contents
saved away. Canceling edits in an activity must be provided through
some other mechanism, such as an explicit "revert" or "undo" option.

See the content package for
more information about content providers. These are a key aspect of how
different activities invoke and propagate data between themselves.

The Activity class also provides an API for managing internal persistent state
associated with an activity. This can be used, for example, to remember
the user's preferred initial display in a calendar (day view or week view)
or the user's default home page in a web browser.

Activity persistent state is managed
with the method getPreferences(int),
allowing you to retrieve and
modify a set of name/value pairs associated with the activity. To use
preferences that are shared across multiple application components
(activities, receivers, services, providers), you can use the underlying
Context.getSharedPreferences() method
to retrieve a preferences
object stored under a specific name.
(Note that it is not possible to share settings data across application
packages -- for that you will need a content provider.)

Here is an excerpt from a calendar activity that stores the user's
preferred view mode in its persistent settings:

Permissions

The ability to start a particular Activity can be enforced when it is
declared in its
manifest's <activity>
tag. By doing so, other applications will need to declare a corresponding
<uses-permission>
element in their own manifest to be able to start that activity.

Process Lifecycle

The Android system attempts to keep an application process around for as
long as possible, but eventually will need to remove old processes when
memory runs low. As described in Activity
Lifecycle, the decision about which process to remove is intimately
tied to the state of the user's interaction with it. In general, there
are four states a process can be in based on the activities running in it,
listed here in order of importance. The system will kill less important
processes (the last ones) before it resorts to killing more important
processes (the first ones).

The foreground activity (the activity at the top of the screen
that the user is currently interacting with) is considered the most important.
Its process will only be killed as a last resort, if it uses more memory
than is available on the device. Generally at this point the device has
reached a memory paging state, so this is required in order to keep the user
interface responsive.

A visible activity (an activity that is visible to the user
but not in the foreground, such as one sitting behind a foreground dialog)
is considered extremely important and will not be killed unless that is
required to keep the foreground activity running.

A background activity (an activity that is not visible to
the user and has been paused) is no longer critical, so the system may
safely kill its process to reclaim memory for other foreground or
visible processes. If its process needs to be killed, when the user navigates
back to the activity (making it visible on the screen again), its
onCreate(Bundle) method will be called with the savedInstanceState it had previously
supplied in onSaveInstanceState(Bundle) so that it can restart itself in the same
state as the user last left it.

An empty process is one hosting no activities or other
application components (such as Service or
BroadcastReceiver classes). These are killed very
quickly by the system as memory becomes low. For this reason, any
background operation you do outside of an activity must be executed in the
context of an activity BroadcastReceiver or Service to ensure that the system
knows it needs to keep your process around.

Sometimes an Activity may need to do a long-running operation that exists
independently of the activity lifecycle itself. An example may be a camera
application that allows you to upload a picture to a web site. The upload
may take a long time, and the application should allow the user to leave
the application while it is executing. To accomplish this, your Activity
should start a Service in which the upload takes place. This allows
the system to properly prioritize your process (considering it to be more
important than other non-visible applications) for the duration of the
upload, independent of whether the original activity is paused, stopped,
or finished.

Flag for bindService(Intent, ServiceConnection, int): If binding from an activity, allow the
target service's process importance to be raised based on whether the
activity is visible to the user, regardless whether another flag is
used to reduce the amount that the client process's overall importance
is used to impact it.

This constant was deprecated
in API level 23.
MODE_MULTI_PROCESS does not work reliably in
some versions of Android, and furthermore does not provide any
mechanism for reconciling concurrent modifications across
processes. Applications should not attempt to use it. Instead,
they should use an explicit cross-process data management
approach such as ContentProvider.

This constant was deprecated
in API level 17.
Creating world-readable files is very dangerous, and likely
to cause security holes in applications. It is strongly
discouraged; instead, applications should use more formal
mechanism for interactions such as ContentProvider,
BroadcastReceiver, and Service.
There are no guarantees that this access mode will remain on
a file, such as when it goes through a backup and restore.

This constant was deprecated
in API level 17.
Creating world-writable files is very dangerous, and likely
to cause security holes in applications. It is strongly
discouraged; instead, applications should use more formal
mechanism for interactions such as ContentProvider,
BroadcastReceiver, and Service.
There are no guarantees that this access mode will remain on
a file, such as when it goes through a backup and restore.

Level for onTrimMemory(int): the process is around the middle
of the background LRU list; freeing memory can help the system keep
other processes running later in the list for better overall performance.

Level for onTrimMemory(int): the process is not an expendable
background process, but the device is running extremely low on memory
and is about to not be able to keep any background processes running.

If this activity is being destroyed because it can not handle a
configuration parameter being changed (and thus its
onConfigurationChanged(Configuration) method is
not being called), then you can use this method to discover
the set of changes that have occurred while in the process of being
destroyed.

Finds a view that was identified by the android:id XML attribute that was processed
in onCreate(Bundle), or throws an IllegalArgumentException if the ID is invalid, or there is
no matching view in the hierarchy.

This method was deprecated
in API level 23.
Sticky broadcasts should not be used. They provide no security (anyone
can access them), no protection (anyone can modify them), and many other problems.
The recommended pattern is to use a non-sticky broadcast to report that something
has changed, with another mechanism for apps to retrieve the current value whenever
desired.

This method was deprecated
in API level 23.
Sticky broadcasts should not be used. They provide no security (anyone
can access them), no protection (anyone can modify them), and many other problems.
The recommended pattern is to use a non-sticky broadcast to report that something
has changed, with another mechanism for apps to retrieve the current value whenever
desired.

Broadcast the given intent to all interested BroadcastReceivers, delivering
them one at a time to allow more preferred receivers to consume the
broadcast before it is delivered to less preferred receivers.

This method was deprecated
in API level 23.
Sticky broadcasts should not be used. They provide no security (anyone
can access them), no protection (anyone can modify them), and many other problems.
The recommended pattern is to use a non-sticky broadcast to report that something
has changed, with another mechanism for apps to retrieve the current value whenever
desired.

This method was deprecated
in API level 23.
Sticky broadcasts should not be used. They provide no security (anyone
can access them), no protection (anyone can modify them), and many other problems.
The recommended pattern is to use a non-sticky broadcast to report that something
has changed, with another mechanism for apps to retrieve the current value whenever
desired.

This method was deprecated
in API level 23.
Sticky broadcasts should not be used. They provide no security (anyone
can access them), no protection (anyone can modify them), and many other problems.
The recommended pattern is to use a non-sticky broadcast to report that something
has changed, with another mechanism for apps to retrieve the current value whenever
desired.

This method was deprecated
in API level 23.
Sticky broadcasts should not be used. They provide no security (anyone
can access them), no protection (anyone can modify them), and many other problems.
The recommended pattern is to use a non-sticky broadcast to report that something
has changed, with another mechanism for apps to retrieve the current value whenever
desired.

This method was deprecated
in API level 21.
Sticky broadcasts should not be used. They provide no security (anyone
can access them), no protection (anyone can modify them), and many other problems.
The recommended pattern is to use a non-sticky broadcast to report that something
has changed, with another mechanism for apps to retrieve the current value whenever
desired.

This method was deprecated
in API level 21.
Sticky broadcasts should not be used. They provide no security (anyone
can access them), no protection (anyone can modify them), and many other problems.
The recommended pattern is to use a non-sticky broadcast to report that something
has changed, with another mechanism for apps to retrieve the current value whenever
desired.

Broadcast the given intent to all interested BroadcastReceivers, delivering
them one at a time to allow more preferred receivers to consume the
broadcast before it is delivered to less preferred receivers.

This method was deprecated
in API level 21.
Sticky broadcasts should not be used. They provide no security (anyone
can access them), no protection (anyone can modify them), and many other problems.
The recommended pattern is to use a non-sticky broadcast to report that something
has changed, with another mechanism for apps to retrieve the current value whenever
desired.

This method was deprecated
in API level 21.
Sticky broadcasts should not be used. They provide no security (anyone
can access them), no protection (anyone can modify them), and many other problems.
The recommended pattern is to use a non-sticky broadcast to report that something
has changed, with another mechanism for apps to retrieve the current value whenever
desired.

This method was deprecated
in API level 21.
Sticky broadcasts should not be used. They provide no security (anyone
can access them), no protection (anyone can modify them), and many other problems.
The recommended pattern is to use a non-sticky broadcast to report that something
has changed, with another mechanism for apps to retrieve the current value whenever
desired.

This method was deprecated
in API level 21.
Sticky broadcasts should not be used. They provide no security (anyone
can access them), no protection (anyone can modify them), and many other problems.
The recommended pattern is to use a non-sticky broadcast to report that something
has changed, with another mechanism for apps to retrieve the current value whenever
desired.

Causes the current thread to wait until another thread invokes the
notify() method or the
notifyAll() method for this object, or
some other thread interrupts the current thread, or a certain
amount of real time has elapsed.

DEFAULT_KEYS_SEARCH_LOCAL

Use with setDefaultKeyMode(int) to specify that unhandled keystrokes
will start an application-defined search. (If the application or activity does not
actually define a search, the keys will be ignored.)

createPendingResult

Create a new PendingIntent object which you can hand to others
for them to use to send result data back to your
onActivityResult(int, int, Intent) callback. The created object will be either
one-shot (becoming invalid after a result is sent back) or multiple
(allowing any number of results to be sent through it).

Parameters

requestCode

int: Private request code for the sender that will be
associated with the result data when it is returned. The sender can not
modify this value, allowing you to identify incoming results.

data

Intent: Default data to supply in the result, which may be modified
by the sender.

dispatchGenericMotionEvent

Called to process generic motion events. You can override this to
intercept all generic motion events before they are dispatched to the
window. Be sure to call this implementation for generic motion events
that should be handled normally.

Parameters

ev

MotionEvent: The generic motion event.

Returns

boolean

boolean Return true if this event was consumed.

dispatchKeyEvent

Called to process key events. You can override this to intercept all
key events before they are dispatched to the window. Be sure to call
this implementation for key events that should be handled normally.

Parameters

event

KeyEvent: The key event.

Returns

boolean

boolean Return true if this event was consumed.

dispatchKeyShortcutEvent

Called to process a key shortcut event.
You can override this to intercept all key shortcut events before they are
dispatched to the window. Be sure to call this implementation for key shortcut
events that should be handled normally.

dispatchTouchEvent

Called to process touch screen events. You can override this to
intercept all touch screen events before they are dispatched to the
window. Be sure to call this implementation for touch screen events
that should be handled normally.

Parameters

ev

MotionEvent: The touch screen event.

Returns

boolean

boolean Return true if this event was consumed.

dispatchTrackballEvent

Called to process trackball events. You can override this to
intercept all trackball events before they are dispatched to the
window. Be sure to call this implementation for trackball events
that should be handled normally.

enterPictureInPictureMode

Puts the activity in picture-in-picture mode if possible in the current system state. The
set parameters in will be combined with the parameters from prior calls to
setPictureInPictureParams(PictureInPictureParams).
The system may disallow entering picture-in-picture in various cases, including when the
activity is not visible, if the screen is locked or if the user has an activity pinned.

Returns

boolean

true if the system successfully put this activity into picture-in-picture mode or was
already in picture-in-picture mode (@see {@link #isInPictureInPictureMode()). If the device
does not support picture-in-picture, return false.

finishAffinity

Finish this activity as well as all activities immediately below it
in the current task that have the same affinity. This is typically
used when an application can be launched on to another task (such as
from an ACTION_VIEW of a content type it understands) and the user
has used the up navigation to switch out of the current task and in
to its own task. In this case, if the user has navigated down into
any other activities of the second application, all of those should
be removed from the original task as part of the task switch.

Note that this finish does not allow you to deliver results
to the previous activity, and an exception will be thrown if you are trying
to do so.

finishAfterTransition

Reverses the Activity Scene entry Transition and triggers the calling Activity
to reverse its exit Transition. When the exit Transition completes,
finish() is called. If no entry Transition was used, finish() is called
immediately and the Activity exit Transition is run.

getCallingActivity

Return the name of the activity that invoked this activity. This is
who the data in setResult() will be sent to. You
can use this information to validate that the recipient is allowed to
receive the data.

Note: if the calling activity is not expecting a result (that is it
did not use the startActivityForResult(Intent, int)
form that includes a request code), then the calling package will be
null.

getCallingPackage

Return the name of the package that invoked this activity. This is who
the data in setResult() will be sent to. You can
use this information to validate that the recipient is allowed to
receive the data.

Note: if the calling activity is not expecting a result (that is it
did not use the startActivityForResult(Intent, int)
form that includes a request code), then the calling package will be
null.

Note: prior to Build.VERSION_CODES.JELLY_BEAN_MR2,
the result from this method was unstable. If the process hosting the calling
package was no longer running, it would return null instead of the proper package
name. You can use getCallingActivity() and retrieve the package name
from that instead.

getChangingConfigurations

If this activity is being destroyed because it can not handle a
configuration parameter being changed (and thus its
onConfigurationChanged(Configuration) method is
not being called), then you can use this method to discover
the set of changes that have occurred while in the process of being
destroyed. Note that there is no guarantee that these will be
accurate (other changes could have happened at any time), so you should
only use this as an optimization hint.

Returns

int

Returns a bit field of the configuration parameters that are
changing, as defined by the Configuration
class.

Note that the data you retrieve here should only be used
as an optimization for handling configuration changes. You should always
be able to handle getting a null pointer back, and an activity must
still be able to restore itself to its previous state (through the
normal onSaveInstanceState(Bundle) mechanism) even if this
function returns null.

getMaxNumPictureInPictureActions

Return the number of actions that will be displayed in the picture-in-picture UI when the
user interacts with the activity currently in picture-in-picture mode. This number may change
if the global configuration changes (ie. if the device is plugged into an external display),
but will always be larger than three.

getParentActivityIntent

Obtain an Intent that will launch an explicit target activity specified by
this activity's logical parent. The logical parent is named in the application's manifest
by the parentActivityName attribute.
Activity subclasses may override this method to modify the Intent returned by
super.getParentActivityIntent() or to implement a different mechanism of retrieving
the parent intent entirely.

getReferrer

Return information about who launched this activity. If the launching Intent
contains an Intent.EXTRA_REFERRER,
that will be returned as-is; otherwise, if known, an
android-app: referrer URI containing the
package name that started the Intent will be returned. This may return null if no
referrer can be identified -- it is neither explicitly specified, nor is it known which
application package was involved.

If called while inside the handling of onNewIntent(Intent), this function will
return the referrer that submitted that new intent to the activity. Otherwise, it
always returns the referrer of the original Intent.

Note that this is not a security feature -- you can not trust the
referrer information, applications can spoof it.

getRequestedOrientation

Return the current requested orientation of the activity. This will
either be the orientation requested in its component's manifest, or
the last requested orientation given to
setRequestedOrientation(int).

A WifiManager for management of Wi-Fi
connectivity. On releases before NYC, it should only be obtained from an application
context, and not from any other derived context to avoid memory leaks within the calling
process.

Note: System services obtained via this API may be closely associated with
the Context in which they are obtained from. In general, do not share the
service objects between various different contexts (Activities, Applications,
Services, Providers, etc.)

isActivityTransitionRunning

Returns whether there are any activity transitions currently running on this
activity. A return value of true can mean that either an enter or
exit transition is running, including whether the background of the activity
is animating as a part of that transition.

Returns

boolean

true if a transition is currently running on this activity, false otherwise.

isChangingConfigurations

Check to see whether this activity is in the process of being destroyed in order to be
recreated with a new configuration. This is often used in
onStop() to determine whether the state needs to be cleaned up or will be passed
on to the next instance of the activity via onRetainNonConfigurationInstance().

Returns

boolean

If the activity is being torn down in order to be recreated with a new configuration,
returns true; else returns false.

isFinishing

Check to see whether this activity is in the process of finishing,
either because you called finish() on it or someone else
has requested that it finished. This is often used in
onPause() to determine whether the activity is simply pausing or
completely finishing.

isImmersive

Bit indicating that this activity is "immersive" and should not be
interrupted by notifications if possible.
This value is initially set by the manifest property
android:immersive but may be changed at runtime by
setImmersive(boolean).

isVoiceInteraction

Check whether this activity is running as part of a voice interaction with the user.
If true, it should perform its interaction with the user through the
VoiceInteractor returned by getVoiceInteractor().

Returns

boolean

isVoiceInteractionRoot

Like isVoiceInteraction(), but only returns true if this is also the root
of a voice interaction. That is, returns true if this activity was directly
started by the voice interaction service as the initiation of a voice interaction.
Otherwise, for example if it was started by another activity while under voice
interaction, returns false.

Warning: Do not call Cursor.close() on a cursor obtained using
this method, because the activity will do that for you at the appropriate time. However, if
you call stopManagingCursor(Cursor) on a cursor from a managed query, the system will
not automatically close the cursor and, in that case, you must call
Cursor.close().

navigateUpTo

Navigate from this activity to the activity specified by upIntent, finishing this activity
in the process. If the activity indicated by upIntent already exists in the task's history,
this activity and all others before the indicated activity in the history stack will be
finished.

If the indicated activity does not appear in the history stack, this will finish
each activity in this task until the root activity of the task is reached, resulting in
an "in-app home" behavior. This can be useful in apps with a complex navigation hierarchy
when an activity may be reached by a path not passing through a canonical parent
activity.

This method should be used when performing up navigation from within the same task
as the destination. If up navigation should cross tasks in some cases, see
shouldUpRecreateTask(Intent).

Parameters

upIntent

Intent: An intent representing the target destination for up navigation

Returns

boolean

true if up navigation successfully reached the activity indicated by upIntent and
upIntent was delivered to it. false if an instance of the indicated activity could
not be found and this activity was simply finished normally.

navigateUpToFromChild

This is called when a child activity of this one calls its
navigateUpTo(Intent) method. The default implementation simply calls
navigateUpTo(upIntent) on this activity (the parent).

Parameters

child

Activity: The activity making the call.

upIntent

Intent: An intent representing the target destination for up navigation

Returns

boolean

true if up navigation successfully reached the activity indicated by upIntent and
upIntent was delivered to it. false if an instance of the indicated activity could
not be found and this activity was simply finished normally.

onActivityReenter

Called when an activity you launched with an activity transition exposes this
Activity through a returning activity transition, giving you the resultCode
and any additional data from it. This method will only be called if the activity
set a result code other than RESULT_CANCELED and it supports activity
transitions with Window.FEATURE_ACTIVITY_TRANSITIONS.

The purpose of this function is to let the called Activity send a hint about
its state so that this underlying Activity can prepare to be exposed. A call to
this method does not guarantee that the called Activity has or will be exiting soon.
It only indicates that it will expose this Activity's Window and it has
some data to pass to prepare it.

Parameters

resultCode

int: The integer result code returned by the child activity
through its setResult().

data

Intent: An Intent, which can return result data to the caller
(various data can be attached to Intent "extras").

onConfigurationChanged

Called by the system when the device configuration changes while your
activity is running. Note that this will only be called if
you have selected configurations you would like to handle with the
R.attr.configChanges attribute in your manifest. If
any configuration change occurs that is not selected to be reported
by that attribute, then instead of reporting it the system will stop
and restart the activity (to have it launched with the new
configuration).

At the time that this function has been called, your Resources
object will have been updated to return resource values matching the
new configuration.

onContextItemSelected

This hook is called whenever an item in a context menu is selected. The
default implementation simply returns false to have the normal processing
happen (calling the item's Runnable or sending a message to its Handler
as appropriate). You can use this method for any items for which you
would like to do processing without those other facilities.

Bundle: if the activity is being re-initialized after
previously being shut down then this Bundle contains the data it most
recently supplied in onSaveInstanceState(Bundle).
Note: Otherwise it is null.

persistentState

PersistableBundle: if the activity is being re-initialized after
previously being shut down or powered off then this Bundle contains the data it most
recently supplied to outPersistentState in onSaveInstanceState(Bundle).
Note: Otherwise it is null.

onCreateContextMenu

Called when a context menu for the view is about to be shown.
Unlike onCreateOptionsMenu(Menu), this will be called every
time the context menu is about to be shown and should be populated for
the view (or item inside the view for AdapterView subclasses,
this can be found in the menuInfo)).

onCreateDescription

Generate a new description for this activity. This method is called
before stopping the activity and can, if desired, return some textual
description of its current state to be displayed to the user.

The default implementation returns null, which will cause you to
inherit the description from the previous activity. If all activities
return null, generally the label of the top activity will be used as the
description.

onCreateNavigateUpTaskStack

Define the synthetic task stack that will be generated during Up navigation from
a different task.

The default implementation of this method adds the parent chain of this activity
as specified in the manifest to the supplied TaskStackBuilder. Applications
may choose to override this method to construct the desired task stack in a different
way.

onCreateOptionsMenu

Initialize the contents of the Activity's standard options menu. You
should place your menu items in to menu.

This is only called once, the first time the options menu is
displayed. To update the menu every time it is displayed, see
onPrepareOptionsMenu(Menu).

The default implementation populates the menu with standard system
menu items. These are placed in the Menu.CATEGORY_SYSTEM group so that
they will be correctly ordered with application-defined menu items.
Deriving classes should always call through to the base implementation.

You can safely hold on to menu (and any items created
from it), making modifications to it as desired, until the next
time onCreateOptionsMenu() is called.

onEnterAnimationComplete

Activities cannot draw during the period that their windows are animating in. In order
to know when it is safe to begin drawing they can override this method which will be
called when the entering animation has completed.

onGenericMotionEvent

Called when a generic motion event was not handled by any of the
views inside of the activity.

Generic motion events describe joystick movements, mouse hovers, track pad
touches, scroll wheel movements and other input events. The
source of the motion event specifies
the class of input that was received. Implementations of this method
must examine the bits in the source before processing the event.
The following code example shows how this is done.

Generic motion events with source class
InputDevice.SOURCE_CLASS_POINTER
are delivered to the view under the pointer. All other generic motion events are
delivered to the focused view.

onKeyDown

Called when a key was pressed down and not handled by any of the views
inside of the activity. So, for example, key presses while the cursor
is inside a TextView will not trigger the event (unless it is a navigation
to another object) because TextView handles its own key presses.

If the focused view didn't want this event, this method is called.

The default implementation takes care of KeyEvent.KEYCODE_BACK
by calling onBackPressed(), though the behavior varies based
on the application compatibility mode: for
Build.VERSION_CODES.ECLAIR or later applications,
it will set up the dispatch to call onKeyUp(int, KeyEvent) where the action
will be performed; for earlier applications, it will perform the
action immediately in on-down, as those versions of the platform
behaved.

onKeyShortcut

Called when a key shortcut event is not handled by any of the views in the Activity.
Override this method to implement global key shortcuts for the Activity.
Key shortcuts can also be implemented by setting the
shortcut property of menu items.

Parameters

keyCode

int: The value in event.getKeyCode().

event

KeyEvent: Description of the key event.

Returns

boolean

True if the key shortcut was handled.

onKeyUp

Called when a key was released and not handled by any of the views
inside of the activity. So, for example, key presses while the cursor
is inside a TextView will not trigger the event (unless it is a navigation
to another object) because TextView handles its own key presses.

The default implementation handles KEYCODE_BACK to stop the activity
and go back.

Parameters

keyCode

int: The value in event.getKeyCode().

event

KeyEvent: Description of the key event.

Returns

boolean

Return true to prevent this event from being propagated
further, or false to indicate that you have not handled
this event and it should continue to be propagated.

onLocalVoiceInteractionStopped

Callback to indicate that the local voice interaction has stopped either
because it was requested through a call to stopLocalVoiceInteraction()
or because it was canceled by the user. The previously acquired VoiceInteractor
is no longer valid after this.

onLowMemory

This is called when the overall system is running low on memory, and
actively running processes should trim their memory usage. While
the exact point at which this will be called is not defined, generally
it will happen when all background process have been killed.
That is, before reaching the point of killing processes hosting
service and foreground UI that we would like to avoid killing.

You should implement this method to release
any caches or other unnecessary resources you may be holding on to.
The system will perform a garbage collection for you after returning from this method.

onMultiWindowModeChanged

Called by the system when the activity changes from fullscreen mode to multi-window mode and
visa-versa. This method provides the same configuration that will be sent in the following
onConfigurationChanged(Configuration) call after the activity enters this mode.

onNavigateUp

This method is called whenever the user chooses to navigate Up within your application's
activity hierarchy from the action bar.

If the attribute parentActivityName
was specified in the manifest for this activity or an activity-alias to it,
default Up navigation will be handled automatically. If any activity
along the parent chain requires extra Intent arguments, the Activity subclass
should override the method onPrepareNavigateUpTaskStack(TaskStackBuilder)
to supply those arguments.

onOptionsItemSelected

This hook is called whenever an item in your options menu is selected.
The default implementation simply returns false to have the normal
processing happen (calling the item's Runnable or sending a message to
its Handler as appropriate). You can use this method for any items
for which you would like to do processing without those other
facilities.

Derived classes should call through to the base class for it to
perform the default menu handling.

onPictureInPictureModeChanged

Called by the system when the activity changes to and from picture-in-picture mode. This
method provides the same configuration that will be sent in the following
onConfigurationChanged(Configuration) call after the activity enters this mode.

onPrepareOptionsMenu

Prepare the Screen's standard options menu to be displayed. This is
called right before the menu is shown, every time it is shown. You can
use this method to efficiently enable/disable items or otherwise
dynamically modify the contents.

The default implementation updates the system menu items based on the
activity's state. Deriving classes should always call through to the
base class implementation.

Parameters

menu

Menu: The options menu as last shown or first initialized by
onCreateOptionsMenu().

Returns

boolean

You must return true for the menu to be displayed;
if you return false it will not be shown.

Custom implementation may adjust the content intent to better reflect the top-level
context of the activity, and fill in its ClipData with additional content of
interest that the user is currently viewing. For example, an image gallery application
that has launched in to an activity allowing the user to swipe through pictures should
modify the intent to reference the current image they are looking it; such an
application when showing a list of pictures should add a ClipData that has
references to all of the pictures currently visible on screen.

Parameters

outContent

AssistContent: The assist content to return.

onProvideAssistData

This is called when the user is requesting an assist, to build a full
Intent.ACTION_ASSIST Intent with all of the context of the current
application. You can override this method to place into the bundle anything
you would like to appear in the Intent.EXTRA_ASSIST_CONTEXT part
of the assist Intent.

onProvideReferrer

Override to generate the desired referrer for the content currently being shown
by the app. The default implementation returns null, meaning the referrer will simply
be the android-app: of the package name of this activity. Return a non-null Uri to
have that supplied as the Intent.EXTRA_REFERRER of any activities started from it.

Note: It is possible that the permissions request interaction
with the user is interrupted. In this case you will receive empty permissions
and results arrays which should be treated as a cancellation.

A new instance of the activity will always be immediately
created after this one's onDestroy() is called. In particular,
no messages will be dispatched during this time (when the returned
object does not have an activity to be associated with).

These guarantees are designed so that an activity can use this API
to propagate extensive state from the old to new activity instance, from
loaded bitmaps, to network connections, to evenly actively running
threads. Note that you should not propagate any data that
may change based on the configuration, including any data loaded from
resources such as strings, layouts, or drawables.

The guarantee of no message handling during the switch to the next
activity simplifies use with active objects. For example if your retained
state is an AsyncTask you are guaranteed that its
call back functions (like AsyncTask.onPostExecute(Result)) will
not be called from the call here until you execute the next instance's
onCreate(Bundle). (Note however that there is of course no such
guarantee for AsyncTask.doInBackground(Params...) since that is
running in a separate thread.)

onSearchRequested

This hook is called when the user signals the desire to start a search.

You can use this function as a simple way to launch the search UI, in response to a
menu item, search button, or other widgets within your activity. Unless overidden,
calling this function is the same as calling
startSearch(null, false, null, false), which launches
search for the current activity as specified in its manifest, see SearchManager.

You can override this function to force global search, e.g. in response to a dedicated
search key, or to block search entirely (by simply returning false).

Returns true if search launched, and false if the activity does
not respond to search. The default implementation always returns true, except
when in Configuration.UI_MODE_TYPE_TELEVISION mode where it returns false.

onTouchEvent

Called when a touch screen event was not handled by any of the views
under it. This is most useful to process touch events that happen
outside of your window bounds, where there is no view to receive it.

Parameters

event

MotionEvent: The touch screen event being processed.

Returns

boolean

Return true if you have consumed the event, false if you haven't.
The default implementation always returns false.

onTrackballEvent

Called when the trackball was moved and not handled by any of the
views inside of the activity. So, for example, if the trackball moves
while focus is on a button, you will receive a call here because
buttons do not normally do anything with trackball events. The call
here happens before trackball movements are converted to
DPAD key events, which then get sent back to the view hierarchy, and
will be processed at the point for things like focus navigation.

Parameters

event

MotionEvent: The trackball event being processed.

Returns

boolean

Return true if you have consumed the event, false if you haven't.
The default implementation always returns false.

onTrimMemory

Called when the operating system has determined that it is a good
time for a process to trim unneeded memory from its process. This will
happen for example when it goes in the background and there is not enough
memory to keep as many background processes running as desired. You
should never compare to exact values of the level, since new intermediate
values may be added -- you will typically want to compare if the value
is greater or equal to a level you are interested in.

onUserInteraction

Called whenever a key, touch, or trackball event is dispatched to the
activity. Implement this method if you wish to know that the user has
interacted with the device in some way while your activity is running.
This callback and onUserLeaveHint() are intended to help
activities manage status bar notifications intelligently; specifically,
for helping activities determine the proper time to cancel a notification.

All calls to your activity's onUserLeaveHint() callback will
be accompanied by calls to onUserInteraction(). This
ensures that your activity will be told of relevant user activity such
as pulling down the notification pane and touching an item there.

Note that this callback will be invoked for the touch down action
that begins a touch gesture, but may not be invoked for the touch-moved
and touch-up actions that follow.

onVisibleBehindCanceled

This method was deprecated
in API level 26.
This method's functionality is no longer supported as of
Build.VERSION_CODES.O and will be removed in a future release.

Called when a translucent activity over this activity is becoming opaque or another
activity is being launched. Activities that override this method must call
super.onVisibleBehindCanceled() or a SuperNotCalledException will be thrown.

When this method is called the activity has 500 msec to release any resources it may be
using while visible in the background.
If the activity has not returned from this method in 500 msec the system will destroy
the activity and kill the process in order to recover the resources for another
process. Otherwise onStop() will be called following return.

If you override this method you must call through to the
superclass implementation.

onWindowFocusChanged

Called when the current Window of the activity gains or loses
focus. This is the best indicator of whether this activity is visible
to the user. The default implementation clears the key tracking
state, so should always be called.

Note that this provides information about global focus state, which
is managed independently of activity lifecycles. As such, while focus
changes will generally have some relation to lifecycle changes (an
activity that is stopped will not generally get window focus), you
should not rely on any particular order between the callbacks here and
those in the other lifecycle methods such as onResume().

As a general rule, however, a resumed activity will have window
focus... unless it has displayed other dialogs or popups that take
input focus, in which case the activity itself will not have focus
when the other windows have it. Likewise, the system may display
system-level windows (such as the status bar notification panel or
a system alert) which will temporarily take window input focus without
pausing the foreground activity.

onWindowStartingActionMode

Called when an action mode is being started for this window. Gives the
callback an opportunity to handle the action mode in its own unique and
beautiful way. If this method returns null the system can choose a way
to present the mode or choose not to start the mode at all.

Parameters

callback

ActionMode.Callback: Callback to control the lifecycle of this action mode

recreate

Cause this Activity to be recreated with a new instance. This results
in essentially the same flow as when the Activity is created due to
a configuration change -- the current instance will go through its
lifecycle to onDestroy() and a new instance then created after it.

releaseInstance

Ask that the local app instance of this activity be released to free up its memory.
This is asking for the activity to be destroyed, but does not finish the activity --
a new instance of the activity will later be re-created if needed due to the user
navigating back to it.

Returns

boolean

Returns true if the activity was in a state that it has started the process
of destroying its current instance; returns false if for any reason this could not
be done: it is currently visible to the user, it is already being destroyed, it is
being finished, it hasn't yet saved its state, etc.

reportFullyDrawn

Report to the system that your app is now fully drawn, purely for diagnostic
purposes (calling it does not impact the visible behavior of the activity).
This is only used to help instrument application launch times, so that the
app can report when it is fully in a usable state; without this, the only thing
the system itself can determine is the point at which the activity's window
is first drawn and displayed. To participate in app launch time
measurement, you should always call this method after first launch (when
onCreate(android.os.Bundle) is called), at the point where you have
entirely drawn your UI and populated with all of the significant data. You
can safely call this method any time after first launch as well, in which case
it will simply be ignored.

requestPermissions

Requests permissions to be granted to this application. These permissions
must be requested in your manifest, they should not be granted to your app,
and they should have protection level #PROTECTION_DANGEROUS dangerous, regardless whether they are declared by
the platform or a third-party app.

If your app does not have the requested permissions the user will be presented
with UI for accepting them. After the user has accepted or rejected the
requested permissions you will receive a callback on onRequestPermissionsResult(int, String[], int[]) reporting whether the
permissions were granted or not.

Note that requesting a permission does not guarantee it will be granted and
your app should be able to run without having this permission.

This method may start an activity allowing the user to choose which permissions
to grant and which to reject. Hence, you should be prepared that your activity
may be paused and resumed. Further, granting some permissions may require
a restart of you application. In such a case, the system will recreate the
activity stack before delivering the result to onRequestPermissionsResult(int, String[], int[]).

Calling this API for permissions already granted to your app would show UI
to the user to decide whether the app can still hold these permissions. This
can be useful if the way your app uses data guarded by the permissions
changes significantly.

requestVisibleBehind

This method was deprecated
in API level 26.
This method's functionality is no longer supported as of
Build.VERSION_CODES.O and will be removed in a future release.

Activities that want to remain visible behind a translucent activity above them must call
this method anytime between the start of onResume() and the return from
onPause(). If this call is successful then the activity will remain visible after
onPause() is called, and is allowed to continue playing media in the background.

The actions of this call are reset each time that this activity is brought to the
front. That is, every time onResume() is called the activity will be assumed
to not have requested visible behind. Therefore, if you want this activity to continue to
be visible in the background you must call this method again.

Only fullscreen opaque activities may make this call. I.e. this call is a nop
for dialog and translucent activities.

Under all circumstances, the activity must stop playing and release resources prior to or
within a call to onVisibleBehindCanceled() or if this call returns false.

False will be returned any time this method is called between the return of onPause and
the next call to onResume.

Parameters

visible

boolean: true to notify the system that the activity wishes to be visible behind other
translucent activities, false to indicate otherwise. Resources must be
released when passing false to this method.

Returns

boolean

the resulting visibiity state. If true the activity will remain visible beyond
onPause() if the next activity is translucent or not fullscreen. If false
then the activity may not count on being visible behind other translucent activities,
and must stop any media playback and release resources.
Returning false may occur in lieu of a call to onVisibleBehindCanceled() so
the return value must be checked.

requireViewById

Finds a view that was identified by the android:id XML attribute that was processed
in onCreate(Bundle), or throws an IllegalArgumentException if the ID is invalid, or there is
no matching view in the hierarchy.

Note: In most cases -- depending on compiler support --
the resulting view is automatically cast to the target class type. If
the target class type is unconstrained, an explicit cast may be
necessary.

runOnUiThread

Runs the specified action on the UI thread. If the current thread is the UI
thread, then the action is executed immediately. If the current thread is
not the UI thread, the action is posted to the event queue of the UI thread.

Parameters

action

Runnable: the action to run on the UI thread

setActionBar

When set to a non-null value the getActionBar() method will return
an ActionBar object that can be used to control the given toolbar as if it were
a traditional window decor action bar. The toolbar's menu will be populated with the
Activity's options menu and the navigation button will be wired through the standard
home menu select action.

In order to use a Toolbar within the Activity's window content the application
must not request the window feature FEATURE_ACTION_BAR.

Parameters

toolbar

Toolbar: Toolbar to set as the Activity's action bar, or null to clear it

Note that the mode selected here does not impact the default
handling of system keys, such as the "back" and "menu" keys, and your
activity and its views always get a first chance to receive and handle
all application keys.

setImmersive

Adjust the current immersive mode setting.
Note that changing this value will have no effect on the activity's
ActivityInfo structure; that is, if
android:immersive is set to true
in the application's manifest entry for this activity, the ActivityInfo.flags member will
always have its FLAG_IMMERSIVE bit set.

setMediaController

The controller will be tied to the window of this Activity. Media key and
volume events which are received while the Activity is in the foreground
will be forwarded to the controller and used to invoke transport controls
or adjust the volume. This may be used instead of or in addition to
setVolumeControlStream(int) to affect a specific session instead of a
specific stream.

It is not guaranteed that the hardware volume controls will always change
this session's volume (for example, if a call is in progress, its
stream's volume may be changed instead). To reset back to the default use
null as the controller.

Parameters

controller

MediaController: The controller for the session which should receive
media keys and volume changes.

setRequestedOrientation

Change the desired orientation of this activity. If the activity
is currently in the foreground or otherwise impacting the screen
orientation, the screen will immediately be changed (possibly causing
the activity to be restarted). Otherwise, this will be used the next
time the activity is visible.

setSecondaryProgress

This method was deprecated
in API level 24.
No longer supported starting in API 21.

Sets the secondary progress for the progress bar in the title. This
progress is drawn between the primary progress (set via
setProgress(int) and the background. It can be ideal for media
scenarios such as showing the buffering progress while the default
progress shows the play progress.

setShowWhenLocked

Specifies whether an Activity should be shown on top of the lock screen whenever
the lockscreen is up and the activity is resumed. Normally an activity will be transitioned
to the stopped state if it is started while the lockscreen is up, but with this flag set the
activity will remain in the resumed state visible on-top of the lock screen. This value can
be set as a manifest attribute using R.attr.showWhenLocked.

Parameters

showWhenLocked

boolean: true to show the Activity on top of the lock screen;
false otherwise.

setTaskDescription

Sets information describing the task with this activity for presentation inside the Recents
System UI. When ActivityManager.getRecentTasks(int, int) is called, the activities of each task
are traversed in order from the topmost activity to the bottommost. The traversal continues
for each property until a suitable value is found. For each task the taskDescription will be
returned in ActivityManager.TaskDescription.

Parameters

taskDescription

ActivityManager.TaskDescription: The TaskDescription properties that describe the task with this activity

setTurnScreenOn

Specifies whether the screen should be turned on when the Activity is resumed.
Normally an activity will be transitioned to the stopped state if it is started while the
screen if off, but with this flag set the activity will cause the screen to turn on if the
activity will be visible and resumed due to the screen coming on. The screen will not be
turned on if the activity won't be visible after the screen is turned on. This flag is
normally used in conjunction with the R.attr.showWhenLocked flag to make sure
the activity is visible after the screen is turned on when the lockscreen is up. In addition,
if this flag is set and the activity calls KeyguardManager.requestDismissKeyguard(Activity, KeyguardManager.KeyguardDismissCallback)
the screen will turn on.

setVisible

Control whether this activity's main window is visible. This is intended
only for the special case of an activity that is not going to show a
UI itself, but can't just finish prior to onResume() because it needs
to wait for a service binding or such. Setting this to false allows
you to prevent your UI from being shown during that time.

setVolumeControlStream

Suggests an audio stream whose volume should be changed by the hardware
volume controls.

The suggested audio stream will be tied to the window of this Activity.
Volume requests which are received while the Activity is in the
foreground will affect this stream.

It is not guaranteed that the hardware volume controls will always change
this stream's volume (for example, if a call is in progress, its stream's
volume may be changed instead). To reset back to the default, use
AudioManager.USE_DEFAULT_STREAM_TYPE.

Parameters

streamType

int: The type of the audio stream whose volume should be
changed by the hardware volume controls.

shouldShowRequestPermissionRationale

Gets whether you should show UI with rationale for requesting a permission.
You should do this only if you do not have the permission and the context in
which the permission is requested does not clearly communicate to the user
what would be the benefit from granting this permission.

For example, if you write a camera app, requesting the camera permission
would be expected by the user and no rationale for why it is requested is
needed. If however, the app needs location for tagging photos then a non-tech
savvy user may wonder how location is related to taking photos. In this case
you may choose to show UI with rationale of requesting this permission.

shouldUpRecreateTask

Returns true if the app should recreate the task when navigating 'up' from this activity
by using targetIntent.

If this method returns false the app can trivially call
navigateUpTo(Intent) using the same parameters to correctly perform
up navigation. If this method returns false, the app should synthesize a new task stack
by using TaskStackBuilder or another similar mechanism to perform up navigation.

Parameters

targetIntent

Intent: An intent representing the target destination for up navigation

Returns

boolean

true if navigating up should recreate a new task stack, false if the same task
should be used for the destination

showLockTaskEscapeMessage

Shows the user the system defined message for telling the user how to exit
lock task mode. The task containing this activity must be in lock task mode at the time
of this call for the message to be displayed.

startActivities

Launch a new activity. You will not receive any information about when
the activity exits. This implementation overrides the base version,
providing information about
the activity performing the launch. Because of this additional
information, the Intent.FLAG_ACTIVITY_NEW_TASK launch flag is not
required; if not specified, the new activity will be added to the
task of the caller.

startActivity

Launch a new activity. You will not receive any information about when
the activity exits. This implementation overrides the base version,
providing information about
the activity performing the launch. Because of this additional
information, the Intent.FLAG_ACTIVITY_NEW_TASK launch flag is not
required; if not specified, the new activity will be added to the
task of the caller.

startActivityForResult

Launch an activity for which you would like a result when it finished.
When this activity exits, your
onActivityResult() method will be called with the given requestCode.
Using a negative requestCode is the same as calling
startActivity(Intent) (the activity is not launched as a sub-activity).

Note that this method should only be used with Intent protocols
that are defined to return a result. In other protocols (such as
Intent.ACTION_MAIN or Intent.ACTION_VIEW), you may
not get the result when you expect. For example, if the activity you
are launching uses Intent.FLAG_ACTIVITY_NEW_TASK, it will not
run in your task and thus you will immediately receive a cancel result.

As a special case, if you call startActivityForResult() with a requestCode
>= 0 during the initial onCreate(Bundle savedInstanceState)/onResume() of your
activity, then your window will not be displayed until a result is
returned back from the started activity. This is to avoid visible
flickering when redirecting to another activity.

startActivityIfNeeded

A special variation to launch an activity only if a new activity
instance is needed to handle the given Intent. In other words, this is
just like startActivityForResult(Intent, int) except: if you are
using the Intent.FLAG_ACTIVITY_SINGLE_TOP flag, or
singleTask or singleTop
launchMode,
and the activity
that handles intent is the same as your currently running
activity, then a new instance is not needed. In this case, instead of
the normal behavior of calling onNewIntent(Intent) this function will
return and you can handle the Intent yourself.

This function can only be called from a top-level activity; if it is
called from a child activity, a runtime exception will be thrown.

int: Intent flags in the original IntentSender that you
would like to change.

flagsValues

int: Desired values for any bits set in
flagsMask

extraFlags

int: Always set to 0.

options

Bundle: Additional options for how the Activity should be started.
See Context.startActivity(Intent, Bundle)
Context.startActivity(Intent, Bundle)} for more details. If options
have also been supplied by the IntentSender, options given here will
override any that conflict with those given by the IntentSender.

int: Intent flags in the original IntentSender that you
would like to change.

flagsValues

int: Desired values for any bits set in
flagsMask

extraFlags

int: Always set to 0.

options

Bundle: Additional options for how the Activity should be started.
See Context.startActivity(Intent, Bundle)
Context.startActivity(Intent, Bundle)} for more details. If options
have also been supplied by the IntentSender, options given here will
override any that conflict with those given by the IntentSender.

Otherwise, the current task will be launched into screen pinning mode. In this case, the
system will prompt the user with a dialog requesting permission to use this mode.
The user can exit at any time through instructions shown on the request dialog. Calling
stopLockTask() will also terminate this mode.

Note: this method can only be called when the activity is foreground.
That is, between onResume() and onPause().

startManagingCursor

This method was deprecated
in API level 11.
Use the new CursorLoader class with
LoaderManager instead; this is also
available on older platforms through the Android compatibility package.

This method allows the activity to take care of managing the given
Cursor's lifecycle for you based on the activity's lifecycle.
That is, when the activity is stopped it will automatically call
Cursor.deactivate() on the given Cursor, and when it is later restarted
it will call Cursor.requery() for you. When the activity is
destroyed, all managed Cursors will be closed automatically.
If you are targeting Build.VERSION_CODES.HONEYCOMB
or later, consider instead using LoaderManager instead, available
via getLoaderManager().

startNextMatchingActivity

Special version of starting an activity, for use when you are replacing
other activity components. You can use this to hand the Intent off
to the next Activity that can handle it. You typically call this in
onCreate(Bundle) with the Intent returned by getIntent().

Parameters

intent

Intent: The intent to dispatch to the next activity. For
correct behavior, this must be the same as the Intent that started
your own activity; the only changes you can make are to the extras
inside of it.

Returns a boolean indicating whether there was another Activity
to start: true if there was a next activity to start, false if there
wasn't. In general, if true is returned you will then want to call
finish() on yourself.

startNextMatchingActivity

Intent: The intent to dispatch to the next activity. For
correct behavior, this must be the same as the Intent that started
your own activity; the only changes you can make are to the extras
inside of it.

This value must never be null.

Returns

boolean

Returns a boolean indicating whether there was another Activity
to start: true if there was a next activity to start, false if there
wasn't. In general, if true is returned you will then want to call
finish() on yourself.

startSearch

It is typically called from onSearchRequested(), either directly from
Activity.onSearchRequested() or from an overridden version in any given
Activity. If your goal is simply to activate search, it is preferred to call
onSearchRequested(), which may have been overridden elsewhere in your Activity. If your goal
is to inject specific data such as context data, it is preferred to override
onSearchRequested(), so that any callers to it will benefit from the override.

String: Any non-null non-empty string will be inserted as
pre-entered text in the search query box.

selectInitialQuery

boolean: If true, the initial query will be preselected, which means that
any further typing will replace it. This is useful for cases where an entire pre-formed
query is being inserted. If false, the selection point will be placed at the end of the
inserted query. This is useful when the inserted query is text that the user entered,
and the user would expect to be able to keep typing. This parameter is only meaningful
if initialQuery is a non-empty string.

appSearchData

Bundle: An application can insert application-specific
context here, in order to improve quality or specificity of its own
searches. This data will be returned with SEARCH intent(s). Null if
no extra data is required.

This value may be null.

globalSearch

boolean: If false, this will only launch the search that has been specifically
defined by the application (which is usually defined as a local search). If no default
search is defined in the current application or activity, global search will be launched.
If true, this will always launch a platform-global (e.g. web-based) search instead.

stopLockTask

Called to end the LockTask or screen pinning mode started by startLockTask().
This can only be called by activities that have called startLockTask() previously.

Note: If the device is in LockTask mode that is not initially started
by this activity, then calling this method will not terminate the LockTask mode, but only
finish its own task. The device will remain in LockTask mode, until the activity which
started the LockTask mode calls this method, or until its whitelist authorization is revoked
by DevicePolicyManager.setLockTaskPackages(ComponentName, String[]).

Bundle: An application can insert application-specific
context here, in order to improve quality or specificity of its own
searches. This data will be returned with SEARCH intent(s). Null if
no extra data is required.

onActivityResult

Called when an activity you launched exits, giving you the requestCode
you started it with, the resultCode it returned, and any additional
data from it. The resultCode will be
RESULT_CANCELED if the activity explicitly returned that,
didn't return any result, or crashed during its operation.

You will receive this call immediately before onResume() when your
activity is re-starting.

onApplyThemeResource

Called by setTheme(int) and getTheme() to apply a theme
resource to the current Theme object. May be overridden to change the
default (simple) behavior. This method will not be called in multiple
threads simultaneously.

Parameters

theme

Resources.Theme: the theme being modified

resid

int: the style resource being applied to theme

first

boolean: true if this is the first time a style is being
applied to theme

If you override this method you must call through to the
superclass implementation.

Parameters

savedInstanceState

Bundle: If the activity is being re-initialized after
previously being shut down then this Bundle contains the data it most
recently supplied in onSaveInstanceState(Bundle). Note: Otherwise it is null.

If you use showDialog(int), the activity will call through to
this method the first time, and hang onto it thereafter. Any dialog
that is created by this method will automatically be saved and restored
for you, including whether it is showing.

If you would like the activity to manage saving and restoring dialogs
for you, you should override this method and handle any ids that are
passed to showDialog(int).

onDestroy

Perform any final cleanup before an activity is destroyed. This can
happen either because the activity is finishing (someone called
finish() on it), or because the system is temporarily destroying
this instance of the activity to save space. You can distinguish
between these two scenarios with the isFinishing() method.

Note: do not count on this method being called as a place for
saving data! For example, if an activity is editing data in a content
provider, those edits should be committed in either onPause() or
onSaveInstanceState(Bundle), not here. This method is usually implemented to
free resources like threads that are associated with an activity, so
that a destroyed activity does not leave such things around while the
rest of its application is still running. There are situations where
the system will simply kill the activity's hosting process without
calling this method (or any others) in it, so it should not be used to
do things that are intended to remain around after the process goes
away.

Derived classes must call through to the super class's
implementation of this method. If they do not, an exception will be
thrown.

If you override this method you must call through to the
superclass implementation.

onNewIntent

This is called for activities that set launchMode to "singleTop" in
their package, or if a client used the Intent.FLAG_ACTIVITY_SINGLE_TOP
flag when calling startActivity(Intent). In either case, when the
activity is re-launched while at the top of the activity stack instead
of a new instance of the activity being started, onNewIntent() will be
called on the existing instance with the Intent that was used to
re-launch it.

An activity will always be paused before receiving a new intent, so
you can count on onResume() being called after this method.

onPause

Called as part of the activity lifecycle when an activity is going into
the background, but has not (yet) been killed. The counterpart to
onResume().

When activity B is launched in front of activity A, this callback will
be invoked on A. B will not be created until A's onPause() returns,
so be sure to not do anything lengthy here.

This callback is mostly used for saving any persistent state the
activity is editing, to present a "edit in place" model to the user and
making sure nothing is lost if there are not enough resources to start
the new activity without first killing this one. This is also a good
place to do things like stop animations and other things that consume a
noticeable amount of CPU in order to make the switch to the next activity
as fast as possible, or to close resources that are exclusive access
such as the camera.

In situations where the system needs more memory it may kill paused
processes to reclaim resources. Because of this, you should be sure
that all of your state is saved by the time you return from
this function. In general onSaveInstanceState(Bundle) is used to save
per-instance state in the activity and this method is used to store
global persistent data (in content providers, files, etc.)

After receiving this call you will usually receive a following call
to onStop() (after the next activity has been resumed and
displayed), however in some cases there will be a direct call back to
onResume() without going through the stopped state.

Derived classes must call through to the super class's
implementation of this method. If they do not, an exception will be
thrown.

If you override this method you must call through to the
superclass implementation.

onPostCreate

Called when activity start-up is complete (after onStart()
and onRestoreInstanceState(Bundle) have been called). Applications will
generally not implement this method; it is intended for system
classes to do final initialization after application code has run.

Derived classes must call through to the super class's
implementation of this method. If they do not, an exception will be
thrown.

If you override this method you must call through to the
superclass implementation.

Parameters

savedInstanceState

Bundle: If the activity is being re-initialized after
previously being shut down then this Bundle contains the data it most
recently supplied in onSaveInstanceState(Bundle). Note: Otherwise it is null.

onPostResume

Called when activity resume is complete (after onResume() has
been called). Applications will generally not implement this method;
it is intended for system classes to do final setup after application
resume code has run.

Derived classes must call through to the super class's
implementation of this method. If they do not, an exception will be
thrown.

If you override this method you must call through to the
superclass implementation.

onPrepareDialog

This method was deprecated
in API level 13.
Use the new DialogFragment class with
FragmentManager instead; this is also
available on older platforms through the Android compatibility package.

Provides an opportunity to prepare a managed dialog before it is being
shown. The default implementation calls through to
onPrepareDialog(int, Dialog) for compatibility.

Override this if you need to update a managed dialog based on the state
of the application each time it is shown. For example, a time picker
dialog might want to be updated with the current time. You should call
through to the superclass's implementation. The default implementation
will set this Activity as the owner activity on the Dialog.

onRestoreInstanceState

This method is called after onStart() when the activity is
being re-initialized from a previously saved state, given here in
savedInstanceState. Most implementations will simply use onCreate(Bundle)
to restore their state, but it is sometimes convenient to do it here
after all of the initialization has been done or to allow subclasses to
decide whether to use your default implementation. The default
implementation of this method performs a restore of any view state that
had previously been frozen by onSaveInstanceState(Bundle).

Keep in mind that onResume is not the best indicator that your activity
is visible to the user; a system window such as the keyguard may be in
front. Use onWindowFocusChanged(boolean) to know for certain that your
activity is visible to the user (for example, to resume a game).

Derived classes must call through to the super class's
implementation of this method. If they do not, an exception will be
thrown.

If you override this method you must call through to the
superclass implementation.

This method is called before an activity may be killed so that when it
comes back some time in the future it can restore its state. For example,
if activity B is launched in front of activity A, and at some point activity
A is killed to reclaim resources, activity A will have a chance to save the
current state of its user interface via this method so that when the user
returns to activity A, the state of the user interface can be restored
via onCreate(Bundle) or onRestoreInstanceState(Bundle).

Do not confuse this method with activity lifecycle callbacks such as
onPause(), which is always called when an activity is being placed
in the background or on its way to destruction, or onStop() which
is called before destruction. One example of when onPause() and
onStop() is called and not this method is when a user navigates back
from activity B to activity A: there is no need to call onSaveInstanceState(Bundle)
on B because that particular instance will never be restored, so the
system avoids calling it. An example when onPause() is called and
not onSaveInstanceState(Bundle) is when activity B is launched in front of activity A:
the system may avoid calling onSaveInstanceState(Bundle) on activity A if it isn't
killed during the lifetime of B since the state of the user interface of
A will stay intact.

The default implementation takes care of most of the UI per-instance
state for you by calling View.onSaveInstanceState() on each
view in the hierarchy that has an id, and by saving the id of the currently
focused view (all of which is restored by the default implementation of
onRestoreInstanceState(Bundle)). If you override this method to save additional
information not captured by each individual view, you will likely want to
call through to the default implementation, otherwise be prepared to save
all of the state of each view yourself.

If called, this method will occur after onStop() for applications
targeting platforms starting with Build.VERSION_CODES.P.
For applications targeting earlier platform versions this method will occur
before onStop() and there are no guarantees about whether it will
occur before or after onPause().

onTitleChanged

onUserLeaveHint

Called as part of the activity lifecycle when an activity is about to go
into the background as the result of user choice. For example, when the
user presses the Home key, onUserLeaveHint() will be called, but
when an incoming phone call causes the in-call Activity to be automatically
brought to the foreground, onUserLeaveHint() will not be called on
the activity being interrupted. In cases when it is invoked, this method
is called right before the activity's onPause() callback.

This callback and onUserInteraction() are intended to help
activities manage status bar notifications intelligently; specifically,
for helping activities determine the proper time to cancel a notification.