A Service is an application component representing either an application's desire
to perform a longer-running operation while not interacting with the user
or to supply functionality for other applications to use.

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
DONUT.

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.

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.

Public constructors

ContextWrapper

Public methods

bindService

Connect to an application service, creating it if needed. This defines
a dependency between your application and the service. The given
conn will receive the service object when it is created and be
told if it dies and restarts. The service will be considered required
by the system only for as long as the calling context exists. For
example, if this Context is an Activity that is stopped, the service will
not be required to continue running until the Activity is resumed.

This function will throw SecurityException if you do not
have permission to bind to the given service.

Note: this method can not be called from a
BroadcastReceiver component. A pattern you can use to
communicate from a BroadcastReceiver to a Service is to call
startService(Intent) with the arguments containing the command to be
sent, with the service calling its
stopSelf(int) method when done executing
that command. See the API demo App/Service/Service Start Arguments
Controller for an illustration of this. It is okay, however, to use
this method from a BroadcastReceiver that has been registered with
registerReceiver(BroadcastReceiver, IntentFilter), since the lifetime of this BroadcastReceiver
is tied to another object (the one that registered it).

Parameters

service

Intent: Identifies the service to connect to. The Intent must
specify an explicit component name.

conn

ServiceConnection: Receives information as the service is started and stopped.
This must be a valid ServiceConnection object; it must not be null.

If you have successfully bound to the service, true is returned;
false is returned if the connection is not made so you will not
receive the service object. However, you should still call
unbindService(ServiceConnection) to release the connection.

checkCallingOrSelfPermission

Determine whether the calling process of an IPC or you have been
granted a particular permission. This is the same as
checkCallingPermission(String), except it grants your own permissions
if you are not currently processing an IPC. Use with care!

checkCallingOrSelfUriPermission

Determine whether the calling process of an IPC or you has been granted
permission to access a specific URI. This is the same as
checkCallingUriPermission(Uri, int), except it grants your own permissions
if you are not currently processing an IPC. Use with care!

checkCallingPermission

Determine whether the calling process of an IPC you are handling has been
granted a particular permission. This is basically the same as calling
checkPermission(String, int, int) with the pid and uid returned
by getCallingPid() and
getCallingUid(). One important difference
is that if you are not currently processing an IPC, this function
will always fail. This is done to protect against accidentally
leaking permissions; you can use checkCallingOrSelfPermission(String)
to avoid this protection.

checkCallingUriPermission

Determine whether the calling process and user ID has been
granted permission to access a specific URI. This is basically
the same as calling checkUriPermission(Uri, int, int, int) with the pid and uid returned by getCallingPid() and getCallingUid(). One important difference is
that if you are not currently processing an IPC, this function
will always fail.

checkUriPermission

Determine whether a particular process and user ID has been granted
permission to access a specific URI. This only checks for permissions
that have been explicitly granted -- if the given process/uid has
more general access to the URI's content provider then this check will
always fail.

Parameters

uri

Uri: The uri that is being checked.

pid

int: The process ID being checked against. Must be > 0.

uid

int: The user ID being checked against. A uid of 0 is the root
user, which will pass every permission check.

createConfigurationContext

Return a new Context object for the current Context but whose resources
are adjusted to match the given Configuration. Each call to this method
returns a new instance of a Context object; Context objects are not
shared, however common state (ClassLoader, other Resources for the
same configuration) may be so the Context itself can be fairly lightweight.

Parameters

overrideConfiguration

Configuration: A Configuration specifying what
values to modify in the base Configuration of the original Context's
resources. If the base configuration changes (such as due to an
orientation change), the resources of this context will also change except
for those that have been explicitly overridden with a value here.

createDeviceProtectedStorageContext

Return a new Context object for the current Context but whose storage
APIs are backed by device-protected storage.

On devices with direct boot, data stored in this location is encrypted
with a key tied to the physical device, and it can be accessed
immediately after the device has booted successfully, both
before and after the user has authenticated with their
credentials (such as a lock pattern or PIN).

Because device-protected data is available without user authentication,
you should carefully limit the data you store using this Context. For
example, storing sensitive authentication tokens or passwords in the
device-protected area is strongly discouraged.

If the underlying device does not have the ability to store
device-protected and credential-protected data using different keys, then
both storage areas will become available at the same time. They remain as
two distinct storage locations on disk, and only the window of
availability changes.

Each call to this method returns a new instance of a Context object;
Context objects are not shared, however common state (ClassLoader, other
Resources for the same configuration) may be so the Context itself can be
fairly lightweight.

createDisplayContext

