ConnectionService

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

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.

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.

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.

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

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.

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

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.

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.

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 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 given permission is not allowed for a particular process and user ID running in the system, throw a SecurityException.

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

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 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)), it's contents are backed by a private user data partition, which means there is little benefit to storing data here instead of the private directories returned by getFilesDir(), etc.

Starting in 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:

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.

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 your are registering for is sticky, you can supply null for your receiver. In this case, no receiver is registered -- the function simply returns the sticky Intent that matches filter. In the case of multiple matches, the same rules as described above apply.

See BroadcastReceiver for more information on Intent broadcasts.

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

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

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

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

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.

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 stop the service and declare the app ANR.

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.

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.

Request that a given application service be started. The Intent should either contain the complete class name of a specific service implementation to start, or a specific package name to target. If the Intent is less specified, it logs a warning about this. In this case any of the multiple matching services may be used. If this service is not already running, it will be instantiated and started (creating a process for it if needed); if it is running then it remains running.

Every call to this method will result in a corresponding call to the target service's android.app.Service#onStartCommand method, with the intent given here. This provides a convenient way to submit jobs to a service without having to bind and call on to its interface.

Using startService() overrides the default service lifetime that is managed by #bindService: it requires the service to remain running until stopService is called, regardless of whether any clients are connected to it. Note that calls to startService() do not nest: no matter how many times you call startService(), a single call to stopService will stop it.

The system attempts to keep running services around as much as possible. The only time they should be stopped is if the current foreground application is using so many resources that the service needs to be killed. If any errors happen in the service's process, it will automatically be restarted.

This function will throw SecurityException if you do not have permission to start the given service.

Note: Each call to startService() results in significant work done by the system to manage service lifecycle surrounding the processing of the intent, which can take multiple milliseconds of CPU time. Due to this cost, startService() should not be used for frequent intent delivery to a service, and only for scheduling significant work. Use #bindService for high frequency calls.

Returns a color associated with a particular resource ID and styled for the current theme.

Returns a color state list associated with a particular resource ID and styled for the current theme.

Returns a drawable object associated with a particular resource ID and styled for the current theme.

Returns a localized string from the application's package's default string table.

Returns a localized formatted string from the application's package's default string table, substituting the format arguments as defined in java.util.Formatter and java.lang.String#format.

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

Currently available classes are: android.view.WindowManager, android.view.LayoutInflater, android.app.ActivityManager, android.os.PowerManager, android.app.AlarmManager, android.app.NotificationManager, android.app.KeyguardManager, android.location.LocationManager, android.app.SearchManager, android.os.Vibrator, android.net.ConnectivityManager, android.net.wifi.WifiManager, android.media.AudioManager, android.media.MediaRouter, android.telephony.TelephonyManager, android.telephony.SubscriptionManager, android.view.inputmethod.InputMethodManager, android.app.UiModeManager, android.app.DownloadManager, android.os.BatteryManager, android.app.job.JobScheduler, android.app.usage.NetworkStatsManager, android.content.pm.verify.domain.DomainVerificationManager.

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.

Return a localized, styled CharSequence from the application's package's default string table.

Retrieve styled attribute information in this Context's theme. See android.content.res.Resources.Theme#obtainStyledAttributes(int[]) for more information.

Retrieve styled attribute information in this Context's theme. See android.content.res.Resources.Theme#obtainStyledAttributes(int, int[]) for more information.

Retrieve styled attribute information in this Context's theme. See android.content.res.Resources.Theme#obtainStyledAttributes(AttributeSet, int[], int, int) for more information.

Retrieve styled attribute information in this Context's theme. See android.content.res.Resources.Theme#obtainStyledAttributes(AttributeSet, int[], int, int) for more information.

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#S, Registering the ComponentCallbacks to Context created via createWindowContext(int,android.os.Bundle) or createWindowContext(android.view.Display,int,android.os.Bundle) will receive ComponentCallbacks#onConfigurationChanged(Configuration) from Window Context rather than its base application. It is helpful if you want to handle UI components that associated with the Window Context when the Window Context has configuration changes.

Broadcast the given intent to all interested BroadcastReceivers, allowing an array of required permissions 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.

Remove a ComponentCallbacks object that was previously registered with registerComponentCallbacks(android.content.ComponentCallbacks).

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.

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.

You should implement this method to release any caches or other unnecessary resources you may be holding on to. The system will perform a garbage collection for you after returning from this method.

Preferably, you should implement ComponentCallbacks2#onTrimMemory from ComponentCallbacks2 to incrementally unload your resources based on various levels of memory demands. That API is available for API level 14 and higher, so you should only use this onLowMemory method as a fallback for older versions, which can be treated the same as ComponentCallbacks2#onTrimMemory with the android.content.ComponentCallbacks2#TRIM_MEMORY_COMPLETE level.