CarrierMessagingService

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.

Print the Service's state into the given stream. This gets invoked if you run "adb shell dumpsys activity service <yourservicename>" (note that for this command to work, the service must be running, and you must specify a fully-qualified service name). This is distinct from "dumpsys <servicename>", which only works for named system services and which invokes the IBinder.dump method on the IBinder interface registered with ServiceManager.

Return the application that owns this service.

If the service has become a foreground service by calling startForeground(int,android.app.Notification) or startForeground(int,android.app.Notification,int), getForegroundServiceType() returns the current foreground service type.

If there is no foregroundServiceType specified in manifest, ServiceInfo.FOREGROUND_SERVICE_TYPE_NONE is returned.

If the service is not a foreground service, ServiceInfo.FOREGROUND_SERVICE_TYPE_NONE is returned.

Called by the system when the device configuration changes while your component is running. Note that, unlike activities, other components are never restarted when a configuration changes: they must always deal with the results of the change, such as by re-retrieving resources.

At the time that this function has been called, your Resources object will have been updated to return resource values matching the new configuration.

For more information, read Handling Runtime Changes.

Called by the system when the service is first created. Do not call this method directly.

Called by the system to notify a Service that it is no longer used and is being removed. The service should clean up any resources it holds (threads, registered receivers, etc) at this point. Upon return, there will be no more calls in to this Service object and it is effectively dead. Do not call this method directly.

This is called when the overall system is running low on memory, and actively running processes should trim their memory usage. While the exact point at which this will be called is not defined, generally it will happen when all background process have been killed. That is, before reaching the point of killing processes hosting service and foreground UI that we would like to avoid killing.

Called when new clients have connected to the service, after it had previously been notified that all had disconnected in its onUnbind. This will only be called if the implementation of onUnbind was overridden to return true.

Called by the system every time a client explicitly starts the service by calling android.content.Context#startService, providing the arguments it supplied and a unique integer token representing the start request. Do not call this method directly.

For backwards compatibility, the default implementation calls onStart and returns either START_STICKY or START_STICKY_COMPATIBILITY.

Note that the system calls this on your service's main thread. A service's main thread is the same thread where UI operations take place for Activities running in the same process. You should always avoid stalling the main thread's event loop. When doing long-running operations, network calls, or heavy disk I/O, you should kick off a new thread, or use android.os.AsyncTask.

This is called if the service is currently running and the user has removed a task that comes from the service's application. If you have set ServiceInfo.FLAG_STOP_WITH_TASK then you will not receive this callback; instead, the service will simply be stopped.

Callback called on timeout for ServiceInfo.FOREGROUND_SERVICE_TYPE_SHORT_SERVICE. See ServiceInfo.FOREGROUND_SERVICE_TYPE_SHORT_SERVICE for more details.

If the foreground service of type ServiceInfo.FOREGROUND_SERVICE_TYPE_SHORT_SERVICE doesn't finish even after it's timed out, the app will be declared an ANR after a short grace period of several seconds.

Starting from Android version android.os.Build.VERSION_CODES#VANILLA_ICE_CREAM, onTimeout(int,int) will also be called when a foreground service of type ServiceInfo.FOREGROUND_SERVICE_TYPE_SHORT_SERVICE times out. Developers do not need to implement both of the callbacks on android.os.Build.VERSION_CODES#VANILLA_ICE_CREAM and onwards.

Note, even though ServiceInfo.FOREGROUND_SERVICE_TYPE_SHORT_SERVICE was added on Android version android.os.Build.VERSION_CODES#UPSIDE_DOWN_CAKE, it can be also used on on prior android versions (just like other new foreground service types can be used). However, because android.app.Service#onTimeout(int) did not exist on prior versions, it will never called on such versions. Because of this, developers must make sure to stop the foreground service even if android.app.Service#onTimeout(int) is not called on such versions.

Callback called when a particular foreground service type has timed out.

