ContextWrapper

ContextWrapper

public ContextWrapper (Context base)

bindIsolatedService

public boolean bindIsolatedService (Intent service, 
                int flags, 
                String instanceName, 
                Executor executor, 
                ServiceConnection conn)

Variation of bindService(Intent, BindServiceFlags, Executor, ServiceConnection) that, in the specific case of isolated services, allows the caller to generate multiple instances of a service from a single component declaration. In other words, you can use this to bind to a service that has specified R.attr.isolatedProcess and, in addition to the existing behavior of running in an isolated process, you can also through the arguments here have the system bring up multiple concurrent processes hosting their own instances of that service. The instanceName you provide here identifies the different instances, and you can use updateServiceGroup(android.content.ServiceConnection, int, int) to tell the system how it should manage each of these instances.

bindService

public boolean bindService (Intent service, 
                int flags, 
                Executor executor, 
                ServiceConnection conn)

Same as bindService(Intent, ServiceConnection, int) with executor to control ServiceConnection callbacks.

This method only accepts a 32 bits flag, to pass in a 64 bits flag, call bindService(android.content.Intent, android.content.Context.BindServiceFlags, java.util.concurrent.Executor, android.content.ServiceConnection) instead.

bindService

public boolean bindService (Intent service, 
                ServiceConnection conn, 
                Context.BindServiceFlags flags)

See bindService(android.content.Intent, android.content.ServiceConnection, int) Call BindServiceFlags.of(long) to obtain a BindServiceFlags object.

bindService

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

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

If the service does not support binding, it may return null from its onBind() method. If it does, then the ServiceConnection's onNullBinding() method will be invoked instead of onServiceConnected().

Note: This method cannot 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 Service.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).

This method only accepts a int type flag, to pass in a long type flag, call bindService(android.content.Intent, android.content.ServiceConnection, android.content.Context.BindServiceFlags) instead.

bindService

public boolean bindService (Intent service, 
                Context.BindServiceFlags flags, 
                Executor executor, 
                ServiceConnection conn)

See bindService(android.content.Intent, int, java.util.concurrent.Executor, android.content.ServiceConnection) Call BindServiceFlags.of(long) to obtain a BindServiceFlags object.

checkCallingOrSelfPermission

public 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

public 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!

checkCallingOrSelfUriPermissions

public int[] checkCallingOrSelfUriPermissions (List<Uri> uris, 
                int modeFlags)

Determine whether the calling process of an IPC or you has been granted permission to access a list of URIs. 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

public 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(java.lang.String, int, int) with the pid and uid returned by Binder.getCallingPid() and Binder.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

public int checkCallingUriPermission (Uri uri, 
                int modeFlags)

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

checkCallingUriPermissions

public int[] checkCallingUriPermissions (List<Uri> uris, 
                int modeFlags)

Determine whether the calling process and uid has been granted permission to access a list of URIs. This is basically the same as calling checkUriPermissions(java.util.List, int, int, int) with the pid and uid returned by Binder.getCallingPid() and Binder.getCallingUid(). One important difference is that if you are not currently processing an IPC, this function will always fail.

checkContentUriPermissionFull

public int checkContentUriPermissionFull (Uri uri, 
                int pid, 
                int uid, 
                int modeFlags)

Determine whether a particular process and uid has been granted permission to access a specific content URI.

Unlike checkUriPermission(android.net.Uri, int, int, int), this method checks for general access to the URI's content provider, as well as explicitly granted permissions.

Note, this check will throw an IllegalArgumentException for non-content URIs.

checkPermission

public 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

public int checkSelfPermission (String permission)

Determine whether you have been granted a particular permission.

checkUriPermission

public 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

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

Determine whether a particular process and uid 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.

checkUriPermissions

public int[] checkUriPermissions (List<Uri> uris, 
                int pid, 
                int uid, 
                int modeFlags)

Determine whether a particular process and uid has been granted permission to access a list of URIs. 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. Note: On SDK Version Build.VERSION_CODES.S, calling this method from a secondary-user's context will incorrectly return PackageManager.PERMISSION_DENIED for all {code uris}.

clearWallpaper

public void clearWallpaper ()

This method is deprecated.
Use WallpaperManager.clear() instead.

This method requires the caller to hold the permission Manifest.permission.SET_WALLPAPER.

createAttributionContext

public Context createAttributionContext (String attributionTag)

Return a new Context object for the current Context but attribute to a different tag. In complex apps attribution tagging can be used to distinguish between separate logical parts.

createConfigurationContext

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

createContext

public Context createContext (ContextParams contextParams)

Creates a context with specific properties and behaviors.

createDeviceContext

public Context createDeviceContext (int deviceId)

Returns a new Context object from the current context but with device association given by the deviceId. Each call to this method returns a new instance of a context object. Context objects are not shared; however, common state (such as the ClassLoader and other resources for the same configuration) can be shared, so the Context itself is lightweight.