Return a new Context object for the current Context but whose resources
are adjusted to match the metrics of the given Display. Each call to this method
returns a new instance of a Context object; Context objects are not
shared, however common state (ClassLoader, other Resources for the
same configuration) may be so the Context itself can be fairly lightweight.
The returned display Context provides a WindowManager
(see getSystemService(String)) that is configured to show windows
on the given display. The WindowManager's getDefaultDisplay()
method can be used to retrieve the Display from the returned Context.

Parameters

display

Display: A Display object specifying the display
for whose metrics the Context's resources should be tailored and upon which
new windows should be shown.

createPackageContext

Return a new Context object for the given application name. This
Context is the same as what the named application gets when it is
launched, containing the same resources and class loader. Each call to
this method returns a new instance of a Context object; Context objects
are not shared, however they share common state (Resources, ClassLoader,
etc) so the Context instance itself is fairly lightweight.

enforceCallingOrSelfPermission

If neither you nor the calling process of an IPC you are
handling has been granted a particular permission, throw a
SecurityException. This is the same as enforceCallingPermission(String, String), except it grants your own
permissions if you are not currently processing an IPC. Use
with care!

enforceUriPermission

If a particular process and user ID has not been granted
permission to access a specific URI, throw SecurityException. This only checks for permissions that have
been explicitly granted -- if the given process/uid has more
general access to the URI's content provider then this check
will always fail.

Parameters

uri

Uri: The uri that is being checked.

pid

int: The process ID being checked against. Must be > 0.

uid

int: The user ID being checked against. A uid of 0 is the root
user, which will pass every permission check.

getApplicationContext

Return the context of the single, global Application object of the
current process. This generally should only be used if you need a
Context whose lifecycle is separate from the current context, that is
tied to the lifetime of the process rather than the current component.

If used from an Activity context, the receiver is being registered
within that activity. This means that you are expected to unregister
before the activity is done being destroyed; in fact if you do not do
so, the framework will clean up your leaked registration as it removes
the activity and log an error. Thus, if you use the Activity context
to register a receiver that is static (global to the process, not
associated with an Activity instance) then that registration will be
removed on you at whatever point the activity you used is destroyed.

If used from the Context returned here, the receiver is being
registered with the global state associated with your application. Thus
it will never be unregistered for you. This is necessary if the receiver
is associated with static data, not a particular component. However
using the ApplicationContext elsewhere can easily lead to serious leaks
if you forget to unregister, unbind, etc.

getAssets

Note: Implementations of this method should return
an AssetManager instance that is consistent with the Resources instance
returned by getResources(). For example, they should share the
same Configuration object.

Apps are strongly encouraged to keep their usage of cache space below the
quota returned by
getCacheQuotaBytes(java.util.UUID). If your app
goes above this quota, your cached files will be some of the first to be
deleted when additional disk space is needed. Conversely, if your app
stays under this quota, your cached files will be some of the last to be
deleted when additional disk space is needed.

Note that your cache quota will change over time depending on how
frequently the user interacts with your app, and depending on how much
system-wide disk space is used.

The returned path may change over time if the calling app is moved to an
adopted storage device, so only relative paths should be persisted.

Apps require no extra permissions to read or write to the returned path,
since this path lives in their private storage.

getContentResolver

getDataDir

Returns the absolute path to the directory on the filesystem where all
private files belonging to this app are stored. Apps should not use this
path directly; they should instead use getFilesDir(),
getCacheDir(), getDir(String, int), or other storage
APIs on this class.

The returned path may change over time if the calling app is moved to an
adopted storage device, so only relative paths should be persisted.

No additional permissions are required for the calling app to read or
write files under the returned path.

getDir

Retrieve, creating if needed, a new directory in which the application
can place its own custom data files. You can use the returned File
object to create and access files in this directory. Note that files
created through a File object will only be accessible by your own
application; you can only set the mode of the entire directory, not
of individual files.

The returned path may change over time if the calling app is moved to an
adopted storage device, so only relative paths should be persisted.

Apps require no extra permissions to read or write to the returned path,
since this path lives in their private storage.

Parameters

name

String: Name of the directory to retrieve. This is a directory
that is created as part of your application data.

getExternalCacheDir

Returns absolute path to application-specific directory on the primary
shared/external storage device where the application can place cache
files it owns. These files are internal to the application, and not
typically visible to the user as media.

This is like getCacheDir() in that these files will be deleted
when the application is uninstalled, however there are some important
differences:

The platform does not always monitor the space available in shared
storage, and thus may not automatically delete these files. Apps should
always manage the maximum space used in this location. Currently the only
time files here will be deleted by the platform is when running on
JELLY_BEAN_MR1 or later and
isExternalStorageEmulated(File) returns true.