This callback is meant to give the app a small grace period of a few seconds to finish the foreground service of the associated type - if it fails to do so, the app will crash.

The foreground service of the associated type can be stopped within the time limit by android.app.Service#stopSelf(), android.content.Context#stopService(android.content.Intent) or their overloads. android.app.Service#stopForeground(int) can be used as well, which demotes the service to a "background" service, which will soon be stopped by the system.

The specific time limit for each type (if one exists) is mentioned in the documentation for that foreground service type. See dataSync for example.

Note: time limits are restricted to a rolling 24-hour window - for example, if a foreground service type has a time limit of 6 hours, that time counter begins as soon as the foreground service starts. This time limit will only be reset once every 24 hours or if the app comes into the foreground state.

Called when the operating system has determined that it is a good time for a process to trim unneeded memory from its process. You should never compare to exact values of the level, since new intermediate values may be added -- you will typically want to compare if the value is greater or equal to a level you are interested in.

To retrieve the processes current trim level at any point, you can use ActivityManager.getMyMemoryState(RunningAppProcessInfo).

Called when all clients have disconnected from a particular interface published by the service. The default implementation does nothing and returns false.

If your service is started (running through Context.startService(Intent)), then also make this service run in the foreground, supplying the ongoing notification to be shown to the user while in this state. By default started services are background, meaning that their process won't be given foreground CPU scheduling (unless something else in that process is foreground) and, if the system needs to kill them to reclaim more memory (such as to display a large page in a web browser), they can be killed without too much harm. You use #startForeground if killing your service would be disruptive to the user, such as if your service is performing background music playback, so the user would notice if their music stopped playing.

Note that calling this method does not put the service in the started state itself, even though the name sounds like it. You must always call startService(android.content.Intent) first to tell the system it should keep the service running, and then use this method to tell it to keep it running harder.

Apps targeting API android.os.Build.VERSION_CODES#P or later must request the permission android.Manifest.permission#FOREGROUND_SERVICE in order to use this API.

Apps built with SDK version android.os.Build.VERSION_CODES#Q or later can specify the foreground service types using attribute android.R.attr#foregroundServiceType in service element of manifest file. The value of attribute android.R.attr#foregroundServiceType can be multiple flags ORed together.

Note: Beginning with SDK Version android.os.Build.VERSION_CODES#S, apps targeting SDK Version android.os.Build.VERSION_CODES#S or higher are not allowed to start foreground services from the background. See Behavior changes: Apps targeting Android 12 for more details.

Note: Beginning with SDK Version android.os.Build.VERSION_CODES#UPSIDE_DOWN_CAKE, apps targeting SDK Version android.os.Build.VERSION_CODES#UPSIDE_DOWN_CAKE or higher are not allowed to start foreground services without specifying a valid foreground service type in the manifest attribute android.R.attr#foregroundServiceType. See Behavior changes: Apps targeting Android 14 for more details.

An overloaded version of startForeground(int,android.app.Notification) with additional foregroundServiceType parameter.

Apps built with SDK version android.os.Build.VERSION_CODES#Q or later can specify the foreground service types using attribute android.R.attr#foregroundServiceType in service element of manifest file. The value of attribute android.R.attr#foregroundServiceType can be multiple flags ORed together.

The foregroundServiceType parameter must be a subset flags of what is specified in manifest attribute android.R.attr#foregroundServiceType, if not, an IllegalArgumentException is thrown. Specify foregroundServiceType parameter as android.content.pm.ServiceInfo#FOREGROUND_SERVICE_TYPE_MANIFEST to use all flags that is specified in manifest attribute foregroundServiceType.

Note: Beginning with SDK Version android.os.Build.VERSION_CODES#S, apps targeting SDK Version android.os.Build.VERSION_CODES#S or higher are not allowed to start foreground services from the background. See Behavior changes: Apps targeting Android 12 for more details.