Applications that run on virtual devices may use this method to access the default device capabilities and functionality (by passing Context.DEVICE_ID_DEFAULT. Similarly, applications running on the default device may access the functionality of virtual devices.

Note that the newly created instance will be associated with the same display as the parent Context, regardless of the device ID passed here.

createDeviceProtectedStorageContext

public 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

public Context createDisplayContext (Display display)

Returns a new Context object from the current context but with resources adjusted to match the metrics of display. Each call to this method returns a new instance of a context object. Context objects are not shared; however, common state (such as the ClassLoader and other resources for the same configuration) can be shared, so the Context itself is lightweight.

Note: This Context is not expected to be updated with new configuration if the underlying display configuration changes and the cached Resources it returns could be stale. It is suggested to use DisplayManager.DisplayListener to listen for changes and re-create an instance if necessary.

This Context is not a UI context, do not use it to access UI components or obtain a WindowManager instance.

To obtain an instance of WindowManager configured to show windows on the given display, call createWindowContext(int, android.os.Bundle) on the returned display context, then call getSystemService(java.lang.String) or getSystemService(java.lang.Class) on the returned window context.

createPackageContext

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

createWindowContext

public Context createWindowContext (int type, 
                Bundle options)

Creates a Context for a non-activity window.

A window context is a context that can be used to add non-activity windows, such as WindowManager.LayoutParams.TYPE_APPLICATION_OVERLAY. A window context must be created from a context that has an associated Display, such as Activity or a context created with createDisplayContext(android.view.Display).

The window context is created with the appropriate Configuration for the area of the display that the windows created with it can occupy; it must be used when inflating views, such that they can be inflated with proper Resources. Below is a sample code to add an application overlay window on the primary display:

 ...
 final DisplayManager dm = anyContext.getSystemService(DisplayManager.class);
 final Display primaryDisplay = dm.getDisplay(DEFAULT_DISPLAY);
 final Context windowContext = anyContext.createDisplayContext(primaryDisplay)
         .createWindowContext(TYPE_APPLICATION_OVERLAY, null);
 final View overlayView = Inflater.from(windowContext).inflate(someLayoutXml, null);

 // WindowManager.LayoutParams initialization
 ...
 // The types used in addView and createWindowContext must match.
 mParams.type = TYPE_APPLICATION_OVERLAY;
 ...

 windowContext.getSystemService(WindowManager.class).addView(overlayView, mParams);
 

This context's configuration and resources are adjusted to an area of the display where the windows with provided type will be added. Note that all windows associated with the same context will have an affinity and can only be moved together between different displays or areas on a display. If there is a need to add different window types, or non-associated windows, separate Contexts should be used.

Creating a window context is an expensive operation. Misuse of this API may lead to a huge performance drop. The best practice is to use the same window context when possible. An approach is to create one window context with specific window type and display and use it everywhere it's needed.

After Build.VERSION_CODES.S, window context provides the capability to receive configuration changes for existing token by overriding the token of the WindowManager.LayoutParams passed in WindowManager.addView(View, LayoutParams). This is useful when an application needs to attach its window to an existing activity for window token sharing use-case.

Note that the window context in Build.VERSION_CODES.R didn't have this capability. This is a no-op for the window context in Build.VERSION_CODES.R.

 final DisplayManager dm = anyContext.getSystemService(DisplayManager.class);
 final Display primaryDisplay = dm.getDisplay(DEFAULT_DISPLAY);
 final Context windowContext = anyContext.createWindowContext(primaryDisplay,
         TYPE_APPLICATION, null);

 // Get an existing token.
 final IBinder existingToken = activity.getWindow().getAttributes().token;

 // The types used in addView() and createWindowContext() must match.
 final WindowManager.LayoutParams params = new WindowManager.LayoutParams(TYPE_APPLICATION);
 params.token = existingToken;

 // After WindowManager#addView(), the server side will extract the provided token from
 // LayoutParams#token (existingToken in the sample code), and switch to propagate
 // configuration changes from the node associated with the provided token.
 windowContext.getSystemService(WindowManager.class).addView(overlayView, mParams);
 

After Build.VERSION_CODES.S, window context provides the capability to listen to its Configuration changes by calling registerComponentCallbacks(android.content.ComponentCallbacks), while other kinds of Context will register the ComponentCallbacks to its Application context. Note that window context only propagate ComponentCallbacks.onConfigurationChanged(Configuration) callback. ComponentCallbacks.onLowMemory() or other callbacks in ComponentCallbacks2 won't be invoked.

Note that using Application or Service context for UI-related queries may result in layout or continuity issues on devices with variable screen sizes (e.g. foldables) or in multi-window modes, since these non-UI contexts may not reflect the Configuration changes for the visual container.

createWindowContext

public Context createWindowContext (Display display, 
                int type, 
                Bundle options)

Creates a Context for a non-activity window on the given Display.

Similar to createWindowContext(int, android.os.Bundle), but the display is passed in, instead of implicitly using the original Context's Display.

databaseList

public String[] databaseList ()

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

deleteDatabase

public boolean deleteDatabase (String name)

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

deleteFile

public boolean deleteFile (String name)

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

deleteSharedPreferences

public boolean deleteSharedPreferences (String name)

Delete an existing shared preferences file.

enforceCallingOrSelfPermission

public 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

public 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

public 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(java.lang.String, int, int, java.lang.String) with the pid and uid returned by Binder.getCallingPid() and Binder.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

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

If the calling process and uid has not been granted permission to access a specific URI, throw SecurityException. This is basically the same as calling enforceUriPermission(android.net.Uri, int, int, int, java.lang.String) with the pid and uid returned by Binder.getCallingPid() and Binder.getCallingUid(). One important difference is that if you are not currently processing an IPC, this function will always throw a SecurityException.

enforcePermission

public 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

public 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

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

If a particular process and uid 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

public String[] fileList ()

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

getApplicationContext

public 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(android.content.BroadcastReceiver, android.content.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

public ApplicationInfo getApplicationInfo ()

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

getAssets

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

getAttributionSource

public AttributionSource getAttributionSource ()

getBaseContext

public Context getBaseContext ()

getCacheDir

public File getCacheDir ()

Returns the absolute path to the application specific cache directory on the filesystem.

The system will automatically delete files in this directory as disk space is needed elsewhere on the device. The system will always delete older files first, as reported by File.lastModified(). If desired, you can exert more control over how files are deleted using StorageManager.setCacheBehaviorGroup(File, boolean) and StorageManager.setCacheBehaviorTombstone(File, boolean).

Apps are strongly encouraged to keep their usage of cache space below the quota returned by StorageManager.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.

getClassLoader

public ClassLoader getClassLoader ()

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

getCodeCacheDir

public 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

public ContentResolver getContentResolver ()

Return a ContentResolver instance for your application's package.

getDataDir

public 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(java.lang.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

public File getDatabasePath (String name)

Returns the absolute path on the filesystem where a database created with openOrCreateDatabase(String, int, 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.

getDeviceId

public int getDeviceId ()

Gets the device ID this context is associated with. Applications can use this method to determine whether they are running on a virtual device and identify that device. The device ID of the host device is Context.DEVICE_ID_DEFAULT

If the underlying device ID is changed by the system, for example, when an Activity is moved to a different virtual device, applications can register to listen to changes by calling Context.registerDeviceIdChangeListener(Executor, IntConsumer).

This method will only return a reliable value for this instance if it was created with Context.createDeviceContext(int), or if this instance is a UI or Display Context. Contexts created with Context.createDeviceContext(int) will have an explicit device association, which will never change, even if the underlying device is closed or is removed. UI Contexts and Display Contexts are already associated with a display, so if the device association is not explicitly given, Context.getDeviceId() will return the ID of the device associated with the associated display. The system can assign an arbitrary device id value for Contexts not logically associated with a device.

getDir

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

getDisplay

public Display getDisplay ()

Get the display this context is associated with. Applications should use this method with Activity or a context associated with a Display via createDisplayContext(android.view.Display) to get a display object associated with a Context, or DisplayManager.getDisplay(int) to get a display object by id.

getExternalCacheDir

public 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 Build.VERSION_CODES.JELLY_BEAN_MR1 or later and Environment.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 Environment.getExternalStorageState(File).
• There is no security enforced with these files. For example, any application holding Manifest.permission.WRITE_EXTERNAL_STORAGE can write to these files.

If a shared storage device is emulated (as determined by Environment.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 Build.VERSION_CODES.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, Manifest.permission.WRITE_EXTERNAL_STORAGE and/or Manifest.permission.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

public 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 Build.VERSION_CODES.JELLY_BEAN_MR1 or later and Environment.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 Environment.getExternalStorageState(File).
• There is no security enforced with these files. For example, any application holding Manifest.permission.WRITE_EXTERNAL_STORAGE can write to these files.

If a shared storage device is emulated (as determined by Environment.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().

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

public 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 Environment.getExternalStorageState(File).
• There is no security enforced with these files. For example, any application holding Manifest.permission.WRITE_EXTERNAL_STORAGE can write to these files.

If a shared storage device is emulated (as determined by Environment.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 directories returned by getFilesDir(), etc.

Starting in Build.VERSION_CODES.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, Manifest.permission.WRITE_EXTERNAL_STORAGE and/or Manifest.permission.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");
    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");
    return file.exists();
}

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

public 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 Environment.getExternalStorageState(File).
• There is no security enforced with these files. For example, any application holding Manifest.permission.WRITE_EXTERNAL_STORAGE can write to these files.

If a shared storage device is emulated (as determined by Environment.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 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.