Shared storage may not always be available, since removable media can
be ejected by the user. Media state can be checked using
getExternalStorageState(File).

There is no security enforced with these files. For example, any
application holding
WRITE_EXTERNAL_STORAGE can write to
these files.

If a shared storage device is emulated (as determined by
isExternalStorageEmulated(File)), its contents are
backed by a private user data partition, which means there is little
benefit to storing data here instead of the private directory returned by
getCacheDir().

Starting in KITKAT, no permissions
are required to read or write to the returned path; it's always
accessible to the calling app. This only applies to paths generated for
package name of the calling application. To access paths belonging to
other packages,
WRITE_EXTERNAL_STORAGE and/or
READ_EXTERNAL_STORAGE are required.

On devices with multiple users (as described by UserManager),
each user has their own isolated shared storage. Applications only have
access to the shared storage for the user they're running as.

The returned path may change over time if different shared storage media
is inserted, so only relative paths should be persisted.

getExternalCacheDirs

Returns absolute paths to application-specific directories on all
shared/external storage devices where the application can place cache
files it owns. These files are internal to the application, and not
typically visible to the user as media.

This is like getCacheDir() in that these files will be deleted
when the application is uninstalled, however there are some important
differences:

The platform does not always monitor the space available in shared
storage, and thus may not automatically delete these files. Apps should
always manage the maximum space used in this location. Currently the only
time files here will be deleted by the platform is when running on
JELLY_BEAN_MR1 or later and
isExternalStorageEmulated(File) returns true.

Shared storage may not always be available, since removable media can
be ejected by the user. Media state can be checked using
getExternalStorageState(File).

There is no security enforced with these files. For example, any
application holding
WRITE_EXTERNAL_STORAGE can write to
these files.

If a shared storage device is emulated (as determined by
isExternalStorageEmulated(File)), it's contents are
backed by a private user data partition, which means there is little
benefit to storing data here instead of the private directory returned by
getCacheDir().

Shared storage devices returned here are considered a stable part of the
device, including physical media slots under a protective cover. The
returned paths do not include transient devices, such as USB flash drives
connected to handheld devices.

An application may store data on any or all of the returned devices. For
example, an app may choose to store large files on the device with the
most available space, as measured by StatFs.

No additional permissions are required for the calling app to read or
write files under the returned path. Write access outside of these paths
on secondary external storage devices is not available.

The returned paths may change over time if different shared storage media
is inserted, so only relative paths should be persisted.

the absolute paths to application-specific directories. Some
individual paths may be null if that shared storage is
not currently available. The first path returned is the same as
getExternalCacheDir().

getExternalFilesDir

Returns the absolute path to the directory on the primary shared/external
storage device where the application can place persistent files it owns.
These files are internal to the applications, and not typically visible
to the user as media.

This is like getFilesDir() in that these files will be deleted
when the application is uninstalled, however there are some important
differences:

Shared storage may not always be available, since removable media can
be ejected by the user. Media state can be checked using
getExternalStorageState(File).

There is no security enforced with these files. For example, any
application holding
WRITE_EXTERNAL_STORAGE can write to
these files.

If a shared storage device is emulated (as determined by
isExternalStorageEmulated(File)), it's contents are
backed by a private user data partition, which means there is little
benefit to storing data here instead of the private directories returned
by getFilesDir(), etc.

Starting in KITKAT, no permissions
are required to read or write to the returned path; it's always
accessible to the calling app. This only applies to paths generated for
package name of the calling application. To access paths belonging to
other packages,
WRITE_EXTERNAL_STORAGE and/or
READ_EXTERNAL_STORAGE are required.

On devices with multiple users (as described by UserManager),
each user has their own isolated shared storage. Applications only have
access to the shared storage for the user they're running as.

The returned path may change over time if different shared storage media
is inserted, so only relative paths should be persisted.

Here is an example of typical code to manipulate a file in an
application's shared storage:

void createExternalStoragePrivateFile() {
// Create a path where we will place our private file on external
// storage.
File file = new File(getExternalFilesDir(null), "DemoFile.jpg");
try {
// Very simple code to copy a picture from the application's
// resource into the external file. Note that this code does
// no error checking, and assumes the picture is small (does not
// try to copy it in chunks). Note that if external storage is
// not currently mounted this will silently fail.
InputStream is = getResources().openRawResource(R.drawable.balloons);
OutputStream os = new FileOutputStream(file);
byte[] data = new byte[is.available()];
is.read(data);
os.write(data);
is.close();
os.close();
} catch (IOException e) {
// Unable to create file, likely because external storage is
// not currently mounted.
Log.w("ExternalStorage", "Error writing " + file, e);
}
}
void deleteExternalStoragePrivateFile() {
// Get path for the file on external storage. If external
// storage is not currently mounted this will fail.
File file = new File(getExternalFilesDir(null), "DemoFile.jpg");
if (file != null) {
file.delete();
}
}
boolean hasExternalStoragePrivateFile() {
// Get path for the file on external storage. If external
// storage is not currently mounted this will fail.
File file = new File(getExternalFilesDir(null), "DemoFile.jpg");
if (file != null) {
return file.exists();
}
return false;
}

