ContextWrapper

ContextWrapper

ContextWrapper (Context base)

bindService

boolean bindService (Intent service, 
                ServiceConnection conn, 
                int flags)

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

checkCallingOrSelfPermission

int checkCallingOrSelfPermission (String permission)

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

int checkCallingOrSelfUriPermission (Uri uri, 
                int modeFlags)

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

int checkCallingPermission (String permission)

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

int checkCallingUriPermission (Uri uri, 
                int modeFlags)

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.

checkPermission

int checkPermission (String permission, 
                int pid, 
                int uid)

Determine whether the given permission is allowed for a particular process and user ID running in the system.

checkSelfPermission

int checkSelfPermission (String permission)

Determine whether you have been granted a particular permission.

checkUriPermission

int checkUriPermission (Uri uri, 
                String readPermission, 
                String writePermission, 
                int pid, 
                int uid, 
                int modeFlags)

Check both a Uri and normal permission. This allows you to perform both checkPermission(String, int, int) and checkUriPermission(Uri, int, int, int) in one call.

checkUriPermission

int checkUriPermission (Uri uri, 
                int pid, 
                int uid, 
                int modeFlags)

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.

clearWallpaper

void clearWallpaper ()

This method was deprecated in API level 23.
Use WallpaperManager.clear() instead.

This method requires the caller to hold the permission SET_WALLPAPER.

createConfigurationContext

Context createConfigurationContext (Configuration overrideConfiguration)

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.

createDeviceProtectedStorageContext

Context 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

Context createDisplayContext (Display display)

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.

createPackageContext

Context createPackageContext (String packageName, 
                int flags)

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.

Throws PackageManager.NameNotFoundException if there is no application with the given package name.

Throws SecurityException if the Context requested can not be loaded into the caller's process for security reasons (see CONTEXT_INCLUDE_CODE for more information}.

databaseList

String[] databaseList ()

Returns an array of strings naming the private databases associated with this Context's application package.

deleteDatabase

boolean deleteDatabase (String name)

Delete an existing private SQLiteDatabase associated with this Context's application package.

deleteFile

boolean deleteFile (String name)

Delete the given private file associated with this Context's application package.

deleteSharedPreferences

boolean deleteSharedPreferences (String name)

Delete an existing shared preferences file.

enforceCallingOrSelfPermission

void enforceCallingOrSelfPermission (String permission, 
                String message)

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!

enforceCallingOrSelfUriPermission

void enforceCallingOrSelfUriPermission (Uri uri, 
                int modeFlags, 
                String message)

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

enforceCallingPermission

void enforceCallingPermission (String permission, 
                String message)

If the calling process of an IPC you are handling has not been granted a particular permission, throw a SecurityException. This is basically the same as calling enforcePermission(String, int, int, String) 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 throw the SecurityException. This is done to protect against accidentally leaking permissions; you can use enforceCallingOrSelfPermission(String, String) to avoid this protection.

enforceCallingUriPermission

void enforceCallingUriPermission (Uri uri, 
                int modeFlags, 
                String message)

If the calling process and user ID has not been granted permission to access a specific URI, throw SecurityException. This is basically the same as calling enforceUriPermission(Uri, int, int, int, String) 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 throw a SecurityException.

enforcePermission

void enforcePermission (String permission, 
                int pid, 
                int uid, 
                String message)

If the given permission is not allowed for a particular process and user ID running in the system, throw a SecurityException.

enforceUriPermission

void enforceUriPermission (Uri uri, 
                String readPermission, 
                String writePermission, 
                int pid, 
                int uid, 
                int modeFlags, 
                String message)

Enforce both a Uri and normal permission. This allows you to perform both enforcePermission(String, int, int, String) and enforceUriPermission(Uri, int, int, int, String) in one call.

enforceUriPermission

void enforceUriPermission (Uri uri, 
                int pid, 
                int uid, 
                int modeFlags, 
                String message)

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.

