Method Detail

• startActivities

   static boolean startActivities(@NonNull() Context context, @NonNull() Array<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 forapp navigation using the back key changed. The back key's behavior is localto the current task and does not capture navigation across different tasks.Navigating across tasks and easily reaching the previous task is accomplishedthrough the "recents" UI, accessible through the software-provided Recents keyon the navigation or system bar. On devices with the older hardware button configurationthe 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 thatthe user may navigate out of the new task and back to the Launcher by repeatedpresses of the back key. Back key presses should not navigate across task stacks.

  startActivities provides a mechanism for constructing a synthetic task stack ofmultiple activities. If the underlying API is not available on the system this methodwill return false.

  Parameters:

  context - Start activities using this activity as the starting context

  intents - Array of intents defining the activities that will be started.

• startActivities

   static boolean startActivities(@NonNull() Context context, @NonNull() Array<Intent> intents, @Nullable() 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 forapp navigation using the back key changed. The back key's behavior is localto the current task and does not capture navigation across different tasks.Navigating across tasks and easily reaching the previous task is accomplishedthrough the "recents" UI, accessible through the software-provided Recents keyon the navigation or system bar. On devices with the older hardware button configurationthe 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 thatthe user may navigate out of the new task and back to the Launcher by repeatedpresses of the back key. Back key presses should not navigate across task stacks.

  startActivities provides a mechanism for constructing a synthetic task stack ofmultiple activities. If the underlying API is not available on the system this methodwill return false.

  Parameters:

  context - Start activities using this activity as the starting context

  intents - Array of intents defining the activities that will be started.

  options - Additional options for how the Activity should be started.

• startActivity

   static void startActivity(@NonNull() Context context, @NonNull() Intent intent, @Nullable() Bundle options)

  Start an activity with additional launch information, if able.

  In Android 4.1+ additional options were introduced to allow for morecontrol on activity launch animations. Applications can use this methodalong with ActivityOptionsCompat to use these animations whenavailable. When run on versions of the platform where this feature doesnot exist the activity will be launched normally.

  Parameters:

  context - Context to launch activity from.

  intent - The description of the activity to start.

  options - Additional options for how the Activity should be started.May be null if there are no options.

• getDataDir

  @Nullable() static File getDataDir(@NonNull() Context context)

  Returns the absolute path to the directory on the filesystem where allprivate files belonging to this app are stored. Apps should not use thispath directly; they should instead use getFilesDir, getCacheDir, getDir, orother storage APIs on Context.

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

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

• getObbDirs

  @NonNull() static Array<File> getObbDirs(@NonNull() Context context)

  Returns absolute paths to application-specific directories on allexternal storage devices where the application's OBB files (if there areany) 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 bedeleted when the application is uninstalled, however there are someimportant differences:

  • External files are not always available: they will disappear if theuser 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 ofthe device, including both emulated external storage and physical mediaslots, such as SD cards in a battery compartment. The returned paths donot include transient devices, such as USB flash drives.

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

  Starting in KITKAT, no permissionsare required to write to the returned paths; they're always accessible tothe calling app. Before then, WRITE_EXTERNAL_STORAGE is required towrite. Write access outside of these paths on secondary external storagedevices is not available. To request external storage access in abackwards compatible way, consider using {@code 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 {@code null} if a storage device is unavailable.

• getExternalFilesDirs

  @NonNull() static Array<File> getExternalFilesDirs(@NonNull() Context context, @Nullable() String type)

  Returns absolute paths to application-specific directories on allexternal storage devices where the application can place persistent filesit owns. These files are internal to the application, and not typicallyvisible to the user as media.

  This is like getFilesDir in that these files will bedeleted when the application is uninstalled, however there are someimportant differences:

  • External files are not always available: they will disappear if theuser 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 ofthe device, including both emulated external storage and physical mediaslots, such as SD cards in a battery compartment. The returned paths donot include transient devices, such as USB flash drives.

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

  Starting in KITKAT, no permissionsare required to write to the returned paths; they're always accessible tothe calling app. Before then, WRITE_EXTERNAL_STORAGE is required towrite. Write access outside of these paths on secondary external storagedevices is not available. To request external storage access in abackwards compatible way, consider using {@code 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. Returned paths may be {@code null} if a storage device is unavailable.

• getExternalCacheDirs

  @NonNull() static Array<File> getExternalCacheDirs(@NonNull() Context context)

  Returns absolute paths to application-specific directories on allexternal storage devices where the application can place cache files itowns. These files are internal to the application, and not typicallyvisible to the user as media.

  This is like getCacheDir in that these files will bedeleted when the application is uninstalled, however there are someimportant differences:

  • External files are not always available: they will disappear if theuser 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 ofthe device, including both emulated external storage and physical mediaslots, such as SD cards in a battery compartment. The returned paths donot include transient devices, such as USB flash drives.

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

  Starting in KITKAT, no permissionsare required to write to the returned paths; they're always accessible tothe calling app. Before then, WRITE_EXTERNAL_STORAGE is required towrite. Write access outside of these paths on secondary external storagedevices is not available. To request external storage access in abackwards compatible way, consider using {@code 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 {@code null} if a storage device is unavailable.

• getDrawable

  @Nullable() static Drawable getDrawable(@NonNull() Context context, @DrawableRes() int id)

  Returns a drawable object associated with a particular resource ID.

  Starting in LOLLIPOP, thereturned 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.

• getColorStateList

  @Nullable() static ColorStateList getColorStateList(@NonNull() Context context, @ColorRes() int id)

  Returns a color state list associated with a particular resource ID.

  Starting in M, the returnedcolor state list will be styled for the specified Context's theme.

  Parameters:

  id - The desired resource identifier, as generated by the aapttool.

• getColor

  @ColorInt() static int getColor(@NonNull() Context context, @ColorRes() int id)

  Returns a color associated with a particular resource ID

  Starting in M, the returnedcolor will be styled for the specified Context's theme.

  Parameters:

  id - The desired resource identifier, as generated by the aapttool.

• checkSelfPermission

   static int checkSelfPermission(@NonNull() Context context, @NonNull() String permission)

  Determine whether you have been granted a particular permission.

  Parameters:

  permission - The name of the permission being checked.

• getNoBackupFilesDir

  @Nullable() static File getNoBackupFilesDir(@NonNull() Context context)

  Returns the absolute path to the directory on the filesystem similar to getFilesDir. The difference is that files placed under thisdirectory will be excluded from automatic backup to remote storage ondevices running LOLLIPOP or later.

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

• getCodeCacheDir

   static File getCodeCacheDir(@NonNull() Context context)

  Returns the absolute path to the application specific cache directory onthe filesystem designed for storing cached code. On devices running LOLLIPOP or later, the system will deleteany files stored in this location both when your specific application isupgraded, and when the entire platform is upgraded.

  This location is optimal for storing compiled or optimized code generatedby 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.

• createDeviceProtectedStorageContext

  @Nullable() static Context createDeviceProtectedStorageContext(@NonNull() Context context)

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

  On devices with direct boot, data stored in this location is encryptedwith a key tied to the physical device, and it can be accessedimmediately after the device has booted successfully, bothbefore and after the user has authenticated with theircredentials (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. Forexample, storing sensitive authentication tokens or passwords in thedevice-protected area is strongly discouraged.

  If the underlying device does not have the ability to storedevice-protected and credential-protected data using different keys, thenboth storage areas will become available at the same time. They remain astwo distinct storage locations on disk, and only the window ofavailability changes.

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

  Prior to API 24 this method returns {@code null}, since device-protected storage is not available.

• isDeviceProtectedStorage

   static boolean isDeviceProtectedStorage(@NonNull() Context context)

  Indicates if the storage APIs of this Context are backed bydevice-encrypted storage.

• getMainExecutor

   static Executor getMainExecutor(Context context)

  Return an Executor that will run enqueued tasks on the mainthread associated with this context. This is the thread used to dispatchcalls to application components (activities, services, etc).

• startForegroundService

   static void startForegroundService(@NonNull() Context context, @NonNull() Intent intent)

  startForegroundService() was introduced in O, just call startServicefor before O.

  Parameters:

  context - Context to start Service from.

  intent - The description of the Service to start.

• getSystemService

  @Nullable() static <T> T getSystemService(@NonNull() Context context, @NonNull() Class<T> serviceClass)

  Return the handle to a system-level service by class.

  Parameters:

  context - Context to retrieve service from.

  serviceClass - The class of the desired service.

• getSystemServiceName

  @Nullable() static String getSystemServiceName(@NonNull() Context context, @NonNull() Class<out Object> serviceClass)

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

  Parameters:

  context - Context to retrieve service name from.

  serviceClass - The class of the desired service.