Note: Beginning with SDK Version android.os.Build.VERSION_CODES#UPSIDE_DOWN_CAKE, apps targeting SDK Version android.os.Build.VERSION_CODES#UPSIDE_DOWN_CAKE or higher are not allowed to start foreground services without specifying a valid foreground service type in the manifest attribute android.R.attr#foregroundServiceType, and the parameter foregroundServiceType here must not be the ServiceInfo.FOREGROUND_SERVICE_TYPE_NONE. See Behavior changes: Apps targeting Android 14 for more details.

Legacy version of stopForeground(int).

Remove this service from foreground state, allowing it to be killed if more memory is needed. This does not stop the service from running (for that you use stopSelf() or related methods), just takes it out of the foreground state.

If STOP_FOREGROUND_REMOVE is supplied, the service's associated notification will be cancelled immediately.

If STOP_FOREGROUND_DETACH is supplied, the service's association with the notification will be severed. If the notification had not yet been shown, due to foreground-service notification deferral policy, it is immediately posted when stopForeground(STOP_FOREGROUND_DETACH) is called. In all cases, the notification remains shown even after this service is stopped fully and destroyed.

If zero is passed as the argument, the result will be the legacy behavior as defined prior to Android L: the notification will remain posted until the service is fully stopped, at which time it will automatically be cancelled.

Stop the service, if it was previously started. This is the same as calling android.content.Context#stopService for this particular service.

Old version of stopSelfResult that doesn't return a result.

Stop the service if the most recent time it was started was startId. This is the same as calling android.content.Context#stopService for this particular service but allows you to safely avoid stopping if there is a start request from a client that you haven't yet seen in onStart.

Be careful about ordering of your calls to this function.. If you call this function with the most-recently received ID before you have called it for previously received IDs, the service will be immediately stopped anyway. If you may end up processing IDs out of order (such as by dispatching them on separate threads), then you are responsible for stopping them in the same order you received them.

Variation of #bindService 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 android.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.

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

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

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 with the arguments containing the command to be sent, with the service calling its android.app.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, 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.

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.

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

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, except it grants your own permissions if you are not currently processing an IPC. Use with care!

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, except it grants your own permissions if you are not currently processing an IPC. Use with care!

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 android.os.Binder#getCallingPid and android.os.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 to avoid this protection.

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 android.os.Binder#getCallingPid and android.os.Binder#getCallingUid. One important difference is that if you are not currently processing an IPC, this function will always fail.

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 android.os.Binder#getCallingPid and android.os.Binder#getCallingUid. One important difference is that if you are not currently processing an IPC, this function will always fail.

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.

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

Determine whether you have been granted a particular permission.

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.

Check both a Uri and normal permission. This allows you to perform both checkPermission and #checkUriPermission in one call.

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 android.os.Build.VERSION_CODES#S, calling this method from a secondary-user's context will incorrectly return PackageManager.PERMISSION_DENIED for all {code uris}.

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.

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.

Creates a context with specific properties and behaviors.

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.

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.

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 android.hardware.display.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.

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 android.content.pm.PackageManager.NameNotFoundException if there is no application with the given package name.

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

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.

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 android.view.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 android.view.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. Note that window context only propagate ComponentCallbacks.onConfigurationChanged(Configuration) callback. ComponentCallbacks.onLowMemory() or other callbacks in ComponentCallbacks2 won't be invoked.

Note that using android.app.Application or android.app.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.

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

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

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

Delete an existing shared preferences file.

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, except it grants your own permissions if you are not currently processing an IPC. Use with care!

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, except it grants your own permissions if you are not currently processing an IPC. Use with care!

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 android.os.Binder#getCallingPid and android.os.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 to avoid this protection.

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 android.os.Binder#getCallingPid and android.os.Binder#getCallingUid. One important difference is that if you are not currently processing an IPC, this function will always throw a SecurityException.

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

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.

Enforce both a Uri and normal permission. This allows you to perform both enforcePermission and #enforceUriPermission in one call.

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

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.

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

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.

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.

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

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.