fileList

String[] fileList ()

Returns an array of strings naming the private files associated with this Context's application package.

getApplicationContext

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

Consider for example how this interacts with registerReceiver(BroadcastReceiver, IntentFilter):

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

getApplicationInfo

ApplicationInfo getApplicationInfo ()

Return the full application info for this context's package.

getAssets

AssetManager getAssets ()

Returns an AssetManager instance for the application's package.

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.

getBaseContext

Context getBaseContext ()

getCacheDir

File getCacheDir ()

Returns the absolute path to the application specific cache directory on the filesystem. These files will be ones that get deleted first when the device runs low on storage. There is no guarantee when these files will be deleted.

Note: you should not rely on the system deleting these files for you; you should always have a reasonable maximum, such as 1 MB, for the amount of space you consume with cache files, and prune those files when exceeding that space.

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.

getClassLoader

ClassLoader getClassLoader ()

Return a class loader you can use to retrieve classes in this package.

getCodeCacheDir

File getCodeCacheDir ()

Returns the absolute path to the application specific cache directory on the filesystem designed for storing cached code. The system will delete any files stored in this location both when your specific application is upgraded, and when the entire platform is upgraded.

This location is optimal for storing compiled or optimized code generated by your application at runtime.

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

ContentResolver getContentResolver ()

Return a ContentResolver instance for your application's package.

getDataDir

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

getDatabasePath

File getDatabasePath (String name)

Returns the absolute path on the filesystem where a database created with openOrCreateDatabase(String, int, SQLiteDatabase.CursorFactory) is stored.

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.

getDir

File getDir (String name, 
                int mode)

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.

getExternalCacheDir

File 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)), 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().

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

File[] 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.

getExternalFilesDir

File getExternalFilesDir (String type)

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

File[] getExternalFilesDirs (String type)

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.

getExternalMediaDirs

File[] 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.

getFileStreamPath

File getFileStreamPath (String name)

Returns the absolute path on the filesystem where a file created with openFileOutput(String, int) is stored.

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.

getFilesDir

File getFilesDir ()

Returns the absolute path to the directory on the filesystem where files created with openFileOutput(String, int) are stored.

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.

getMainLooper

Looper getMainLooper ()

Return the Looper for the main thread of the current process. This is the thread used to dispatch calls to application components (activities, services, etc).

By definition, this method returns the same result as would be obtained by calling Looper.getMainLooper().

getNoBackupFilesDir

File 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

File 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 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), 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

File[] 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.

getPackageCodePath

String getPackageCodePath ()

Return the full path to this context's primary Android package. The Android package is a ZIP file which contains application's primary code and assets.

Note: this is not generally useful for applications, since they should not be directly accessing the file system.

getPackageManager

PackageManager getPackageManager ()

Return PackageManager instance to find global package information.

getPackageName

String getPackageName ()

Return the name of this application's package.

getPackageResourcePath

String getPackageResourcePath ()

Return the full path to this context's primary Android package. The Android package is a ZIP file which contains the application's primary resources.

Note: this is not generally useful for applications, since they should not be directly accessing the file system.

getResources

Resources getResources ()

Returns a Resources instance for the application's package.

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

SharedPreferences getSharedPreferences (String name, 
                int mode)

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.

getSystemService

Object getSystemService (String name)

Return the handle to a system-level service by name. The class of the returned object varies by the requested name. Currently available names are:

WINDOW_SERVICE ("window")

The top-level window manager in which you can place custom windows. The returned object is a WindowManager.

LAYOUT_INFLATER_SERVICE ("layout_inflater")

A LayoutInflater for inflating layout resources in this context.

ACTIVITY_SERVICE ("activity")

A ActivityManager for interacting with the global activity state of the system.

POWER_SERVICE ("power")

A PowerManager for controlling power management.

ALARM_SERVICE ("alarm")

A AlarmManager for receiving intents at the time of your choosing.