If you supply a non-null type to this function, the returned
file will be a path to a sub-directory of the given type. Though these
files are not automatically scanned by the media scanner, you can
explicitly add them to the media database with
MediaScannerConnection.scanFile. Note that this is not the same as
Environment.getExternalStoragePublicDirectory(), which provides
directories of media shared by all applications. The directories returned
here are owned by the application, and their contents will be removed
when the application is uninstalled. Unlike
Environment.getExternalStoragePublicDirectory(), the directory returned
here will be automatically created for you.

Here is an example of typical code to manipulate a picture in an
application's shared storage and add it to the media database:

void createExternalStoragePrivatePicture() {
// Create a path where we will place our picture in our own private
// pictures directory. Note that we don't really need to place a
// picture in DIRECTORY_PICTURES, since the media scanner will see
// all media in these directories; this may be useful with other
// media types such as DIRECTORY_MUSIC however to help it classify
// your media for display to the user.
File path = getExternalFilesDir(Environment.DIRECTORY_PICTURES);
File file = new File(path, "DemoPicture.jpg");
try {
// Very simple code to copy a picture from the application's
// resource into the external file. Note that this code does
// no error checking, and assumes the picture is small (does not
// try to copy it in chunks). Note that if external storage is
// not currently mounted this will silently fail.
InputStream is = getResources().openRawResource(R.drawable.balloons);
OutputStream os = new FileOutputStream(file);
byte[] data = new byte[is.available()];
is.read(data);
os.write(data);
is.close();
os.close();
// Tell the media scanner about the new file so that it is
// immediately available to the user.
MediaScannerConnection.scanFile(this,
new String[] { file.toString() }, null,
new MediaScannerConnection.OnScanCompletedListener() {
public void onScanCompleted(String path, Uri uri) {
Log.i("ExternalStorage", "Scanned " + path + ":");
Log.i("ExternalStorage", "-> uri=" + uri);
}
});
} catch (IOException e) {
// Unable to create file, likely because external storage is
// not currently mounted.
Log.w("ExternalStorage", "Error writing " + file, e);
}
}
void deleteExternalStoragePrivatePicture() {
// Create a path where we will place our picture in the user's
// public pictures directory and delete the file. If external
// storage is not currently mounted this will fail.
File path = getExternalFilesDir(Environment.DIRECTORY_PICTURES);
if (path != null) {
File file = new File(path, "DemoPicture.jpg");
file.delete();
}
}
boolean hasExternalStoragePrivatePicture() {
// Create a path where we will place our picture in the user's
// public pictures directory and check if the file exists. If
// external storage is not currently mounted this will think the
// picture doesn't exist.
File path = getExternalFilesDir(Environment.DIRECTORY_PICTURES);
if (path != null) {
File file = new File(path, "DemoPicture.jpg");
return file.exists();
}
return false;
}

getExternalFilesDirs

Returns absolute paths to application-specific directories on all
shared/external storage devices where the application can place
persistent files it owns. These files are internal to the application,
and not typically visible to the user as media.

This is like getFilesDir() in that these files will be deleted
when the application is uninstalled, however there are some important
differences:

Shared storage may not always be available, since removable media can
be ejected by the user. Media state can be checked using
getExternalStorageState(File).

There is no security enforced with these files. For example, any
application holding
WRITE_EXTERNAL_STORAGE can write to
these files.

If a shared storage device is emulated (as determined by
isExternalStorageEmulated(File)), it's contents are
backed by a private user data partition, which means there is little
benefit to storing data here instead of the private directories returned
by getFilesDir(), etc.

Shared storage devices returned here are considered a stable part of the
device, including physical media slots under a protective cover. The
returned paths do not include transient devices, such as USB flash drives
connected to handheld devices.

An application may store data on any or all of the returned devices. For
example, an app may choose to store large files on the device with the
most available space, as measured by StatFs.

No additional permissions are required for the calling app to read or
write files under the returned path. Write access outside of these paths
on secondary external storage devices is not available.

The returned path may change over time if different shared storage media
is inserted, so only relative paths should be persisted.