Return a ContentResolver instance for your application's package.

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.

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

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.

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.

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

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 android.os.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 android.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 android.os.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, android.Manifest.permission#WRITE_EXTERNAL_STORAGE and/or android.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.

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

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 android.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 android.os.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, android.Manifest.permission#WRITE_EXTERNAL_STORAGE and/or android.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:

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:

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

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 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 android.Manifest.permission#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.

Returns the absolute path on the filesystem where a file created with openFileOutput 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.

Returns the absolute path to the directory on the filesystem where files created with openFileOutput 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.

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

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

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.

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

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

<uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE" android:maxSdkVersion="23" />

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

The following code snippet shows how to do this:

File obb = new File(obb_filename);
  boolean open_failed = false;
 
  try {
      BufferedReader br = new BufferedReader(new FileReader(obb));
      open_failed = false;
      ReadObbFile(br);
  } catch (IOException e) {
      open_failed = true;
  }
 
  if (open_failed) {
      // request READ_EXTERNAL_STORAGE permission before reading OBB file
      ReadObbFileWithPermission();
  }
  

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

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.

Return PackageManager instance to find global package information.

Return the name of this application's package.

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.

Return the set of parameters which this Context was created with, if it was created via createContext(android.content.ContextParams).

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.

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.

This method is thread-safe.

If the preferences directory does not already exist, it will be created when this method is called.

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

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 android.view.WindowManager. Must only be obtained from a visual context such as Activity or a Context created with createWindowContext(int,android.os.Bundle), which are adjusted to the configuration and visual bounds of an area on screen.

LAYOUT_INFLATER_SERVICE ("layout_inflater")

A android.view.LayoutInflater for inflating layout resources in this context. Must only be obtained from a visual context such as Activity or a Context created with createWindowContext(int,android.os.Bundle), which are adjusted to the configuration and visual bounds of an area on screen.

ACTIVITY_SERVICE ("activity")

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

WALLPAPER_SERVICE ("wallpaper")

A android.service.wallpaper.WallpaperService for accessing wallpapers in this context. Must only be obtained from a visual context such as Activity or a Context created with createWindowContext(int,android.os.Bundle), which are adjusted to the configuration and visual bounds of an area on screen.

POWER_SERVICE ("power")

A android.os.PowerManager for controlling power management.

ALARM_SERVICE ("alarm")

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

NOTIFICATION_SERVICE ("notification")

A android.app.NotificationManager for informing the user of background events.

KEYGUARD_SERVICE ("keyguard")

A android.app.KeyguardManager for controlling keyguard.

LOCATION_SERVICE ("location")

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

SEARCH_SERVICE ("search")

A android.app.SearchManager for handling search.

VIBRATOR_MANAGER_SERVICE ("vibrator_manager")

A android.os.VibratorManager for accessing the device vibrators, interacting with individual ones and playing synchronized effects on multiple vibrators.

VIBRATOR_SERVICE ("vibrator")

A android.os.Vibrator for interacting with the vibrator hardware.

CONNECTIVITY_SERVICE ("connectivity")

A ConnectivityManager for handling management of network connections.

IPSEC_SERVICE ("ipsec")

A IpSecManager for managing IPSec on sockets and networks.

WIFI_SERVICE ("wifi")

A WifiManager for management of Wi-Fi connectivity. On releases before Android 7, it should only be obtained from an application context, and not from any other derived context to avoid memory leaks within the calling process.

WIFI_AWARE_SERVICE ("wifiaware")

A WifiAwareManager for management of Wi-Fi Aware discovery and 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 android.app.UiModeManager for controlling UI modes.

DOWNLOAD_SERVICE ("download")

A android.app.DownloadManager for requesting HTTP downloads

BATTERY_SERVICE ("batterymanager")

A android.os.BatteryManager for managing battery state

JOB_SCHEDULER_SERVICE ("taskmanager")

A android.app.job.JobScheduler for managing scheduled tasks