NOTIFICATION_SERVICE ("notification")

A NotificationManager for informing the user of background events.

KEYGUARD_SERVICE ("keyguard")

A KeyguardManager for controlling keyguard.

LOCATION_SERVICE ("location")

A LocationManager for controlling location (e.g., GPS) updates.

SEARCH_SERVICE ("search")

A SearchManager for handling search.

VIBRATOR_SERVICE ("vibrator")

A Vibrator for interacting with the vibrator hardware.

CONNECTIVITY_SERVICE ("connection")

A ConnectivityManager for handling management of network connections.

WIFI_SERVICE ("wifi")

A WifiManager for management of Wi-Fi connectivity.

WIFI_P2P_SERVICE ("wifip2p")

A WifiP2pManager for management of Wi-Fi Direct connectivity.

INPUT_METHOD_SERVICE ("input_method")

An InputMethodManager for management of input methods.

UI_MODE_SERVICE ("uimode")

An UiModeManager for controlling UI modes.

DOWNLOAD_SERVICE ("download")

A DownloadManager for requesting HTTP downloads

BATTERY_SERVICE ("batterymanager")

A BatteryManager for managing battery state

JOB_SCHEDULER_SERVICE ("taskmanager")

A JobScheduler for managing scheduled tasks

NETWORK_STATS_SERVICE ("netstats")

A NetworkStatsManager for querying network usage statistics.

HARDWARE_PROPERTIES_SERVICE ("hardware_properties")

A HardwarePropertiesManager for accessing hardware properties.

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

getSystemServiceName

String getSystemServiceName (Class<?> serviceClass)

Gets the name of the system-level service that is represented by the specified class.

getTheme

Resources.Theme getTheme ()

Return the Theme object associated with this Context.

getWallpaper

Drawable getWallpaper ()

This method was deprecated in API level 23.
Use WallpaperManager.get() instead.

getWallpaperDesiredMinimumHeight

int getWallpaperDesiredMinimumHeight ()

This method was deprecated in API level 23.
Use WallpaperManager.getDesiredMinimumHeight() instead.

getWallpaperDesiredMinimumWidth

int getWallpaperDesiredMinimumWidth ()

This method was deprecated in API level 23.
Use WallpaperManager.getDesiredMinimumWidth() instead.

grantUriPermission

void grantUriPermission (String toPackage, 
                Uri uri, 
                int modeFlags)

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

Normally you should use Intent.FLAG_GRANT_READ_URI_PERMISSION or Intent.FLAG_GRANT_WRITE_URI_PERMISSION with the Intent being used to start an activity instead of this function directly. If you use this function directly, you should be sure to call revokeUriPermission(Uri, int) when the target should no longer be allowed to access it.

To succeed, the content provider owning the Uri must have set the grantUriPermissions attribute in its manifest or included the <grant-uri-permissions> tag.

isDeviceProtectedStorage

boolean isDeviceProtectedStorage ()

Indicates if the storage APIs of this Context are backed by device-protected storage.

isRestricted

boolean isRestricted ()

Indicates whether this Context is restricted.

moveDatabaseFrom

boolean moveDatabaseFrom (Context sourceContext, 
                String name)

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.

moveSharedPreferencesFrom

boolean moveSharedPreferencesFrom (Context sourceContext, 
                String name)

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.

openFileInput

FileInputStream openFileInput (String name)

Open a private file associated with this Context's application package for reading.

openFileOutput

FileOutputStream openFileOutput (String name, 
                int mode)

Open a private file associated with this Context's application package for writing. Creates the file if it doesn't already exist.

No additional permissions are required for the calling app to read or write the returned file.

openOrCreateDatabase

SQLiteDatabase openOrCreateDatabase (String name, 
                int mode, 
                SQLiteDatabase.CursorFactory factory, 
                DatabaseErrorHandler errorHandler)

Open a new private SQLiteDatabase associated with this Context's application package. Creates the database file if it doesn't exist.

