Android APIs
public class

ContextCompat

extends Object
java.lang.Object
   ↳ android.support.v4.content.ContextCompat
Known Direct Subclasses

Class Overview

Helper for accessing features in Context introduced after API level 4 in a backwards compatible fashion.

Summary

Public Constructors
ContextCompat()
Public Methods
final File getCodeCacheDir(Context context)
Returns the absolute path to the application specific cache directory on the filesystem designed for storing cached code.
final static Drawable getDrawable(Context context, int id)
Return a drawable object associated with a particular resource ID.
static File[] getExternalCacheDirs(Context context)
Returns absolute paths to application-specific directories on all external storage devices where the application can place cache files it owns.
static File[] getExternalFilesDirs(Context context, String type)
Returns absolute paths to application-specific directories on all external storage devices where the application can place persistent files it owns.
final File getNoBackupFilesDir(Context context)
Returns the absolute path to the directory on the filesystem similar to getFilesDir().
static File[] getObbDirs(Context context)
Returns absolute paths to application-specific directories on all external storage devices where the application's OBB files (if there are any) can be found.
static boolean startActivities(Context context, Intent[] intents)
Start a set of activities as a synthesized task stack, if able.
static boolean startActivities(Context context, Intent[] intents, Bundle options)
Start a set of activities as a synthesized task stack, if able.
[Expand]
Inherited Methods
From class java.lang.Object

Public Constructors

public ContextCompat ()

Public Methods

public final File getCodeCacheDir (Context context)

Returns the absolute path to the application specific cache directory on the filesystem designed for storing cached code. On devices running LOLLIPOP or later, 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.

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

Returns
  • The path of the directory holding application code cache files.

public static final Drawable getDrawable (Context context, int id)

Return a drawable object associated with a particular resource ID.

Starting in LOLLIPOP, the returned drawable will be styled for the specified Context's theme.

Parameters
id The desired resource identifier, as generated by the aapt tool. This integer encodes the package, type, and resource entry. The value 0 is an invalid identifier.
Returns
  • Drawable An object that can be used to draw this resource.

public static File[] getExternalCacheDirs (Context context)

Returns absolute paths to application-specific directories on all 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:

  • External files are not always available: they will disappear if the user mounts the external storage on a computer or removes it.
  • There is no security enforced with these files.

External storage devices returned here are considered a permanent part of the device, including both emulated external storage and physical media slots, such as SD cards in a battery compartment. The returned paths do not include transient devices, such as USB flash drives.

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.

Starting in KITKAT, no permissions are required to write to the returned paths; they're always accessible to the calling app. Before then, WRITE_EXTERNAL_STORAGE is required to write. Write access outside of these paths on secondary external storage devices is not available. To request external storage access in a backwards compatible way, consider using android:maxSdkVersion like this:

<uses-permission
     android:name="android.permission.WRITE_EXTERNAL_STORAGE"
     android:maxSdkVersion="18" />

The first path returned is the same as getExternalCacheDir(). Returned paths may be null if a storage device is unavailable.

public static File[] getExternalFilesDirs (Context context, String type)

Returns absolute paths to application-specific directories on all 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:

  • External files are not always available: they will disappear if the user mounts the external storage on a computer or removes it.
  • There is no security enforced with these files.

External storage devices returned here are considered a permanent part of the device, including both emulated external storage and physical media slots, such as SD cards in a battery compartment. The returned paths do not include transient devices, such as USB flash drives.

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.

Starting in KITKAT, no permissions are required to write to the returned paths; they're always accessible to the calling app. Before then, WRITE_EXTERNAL_STORAGE is required to write. Write access outside of these paths on secondary external storage devices is not available. To request external storage access in a backwards compatible way, consider using android:maxSdkVersion like this:

<uses-permission
     android:name="android.permission.WRITE_EXTERNAL_STORAGE"
     android:maxSdkVersion="18" />

The first path returned is the same as getExternalFilesDir(String). Returned paths may be null if a storage device is unavailable.

public final File getNoBackupFilesDir (Context context)

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 on devices running LOLLIPOP or later. See BackupAgent for a full discussion of the automatic backup mechanism in Android.

No permissions are required to read or write to the returned path, since this path is internal storage.

Returns
  • The path of the directory holding application files that will not be automatically backed up to remote storage.

public static File[] getObbDirs (Context context)

Returns absolute paths to application-specific directories on all 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:

  • External files are not always available: they will disappear if the user mounts the external storage on a computer or removes it.
  • There is no security enforced with these files.

External storage devices returned here are considered a permanent part of the device, including both emulated external storage and physical media slots, such as SD cards in a battery compartment. The returned paths do not include transient devices, such as USB flash drives.

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.

Starting in KITKAT, no permissions are required to write to the returned paths; they're always accessible to the calling app. Before then, WRITE_EXTERNAL_STORAGE is required to write. Write access outside of these paths on secondary external storage devices is not available. To request external storage access in a backwards compatible way, consider using android:maxSdkVersion like this:

<uses-permission
     android:name="android.permission.WRITE_EXTERNAL_STORAGE"
     android:maxSdkVersion="18" />

The first path returned is the same as getObbDir(). Returned paths may be null if a storage device is unavailable.

public static boolean startActivities (Context context, Intent[] intents)

Start a set of activities as a synthesized task stack, if able.

In API level 11 (Android 3.0/Honeycomb) the recommended conventions for app navigation using the back key changed. The back key's behavior is local to the current task and does not capture navigation across different tasks. Navigating across tasks and easily reaching the previous task is accomplished through the "recents" UI, accessible through the software-provided Recents key on the navigation or system bar. On devices with the older hardware button configuration the recents UI can be accessed with a long press on the Home key.

When crossing from one task stack to another post-Android 3.0, the application should synthesize a back stack/history for the new task so that the user may navigate out of the new task and back to the Launcher by repeated presses of the back key. Back key presses should not navigate across task stacks.

startActivities provides a mechanism for constructing a synthetic task stack of multiple activities. If the underlying API is not available on the system this method will return false.

Parameters
context Start activities using this activity as the starting context
intents Array of intents defining the activities that will be started. The element length-1 will correspond to the top activity on the resulting task stack.
Returns
  • true if the underlying API was available and the call was successful, false otherwise

public static boolean startActivities (Context context, Intent[] intents, Bundle options)

Start a set of activities as a synthesized task stack, if able.

In API level 11 (Android 3.0/Honeycomb) the recommended conventions for app navigation using the back key changed. The back key's behavior is local to the current task and does not capture navigation across different tasks. Navigating across tasks and easily reaching the previous task is accomplished through the "recents" UI, accessible through the software-provided Recents key on the navigation or system bar. On devices with the older hardware button configuration the recents UI can be accessed with a long press on the Home key.

When crossing from one task stack to another post-Android 3.0, the application should synthesize a back stack/history for the new task so that the user may navigate out of the new task and back to the Launcher by repeated presses of the back key. Back key presses should not navigate across task stacks.

startActivities provides a mechanism for constructing a synthetic task stack of multiple activities. If the underlying API is not available on the system this method will return false.

Parameters
context Start activities using this activity as the starting context
intents Array of intents defining the activities that will be started. The element length-1 will correspond to the top activity on the resulting task stack.
options Additional options for how the Activity should be started. See {@link android.content.Context#startActivity(Intent, Bundle)
Returns
  • true if the underlying API was available and the call was successful, false otherwise