the absolute paths to application-specific directories. Some
individual paths may be null if that shared storage is
not currently available. The first path returned is the same as
getExternalFilesDir(String).

getExternalMediaDirs

Returns absolute paths to application-specific directories on all
shared/external storage devices where the application can place media
files. These files are scanned and made available to other apps through
MediaStore.

This is like getExternalFilesDirs(String) in that these files will be
deleted when the application is uninstalled, however there are some
important differences:

Shared storage may not always be available, since removable media can
be ejected by the user. Media state can be checked using
getExternalStorageState(File).

There is no security enforced with these files. For example, any
application holding
WRITE_EXTERNAL_STORAGE can write to
these files.

Shared storage devices returned here are considered a stable part of the
device, including physical media slots under a protective cover. The
returned paths do not include transient devices, such as USB flash drives
connected to handheld devices.

An application may store data on any or all of the returned devices. For
example, an app may choose to store large files on the device with the
most available space, as measured by StatFs.

No additional permissions are required for the calling app to read or
write files under the returned path. Write access outside of these paths
on secondary external storage devices is not available.

The returned paths may change over time if different shared storage media
is inserted, so only relative paths should be persisted.

getNoBackupFilesDir

Returns the absolute path to the directory on the filesystem similar to
getFilesDir(). The difference is that files placed under this
directory will be excluded from automatic backup to remote storage. See
BackupAgent for a full discussion
of the automatic backup mechanism in Android.

The returned path may change over time if the calling app is moved to an
adopted storage device, so only relative paths should be persisted.

No additional permissions are required for the calling app to read or
write files under the returned path.

getObbDir

Return the primary shared/external storage directory where this
application's OBB files (if there are any) can be found. Note if the
application does not have any OBB files, this directory may not exist.

This is like getFilesDir() in that these files will be deleted
when the application is uninstalled, however there are some important
differences:

Shared storage may not always be available, since removable media can
be ejected by the user. Media state can be checked using
getExternalStorageState(File).

There is no security enforced with these files. For example, any
application holding
WRITE_EXTERNAL_STORAGE can write to
these files.

Starting in KITKAT, no permissions
are required to read or write to the path that this method returns.
However, starting from M,
to read the OBB expansion files, you must declare the
READ_EXTERNAL_STORAGE permission in the app manifest and ask for
permission at runtime as follows:

Starting from N,
READ_EXTERNAL_STORAGE
permission is not required, so don’t ask for this
permission at runtime. To handle both cases, your app must first try to read the OBB file,
and if it fails, you must request
READ_EXTERNAL_STORAGE permission at runtime.

On devices with multiple users (as described by UserManager),
multiple users may share the same OBB storage location. Applications
should ensure that multiple instances running under different users don't
interfere with each other.

getObbDirs

Returns absolute paths to application-specific directories on all
shared/external storage devices where the application's OBB files (if
there are any) can be found. Note if the application does not have any
OBB files, these directories may not exist.

This is like getFilesDir() in that these files will be deleted
when the application is uninstalled, however there are some important
differences:

Shared storage may not always be available, since removable media can
be ejected by the user. Media state can be checked using
getExternalStorageState(File).

There is no security enforced with these files. For example, any
application holding
WRITE_EXTERNAL_STORAGE can write to
these files.

Shared storage devices returned here are considered a stable part of the
device, including physical media slots under a protective cover. The
returned paths do not include transient devices, such as USB flash drives
connected to handheld devices.

An application may store data on any or all of the returned devices. For
example, an app may choose to store large files on the device with the
most available space, as measured by StatFs.

No additional permissions are required for the calling app to read or
write files under the returned path. Write access outside of these paths
on secondary external storage devices is not available.

getResources

Note: Implementations of this method should return
a Resources instance that is consistent with the AssetManager instance
returned by getAssets(). For example, they should share the
same Configuration object.

getSharedPreferences

Retrieve and hold the contents of the preferences file 'name', returning
a SharedPreferences through which you can retrieve and modify its
values. Only one instance of the SharedPreferences object is returned
to any callers for the same name, meaning they will see each other's
edits as soon as they are made.

Parameters

name

String: Desired preferences file. If a preferences file by this name
does not exist, it will be created when you retrieve an
editor (SharedPreferences.edit()) and then commit changes (Editor.commit()).

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

grantUriPermission

Grant permission to access a specific Uri to another package, regardless
of whether that package has general permission to access the Uri's
content provider. This can be used to grant specific, temporary
permissions, typically in response to user interaction (such as the
user opening an attachment that you would like someone else to
display).

moveDatabaseFrom