Accepts input param: a concrete instance of DatabaseErrorHandler to be used to handle corruption when sqlite reports database corruption.

openOrCreateDatabase

SQLiteDatabase openOrCreateDatabase (String name, 
                int mode, 
                SQLiteDatabase.CursorFactory factory)

Open a new private SQLiteDatabase associated with this Context's application package. Create the database file if it doesn't exist.

peekWallpaper

Drawable peekWallpaper ()

This method was deprecated in API level 23.
Use WallpaperManager.peek() instead.

registerReceiver

Intent registerReceiver (BroadcastReceiver receiver, 
                IntentFilter filter)

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

See BroadcastReceiver for more information on Intent broadcasts.

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

Intent registerReceiver (BroadcastReceiver receiver, 
                IntentFilter filter, 
                String broadcastPermission, 
                Handler scheduler)

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.

See BroadcastReceiver for more information on Intent broadcasts.

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.

removeStickyBroadcast

void removeStickyBroadcast (Intent intent)

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.

Remove the data previously sent with sendStickyBroadcast(Intent), so that it is as if the sticky broadcast had never happened.

You must hold the BROADCAST_STICKY permission in order to use this API. If you do not hold that permission, SecurityException will be thrown.

removeStickyBroadcastAsUser

void removeStickyBroadcastAsUser (Intent intent, 
                UserHandle user)

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. Using it requires holding the INTERACT_ACROSS_USERS permission.

You must hold the BROADCAST_STICKY permission in order to use this API. If you do not hold that permission, SecurityException will be thrown.

revokeUriPermission

void revokeUriPermission (Uri uri, 
                int modeFlags)

Remove all permissions to access a particular content provider Uri that were previously added with grantUriPermission(String, Uri, int). 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).

sendBroadcast

void sendBroadcast (Intent intent, 
                String receiverPermission)

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

See BroadcastReceiver for more information on Intent broadcasts.

sendBroadcast

void sendBroadcast (Intent intent)

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

See BroadcastReceiver for more information on Intent broadcasts.

sendBroadcastAsUser

void sendBroadcastAsUser (Intent intent, 
                UserHandle user)