NETWORK_STATS_SERVICE ("netstats")

A NetworkStatsManager for querying network usage statistics.

HARDWARE_PROPERTIES_SERVICE ("hardware_properties")

A android.os.HardwarePropertiesManager for accessing hardware properties.

DOMAIN_VERIFICATION_SERVICE ("domain_verification")

A android.content.pm.verify.domain.DomainVerificationManager for accessing web domain approval state.

DISPLAY_HASH_SERVICE ("display_hash")

A android.view.displayhash.DisplayHashManager for management of display hashes.

#AUTHENTICATION_POLICY_SERVICE ("authentication_policy")

A android.security.authenticationpolicy.AuthenticationPolicyManager for managing authentication related policies on the device.

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

Note: Instant apps, for which PackageManager.isInstantApp() returns true, don't have access to the following system services: DEVICE_POLICY_SERVICE, #FINGERPRINT_SERVICE, KEYGUARD_SERVICE, SHORTCUT_SERVICE, USB_SERVICE, WALLPAPER_SERVICE, WIFI_P2P_SERVICE, WIFI_SERVICE, WIFI_AWARE_SERVICE. For these services this method will return null. Generally, if you are running as an instant app you should always check whether the result of this method is null.

Note: When implementing this method, keep in mind that new services can be added on newer Android releases, so if you're looking for just the explicit names mentioned above, make sure to return null when you don't recognize the name — if you throw a RuntimeException exception instead, your app might break on new Android releases.

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

Return the Theme object associated with this Context.

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

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

Indicates whether this Context is restricted.

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.

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.

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

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.

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

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.

Add a new ComponentCallbacks to the base application of the Context, which will be called at the same times as the ComponentCallbacks methods of activities and other components are called. Note that you must be sure to use unregisterComponentCallbacks when appropriate in the future; this will not be removed for you.

After Build.VERSION_CODES.TIRAMISU, the ComponentCallbacks will be registered to the base Context, and can be only used after attachBaseContext(android.content.Context). Users can still call to getApplicationContext().registerComponentCallbacks(ComponentCallbacks) to add ComponentCallbacks to the base application.

Adds a new device ID changed listener to the Context, which will be called when the device association is changed by the system.

The callback can be called when an app is moved to a different device and the Context is not explicitly associated with a specific device.

When an application receives a device id update callback, this Context is guaranteed to also have an updated display ID(if any) and Configuration.

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

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

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

If you know the Intent you 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 android.os.Build.VERSION_CODES#UPSIDE_DOWN_CAKE, the system can place context-registered broadcasts in a queue while the app is in the cached state. When the app leaves the cached state, such as returning to the foreground, the system delivers any queued broadcasts. Multiple instances of certain broadcasts might be merged into one broadcast.

As of android.os.Build.VERSION_CODES#ICE_CREAM_SANDWICH, receivers registered with this method will correctly respect the Intent.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.

For apps targeting android.os.Build.VERSION_CODES#UPSIDE_DOWN_CAKE, either RECEIVER_EXPORTED or RECEIVER_NOT_EXPORTED must be specified if the receiver is not being registered for system broadcasts or a SecurityException will be thrown. See registerReceiver(android.content.BroadcastReceiver,android.content.IntentFilter,int) to register a receiver with flags.

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, since the lifetime of such a registered BroadcastReceiver is tied to the object that registered it.

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

See BroadcastReceiver for more information on Intent broadcasts.

As of android.os.Build.VERSION_CODES#UPSIDE_DOWN_CAKE, the system can place context-registered broadcasts in a queue while the app is in the cached state. When the app leaves the cached state, such as returning to the foreground, the system delivers any queued broadcasts. Multiple instances of certain broadcasts might be merged into one broadcast.

As of android.os.Build.VERSION_CODES#ICE_CREAM_SANDWICH, receivers registered with this method will correctly respect the Intent.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.