Move an existing database file from the given source storage context to
this context. This is typically used to migrate data between storage
locations after an upgrade, such as migrating to device protected
storage.

The database must be closed before being moved.

Parameters

sourceContext

Context: The source context which contains the existing
database to move.

name

String: The name of the database file.

Returns

boolean

true if the move was successful or if the database didn't
exist in the source context, otherwise false.

moveSharedPreferencesFrom

Move an existing shared preferences file from the given source storage
context to this context. This is typically used to migrate data between
storage locations after an upgrade, such as moving to device protected
storage.

Parameters

sourceContext

Context: The source context which contains the existing
shared preferences to move.

name

String: The name of the shared preferences file.

Returns

boolean

true if the move was successful or if the shared
preferences didn't exist in the source context, otherwise
false.

registerReceiver

Register a BroadcastReceiver to be run in the main activity thread. The
receiver will be called with any broadcast Intent that
matches filter, in the main application thread.

The system may broadcast Intents that are "sticky" -- these stay
around after the broadcast has finished, to be sent to any later
registrations. If your IntentFilter matches one of these sticky
Intents, that Intent will be returned by this function
and sent to your receiver as if it had just
been broadcast.

There may be multiple sticky Intents that match filter,
in which case each of these will be sent to receiver. In
this case, only one of these can be returned directly by the function;
which of these that is returned is arbitrarily decided by the system.

If you know the Intent your are registering for is sticky, you can
supply null for your receiver. In this case, no receiver is
registered -- the function simply returns the sticky Intent that
matches filter. In the case of multiple matches, the same
rules as described above apply.

As of ICE_CREAM_SANDWICH, receivers
registered with this method will correctly respect the
setPackage(String) specified for an Intent being broadcast.
Prior to that, it would be ignored and delivered to all matching registered
receivers. Be careful if using this for security.

Note: this method cannot be called from a
BroadcastReceiver component; that is, from a BroadcastReceiver
that is declared in an application's manifest. It is okay, however, to call
this method from another BroadcastReceiver that has itself been registered
at run time with registerReceiver(BroadcastReceiver, IntentFilter), since the lifetime of such a
registered BroadcastReceiver is tied to the object that registered it.

registerReceiver

Register to receive intent broadcasts, with the receiver optionally being
exposed to Instant Apps. See
registerReceiver(BroadcastReceiver, IntentFilter) for more
information. By default Instant Apps cannot interact with receivers in other
applications, this allows you to expose a receiver that Instant Apps can
interact with.

As of ICE_CREAM_SANDWICH, receivers
registered with this method will correctly respect the
setPackage(String) specified for an Intent being broadcast.
Prior to that, it would be ignored and delivered to all matching registered
receivers. Be careful if using this for security.

As of ICE_CREAM_SANDWICH, receivers
registered with this method will correctly respect the
setPackage(String) specified for an Intent being broadcast.
Prior to that, it would be ignored and delivered to all matching registered
receivers. Be careful if using this for security.

Parameters

receiver

BroadcastReceiver: The BroadcastReceiver to handle the broadcast.

filter

IntentFilter: Selects the Intent broadcasts to be received.

broadcastPermission

String: String naming a permissions that a
broadcaster must hold in order to send an Intent to you. If null,
no permission is required.

scheduler

Handler: Handler identifying the thread that will receive
the Intent. If null, the main thread of the process will be used.

registerReceiver

Register to receive intent broadcasts, to run in the context of
scheduler. See
registerReceiver(BroadcastReceiver, IntentFilter) for more
information. This allows you to enforce permissions on who can
broadcast intents to your receiver, or have the receiver run in
a different thread than the main application thread.

As of ICE_CREAM_SANDWICH, receivers
registered with this method will correctly respect the
setPackage(String) specified for an Intent being broadcast.
Prior to that, it would be ignored and delivered to all matching registered
receivers. Be careful if using this for security.

Parameters

receiver

BroadcastReceiver: The BroadcastReceiver to handle the broadcast.

filter

IntentFilter: Selects the Intent broadcasts to be received.

broadcastPermission

String: String naming a permissions that a
broadcaster must hold in order to send an Intent to you. If null,
no permission is required.

scheduler

Handler: Handler identifying the thread that will receive
the Intent. If null, the main thread of the process will be used.

removeStickyBroadcast

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.

removeStickyBroadcastAsUser

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.

Version of removeStickyBroadcast(Intent) that allows you to specify the
user the broadcast will be sent to. This is not available to applications
that are not pre-installed on the system image.

revokeUriPermission