Version of sendBroadcast(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. Using it requires holding the INTERACT_ACROSS_USERS permission.

sendBroadcastAsUser

void sendBroadcastAsUser (Intent intent, 
                UserHandle user, 
                String receiverPermission)

Version of sendBroadcast(Intent, String) 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. Using it requires holding the INTERACT_ACROSS_USERS permission.

sendOrderedBroadcast

void sendOrderedBroadcast (Intent intent, 
                String receiverPermission, 
                BroadcastReceiver resultReceiver, 
                Handler scheduler, 
                int initialCode, 
                String initialData, 
                Bundle initialExtras)

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.

See BroadcastReceiver for more information on Intent broadcasts.

sendOrderedBroadcast

void sendOrderedBroadcast (Intent intent, 
                String receiverPermission)

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.

See BroadcastReceiver for more information on Intent broadcasts.

sendOrderedBroadcastAsUser

void sendOrderedBroadcastAsUser (Intent intent, 
                UserHandle user, 
                String receiverPermission, 
                BroadcastReceiver resultReceiver, 
                Handler scheduler, 
                int initialCode, 
                String initialData, 
                Bundle initialExtras)

Version of sendOrderedBroadcast(Intent, String, BroadcastReceiver, Handler, int, String, Bundle) 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. Using it requires holding the INTERACT_ACROSS_USERS permission.

See BroadcastReceiver for more information on Intent broadcasts.

sendStickyBroadcast

void sendStickyBroadcast (Intent intent)

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.

Perform a sendBroadcast(Intent) that is "sticky," meaning the Intent you are sending stays around after the broadcast is complete, so that others can quickly retrieve that data through the return value of registerReceiver(BroadcastReceiver, IntentFilter). In all other ways, this behaves the same as sendBroadcast(Intent).

You must hold the BROADCAST_STICKY permission in order to use this API. If you do not hold that permission, SecurityException will be thrown.

sendStickyBroadcastAsUser

void sendStickyBroadcastAsUser (Intent intent, 
                UserHandle user)

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. Using it requires holding the INTERACT_ACROSS_USERS permission.

sendStickyOrderedBroadcast

void sendStickyOrderedBroadcast (Intent intent, 
                BroadcastReceiver resultReceiver, 
                Handler scheduler, 
                int initialCode, 
                String initialData, 
                Bundle initialExtras)

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.

See BroadcastReceiver for more information on Intent broadcasts.

sendStickyOrderedBroadcastAsUser

void sendStickyOrderedBroadcastAsUser (Intent intent, 
                UserHandle user, 
                BroadcastReceiver resultReceiver, 
                Handler scheduler, 
                int initialCode, 
                String initialData, 
                Bundle initialExtras)

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 sendStickyOrderedBroadcast(Intent, BroadcastReceiver, Handler, int, String, Bundle) 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. Using it requires holding the INTERACT_ACROSS_USERS permission.

See BroadcastReceiver for more information on Intent broadcasts.

setTheme

void setTheme (int resid)

Set the base theme for this context. Note that this should be called before any views are instantiated in the Context (for example before calling setContentView(View) or inflate(int, ViewGroup)).

setWallpaper

void setWallpaper (Bitmap bitmap)

This method was deprecated in API level 23.
Use WallpaperManager.set() instead.

This method requires the caller to hold the permission SET_WALLPAPER.

setWallpaper

void setWallpaper (InputStream data)

This method was deprecated in API level 23.
Use WallpaperManager.set() instead.

This method requires the caller to hold the permission SET_WALLPAPER.

startActivities

void startActivities (Intent[] intents, 
                Bundle options)

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.

startActivities

void startActivities (Intent[] intents)

Same as startActivities(Intent[], Bundle) with no options specified.

startActivity

void startActivity (Intent intent)

Same as startActivity(Intent, Bundle) with no options specified.

startActivity

void startActivity (Intent intent, 
                Bundle options)

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.

This method throws ActivityNotFoundException if there was no Activity found to run the given Intent.

startInstrumentation

boolean startInstrumentation (ComponentName className, 
                String profileFile, 
                Bundle arguments)

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

startIntentSender

void startIntentSender (IntentSender intent, 
                Intent fillInIntent, 
                int flagsMask, 
                int flagsValues, 
                int extraFlags)

Same as startIntentSender(IntentSender, Intent, int, int, int, Bundle) with no options specified.

startIntentSender

void startIntentSender (IntentSender intent, 
                Intent fillInIntent, 
                int flagsMask, 
                int flagsValues, 
                int extraFlags, 
                Bundle options)

Like startActivity(Intent, Bundle), but taking a IntentSender to start. If the IntentSender is for an activity, that activity will be started as if you had called the regular startActivity(Intent) here; otherwise, its associated action will be executed (such as sending a broadcast) as if you had called IntentSender.sendIntent on it.

startService

ComponentName startService (Intent service)

Request that a given application service be started. The Intent should contain 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 log a warning about this and which of the multiple matching services it finds and uses will be undefined. 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() are not nesting: 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.

stopService

boolean stopService (Intent name)

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.

unbindService

void unbindService (ServiceConnection conn)

Disconnect from an application service. You will no longer receive calls as the service is restarted, and the service is now allowed to stop at any time.

unregisterReceiver

void unregisterReceiver (BroadcastReceiver receiver)

Unregister a previously registered BroadcastReceiver. All filters that have been registered for this BroadcastReceiver will be removed.

attachBaseContext

void attachBaseContext (Context base)

Set the base context for this ContextWrapper. All calls will then be delegated to the base context. Throws IllegalStateException if a base context has already been set.