Register to receive intent broadcasts, to run in the context of scheduler. See registerReceiver(android.content.BroadcastReceiver,android.content.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 android.os.Build.VERSION_CODES#UPSIDE_DOWN_CAKE, the system can place context-registered broadcasts in a queue while the app is in the cached state. When the app leaves the cached state, such as returning to the foreground, the system delivers any queued broadcasts. Multiple instances of certain broadcasts might be merged into one broadcast.

As of android.os.Build.VERSION_CODES#ICE_CREAM_SANDWICH, receivers registered with this method will correctly respect the Intent.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.

For apps targeting android.os.Build.VERSION_CODES#UPSIDE_DOWN_CAKE, either RECEIVER_EXPORTED or RECEIVER_NOT_EXPORTED must be specified if the receiver is not being registered for system broadcasts or a SecurityException will be thrown. See registerReceiver(android.content.BroadcastReceiver,android.content.IntentFilter,java.lang.String,android.os.Handler,int) to register a receiver with flags.

Register to receive intent broadcasts, to run in the context of scheduler. See registerReceiver(android.content.BroadcastReceiver,android.content.IntentFilter,int) and registerReceiver(android.content.BroadcastReceiver,android.content.IntentFilter,java.lang.String,android.os.Handler) for more information.

See BroadcastReceiver for more information on Intent broadcasts.

As of android.os.Build.VERSION_CODES#UPSIDE_DOWN_CAKE, the system can place context-registered broadcasts in a queue while the app is in the cached state. When the app leaves the cached state, such as returning to the foreground, the system delivers any queued broadcasts. Multiple instances of certain broadcasts might be merged into one broadcast.

As of android.os.Build.VERSION_CODES#ICE_CREAM_SANDWICH, receivers registered with this method will correctly respect the Intent.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.

Remove the data previously sent with #sendStickyBroadcast, so that it is as if the sticky broadcast had never happened.
Requires android.Manifest.permission#BROADCAST_STICKY

Version of removeStickyBroadcast(android.content.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.

You must hold the android.Manifest.permission#BROADCAST_STICKY permission in order to use this API. If you do not hold that permission, SecurityException will be thrown.
Requires android.Manifest.permission.INTERACT_ACROSS_USERS and android.Manifest.permission#BROADCAST_STICKY

Triggers the revocation of one or more permissions for the calling package. A package is only able to revoke runtime permissions. If a permission is not currently granted, it is ignored and will not get revoked (even if later granted by the user). Ultimately, you should never make assumptions about a permission status as users may grant or revoke them at any time.

Background permissions which have no corresponding foreground permission still granted once the revocation is effective will also be revoked.

The revocation happens asynchronously and kills all processes running in the calling UID. It will be triggered once it is safe to do so. In particular, it will not be triggered as long as the package remains in the foreground, or has any active manifest components (e.g. when another app is accessing a content provider in the package).

If you want to revoke the permissions right away, you could call System.exit() in Handler.postDelayed with a delay to allow completion of async IPC, But System.exit() could affect other apps that are accessing your app at the moment. For example, apps accessing a content provider in your app will all crash.

Note that the settings UI shows a permission group as granted as long as at least one permission in the group is granted. If you want the user to observe the revocation in the settings, you should revoke every permission in the target group. To learn the current list of permissions in a group, you may use PackageManager.getGroupOfPlatformPermission(String, Executor, Consumer) and PackageManager.getPlatformPermissionsForGroup(String, Executor, Consumer). This list of permissions may evolve over time, so it is recommended to check whether it contains any permission you wish to retain before trying to revoke an entire group.

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

Prior to android.os.Build.VERSION_CODES#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 android.os.Build.VERSION_CODES#LOLLIPOP, this function will not throw a security exception, but will remove whatever permission grants to the Uri had been given to the app (or none).

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

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

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

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(android.content.Intent,java.lang.String).

See BroadcastReceiver for more information on Intent broadcasts.

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(android.content.Intent,java.lang.String).

See BroadcastReceiver for more information on Intent broadcasts.

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(android.content.Intent,java.lang.String).

See BroadcastReceiver for more information on Intent broadcasts.

Version of sendBroadcast(android.content.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.
Requires android.Manifest.permission.INTERACT_ACROSS_USERS

Version of sendBroadcast(android.content.Intent,java.lang.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.
Requires android.Manifest.permission.INTERACT_ACROSS_USERS

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.

Version of sendBroadcast(android.content.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 BroadcastReceiver.onReceive 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(android.content.Intent,java.lang.String).

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

See BroadcastReceiver for more information on Intent broadcasts.

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.

Version of sendBroadcast(android.content.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 BroadcastReceiver.onReceive 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(android.content.Intent,java.lang.String).

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

See BroadcastReceiver for more information on Intent broadcasts.

Version of sendOrderedBroadcast(android.content.Intent,java.lang.String,android.content.BroadcastReceiver,android.os.Handler,int,java.lang.String,android.os.Bundle) that allows you to specify the App Op to enforce restrictions on which receivers the broadcast will be sent to.

See BroadcastReceiver for more information on Intent broadcasts.

Version of sendOrderedBroadcast(android.content.Intent,java.lang.String,android.content.BroadcastReceiver,android.os.Handler,int,java.lang.String,android.os.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.

See BroadcastReceiver for more information on Intent broadcasts.
Requires android.Manifest.permission.INTERACT_ACROSS_USERS

Perform a sendBroadcast(android.content.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(android.content.BroadcastReceiver,android.content.IntentFilter). In all other ways, this behaves the same as sendBroadcast(android.content.Intent).
Requires android.Manifest.permission#BROADCAST_STICKY

Perform a sendBroadcast(android.content.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(android.content.BroadcastReceiver,android.content.IntentFilter). In all other ways, this behaves the same as sendBroadcast(android.content.Intent).

Version of sendStickyBroadcast(android.content.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.
Requires android.Manifest.permission.INTERACT_ACROSS_USERS and android.Manifest.permission#BROADCAST_STICKY

Version of #sendStickyBroadcast 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 BroadcastReceiver.onReceive 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(android.content.Intent,java.lang.String).

Like sendBroadcast(android.content.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.
Requires android.Manifest.permission#BROADCAST_STICKY

Version of sendStickyOrderedBroadcast(android.content.Intent,android.content.BroadcastReceiver,android.os.Handler,int,java.lang.String,android.os.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.

See BroadcastReceiver for more information on Intent broadcasts.
Requires android.Manifest.permission.INTERACT_ACROSS_USERS and android.Manifest.permission#BROADCAST_STICKY

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 android.app.Activity#setContentView or android.view.LayoutInflater#inflate).

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

Launch multiple new activities. This is generally the same as calling startActivity(android.content.Intent) for the first Intent in the array, that activity during its creation calling startActivity(android.content.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.

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

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 android.app.Activity Context, then the Intent must include the Intent.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.

Similar to startService(android.content.Intent), but with an implicit promise that the Service will call startForeground(int, android.app.Notification) once it begins running. The service is given an amount of time comparable to the ANR interval to do this, otherwise the system will automatically crash the process, in which case an internal exception ForegroundServiceDidNotStartInTimeException is logged on logcat on devices running SDK Version android.os.Build.VERSION_CODES#S or later. On older Android versions, an internal exception RemoteServiceException is logged instead, with a corresponding message.

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

Note: Beginning with SDK Version android.os.Build.VERSION_CODES#S, apps targeting SDK Version android.os.Build.VERSION_CODES#S or higher are not allowed to start foreground services from the background. See Behavior changes: Apps targeting Android 12 for more details.

Start executing an android.app.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).

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

Like startActivity(android.content.Intent,android.os.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(android.content.Intent) here; otherwise, its associated action will be executed (such as sending a broadcast) as if you had called android.content.IntentSender#sendIntent on it.