Remove all permissions to access a particular content provider Uri
that were previously added with grantUriPermission(String, Uri, int) or any other mechanism.
The given Uri will match all previously granted Uris that are the same or a
sub-path of the given Uri. That is, revoking "content://foo/target" will
revoke both "content://foo/target" and "content://foo/target/sub", but not
"content://foo". It will not remove any prefix grants that exist at a
higher level.

Prior to LOLLIPOP, if you did not have
regular permission access to a Uri, but had received access to it through
a specific Uri permission grant, you could not revoke that grant with this
function and a SecurityException would be thrown. As of
LOLLIPOP, this function will not throw a security
exception, but will remove whatever permission grants to the Uri had been given to the app
(or none).

Unlike revokeUriPermission(String, Uri, int), this method impacts all permission
grants matching the given Uri, for any package they had been granted to, through any
mechanism this had happened (such as indirectly through the clipboard, activity launch,
service start, etc). That means this can be potentially dangerous to use, as it can
revoke grants that another app could be strongly expecting to stick around.

Parameters

uri

Uri: The Uri you would like to revoke access to.

modeFlags

int: The access modes to revoke.

revokeUriPermission

Remove permissions to access a particular content provider Uri
that were previously added with grantUriPermission(String, Uri, int) for a specific target
package. The given Uri will match all previously granted Uris that are the same or a
sub-path of the given Uri. That is, revoking "content://foo/target" will
revoke both "content://foo/target" and "content://foo/target/sub", but not
"content://foo". It will not remove any prefix grants that exist at a
higher level.

Unlike revokeUriPermission(Uri, int), this method will only
revoke permissions that had been explicitly granted through grantUriPermission(String, Uri, int)
and only for the package specified. Any matching grants that have happened through
other mechanisms (clipboard, activity launching, service starting, etc) will not be
removed.

Parameters

targetPackage

String: The package you had previously granted access to.

uri

Uri: The Uri you would like to revoke access to.

modeFlags

int: The access modes to revoke.

sendBroadcast

Broadcast the given intent to all interested BroadcastReceivers, allowing
an optional required permission to be enforced. This
call is asynchronous; it returns immediately, and you will continue
executing while the receivers are run. No results are propagated from
receivers and receivers can not abort the broadcast. If you want
to allow receivers to propagate results or abort the broadcast, you must
send an ordered broadcast using
sendOrderedBroadcast(Intent, String).

sendBroadcast

Broadcast the given intent to all interested BroadcastReceivers. This
call is asynchronous; it returns immediately, and you will continue
executing while the receivers are run. No results are propagated from
receivers and receivers can not abort the broadcast. If you want
to allow receivers to propagate results or abort the broadcast, you must
send an ordered broadcast using
sendOrderedBroadcast(Intent, String).

sendOrderedBroadcast

Version of sendBroadcast(Intent) that allows you to
receive data back from the broadcast. This is accomplished by
supplying your own BroadcastReceiver when calling, which will be
treated as a final receiver at the end of the broadcast -- its
onReceive(Context, Intent) method will be called with
the result values collected from the other receivers. The broadcast will
be serialized in the same way as calling
sendOrderedBroadcast(Intent, String).

Like sendBroadcast(Intent), this method is
asynchronous; it will return before
resultReceiver.onReceive() is called.

sendOrderedBroadcast

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
call is asynchronous; it returns immediately, and you will continue
executing while the receivers are run.

sendStickyBroadcast

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.

sendStickyBroadcastAsUser

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.

Version of sendStickyBroadcast(Intent) that allows you to specify the
user the broadcast will be sent to. This is not available to applications
that are not pre-installed on the system image.

Parameters

intent

Intent: The Intent to broadcast; all receivers matching this
Intent will receive the broadcast, and the Intent will be held to
be re-broadcast to future receivers.

user

UserHandle: UserHandle to send the intent to.

sendStickyOrderedBroadcast

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.

Version of sendStickyBroadcast(Intent) that allows you to
receive data back from the broadcast. This is accomplished by
supplying your own BroadcastReceiver when calling, which will be
treated as a final receiver at the end of the broadcast -- its
onReceive(Context, Intent) method will be called with
the result values collected from the other receivers. The broadcast will
be serialized in the same way as calling
sendOrderedBroadcast(Intent, String).

Like sendBroadcast(Intent), this method is
asynchronous; it will return before
resultReceiver.onReceive() is called. Note that the sticky data
stored is only the data you initially supply to the broadcast, not
the result of any changes made by the 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.

startActivities

Launch multiple new activities. This is generally the same as calling
startActivity(Intent) for the first Intent in the array,
that activity during its creation calling startActivity(Intent)
for the second entry, etc. Note that unlike that approach, generally
none of the activities except the last in the array will be created
at this point, but rather will be created when the user first visits
them (due to pressing back from the activity on top).

This method throws ActivityNotFoundException
if there was no Activity found for any given Intent. In this
case the state of the activity stack is undefined (some Intents in the
list may be on it, some not), so you probably want to avoid such situations.

Parameters

intents

Intent: An array of Intents to be started.

options

Bundle: Additional options for how the Activity should be started.
See startActivity(Intent, Bundle)
Context.startActivity(Intent, Bundle)} for more details.

startActivity

Launch a new activity. You will not receive any information about when
the activity exits.

Note that if this method is being called from outside of an
Activity Context, then the Intent must include
the FLAG_ACTIVITY_NEW_TASK launch flag. This is because,
without being started from an existing Activity, there is no existing
task in which to place the new activity and thus it needs to be placed
in its own separate task.

Bundle: Additional options for how the Activity should be started.
May be null if there are no options. See ActivityOptions
for how to build the Bundle supplied here; there are no supported definitions
for building it manually.

startForegroundService

Similar to startService(Intent), but with an implicit promise that the
Service will call startForeground(int, Notification) once it begins running. The service is given
an amount of time comparable to the ANR interval to do this, otherwise the system
will automatically stop the service and declare the app ANR.

Unlike the ordinary startService(Intent), this method can be used
at any time, regardless of whether the app hosting the service is in a foreground
state.

Parameters

service

Intent: Identifies the service to be started. The Intent must be
fully explicit (supplying a component name). Additional values
may be included in the Intent extras to supply arguments along with
this specific start call.

startInstrumentation

Start executing an Instrumentation class. The given
Instrumentation component will be run by killing its target application
(if currently running), starting the target process, instantiating the
instrumentation component, and then letting it drive the application.

This function is not synchronous -- it returns as soon as the
instrumentation has started and while it is running.

Instrumentation is normally only allowed to run against a package
that is either unsigned or signed with a signature that the
the instrumentation package is also signed with (ensuring the target
trusts the instrumentation).

Parameters

className

ComponentName: Name of the Instrumentation component to be run.

profileFile

String: Optional path to write profiling data as the
instrumentation runs, or null for no profiling.

arguments

Bundle: Additional optional arguments to pass to the
instrumentation, or null.

Returns

boolean

true if the instrumentation was successfully started,
else false if it could not be found.

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

startService

Request that a given application service be started. The Intent
should either contain the complete class name of a specific service
implementation to start, or a specific package name to target. If the
Intent is less specified, it logs a warning about this. In this case any of the
multiple matching services may be used. If this service
is not already running, it will be instantiated and started (creating a
process for it if needed); if it is running then it remains running.

Every call to this method will result in a corresponding call to
the target service's onStartCommand(Intent, int, int) method,
with the intent given here. This provides a convenient way
to submit jobs to a service without having to bind and call on to its
interface.

Using startService() overrides the default service lifetime that is
managed by bindService(Intent, ServiceConnection, int): it requires the service to remain
running until stopService(Intent) is called, regardless of whether
any clients are connected to it. Note that calls to startService()
do not nest: no matter how many times you call startService(),
a single call to stopService(Intent) will stop it.

The system attempts to keep running services around as much as
possible. The only time they should be stopped is if the current
foreground application is using so many resources that the service needs
to be killed. If any errors happen in the service's process, it will
automatically be restarted.

This function will throw SecurityException if you do not
have permission to start the given service.

Note: Each call to startService()
results in significant work done by the system to manage service
lifecycle surrounding the processing of the intent, which can take
multiple milliseconds of CPU time. Due to this cost, startService()
should not be used for frequent intent delivery to a service, and only
for scheduling significant work. Use bound services
for high frequency calls.

Parameters

service

Intent: Identifies the service to be started. The Intent must be
fully explicit (supplying a component name). Additional values
may be included in the Intent extras to supply arguments along with
this specific start call.

stopService

Request that a given application service be stopped. If the service is
not running, nothing happens. Otherwise it is stopped. Note that calls
to startService() are not counted -- this stops the service no matter
how many times it was started.

Note that if a stopped service still has ServiceConnection
objects bound to it with the BIND_AUTO_CREATE set, it will
not be destroyed until all of these bindings are removed. See
the Service documentation for more details on a
service's lifecycle.

This function will throw SecurityException if you do not
have permission to stop the given service.

Parameters

name

Intent: Description of the service to be stopped. The Intent must be either
fully explicit (supplying a component name) or specify a specific package
name it is targetted to.

Returns

boolean

If there is a service matching the given Intent that is already
running, then it is stopped and true is returned; else false is returned.