Skip to content

Most visited

Recently visited


Background Execution Limits

Whenever an app runs in the background, it consumes some of the device's limited resources, like RAM. This can result in an impaired user experience, especially if the user is using a resource-intensive app, such as playing a game or watching video. To improve the user experience, Android O imposes limitations on what apps can do while running in the background. This document describes the changes to the operating system, and how you can update your app to work well under the new limitations.


Many Android apps and services can be running simultaneously. For example, a user could be playing a game in one window while browsing the web in another window, and using a third app to play music. The more apps are running at once, the more load is placed on the system. If additional apps or services are running in the background, this places additional loads on the system, which could result in a poor user experience; for example, the music app might be suddenly shut down.

To lower the chance of these problems, Android O places limitations on what apps can do while users aren't directly interacting with them. If an app targets Android O, it is restricted in two ways:

In most cases, apps can work around these limitations by using JobScheduler jobs. This approach lets an app arrange to perform work when the app isn't actively running, but still gives the system the leeway to schedule these jobs in a way that doesn't affect the user experience.

Background Service Limitations

Services running in the background can consume device resources, potentially resulting in a worse user experience. To mitigate this problem, the system applies a number of limitations on services to apps that target Android O.

Note: These limitations apply only to apps that target Android O. Apps that target API level 25 or lower are not affected.

The system distinguishes between foreground and background apps. (The definition of background for purposes of service limitations is distinct from the definition used by memory management; an app might be in the background as pertains to memory management, but in the foreground as pertains to its ability to launch services.) An app is considered to be in the foreground if any of the following is true:

If none of those conditions is true, the app is considered to be in the background.

While an app is in the foreground, it can create and run both foreground and background services freely. When an app goes into the background, it has a window of several minutes in which it is still allowed to create and use services. At the end of that window, the app is considered to be idle. At this time, the system stops the app's background services, just as if the app had called the services' Service.stopSelf() methods.

Under certain circumstances, a background app is placed on a temporary whitelist for several minutes. While an app is on the whitelist, it can launch services without limitation, and its background services are permitted to run. An app is placed on the whitelist when it handles a task that's visible to the user, such as:

In many cases, your app can replace background services with JobScheduler jobs. For example, CoolPhotoApp needs to check whether the user has received shared photos from friends, even if the app isn't running in the foreground. Previously, the app used a background service which checked with the app's cloud storage. To migrate to Android O, the developer replaces the background service with a scheduled job, which is launched periodically, queries the server, then quits.

Prior to Android O, the usual way to create a foreground service was to create a background service, then promote that service to the foreground. With Android O, this approach fails if the app is not currently able to create background services. For this reason, Android O introduces the new method NotificationManager.startServiceInForeground(). Calling this method is the equivalent of calling startService() to create a service in the background, then immediately calling the service's startForeground() method to promote it to the foreground. However, since the new service is never in the background, it is not subject to the limitations on background services.

Broadcast Limitations

If an app registers to receive broadcasts, the app's receiver consumes resources every time the broadcast is sent. This can cause problems if too many apps register to receive broadcasts based on system events; a system event that triggers a broadcast can cause all of those apps to consume resources in rapid succession, impairing the user experience. To mitigate this problem, Android 7.0 (API level 25) placed limitations on broadcasts, as described in Background Optimization. The Android O makes these limitations more stringent.

Note: These limitations apply only to apps that target Android O. Apps that target API level 25 or lower are not affected.

In many cases, apps that previously registered for an implicit broadcast can get similar functionality by using a JobScheduler job. For example, a social photo app might need to perform cleanup on its data from time to time, and prefer to do this when the device is connected to a charger. Previously, the app registered a receiver for ACTION_POWER_CONNECTED in its manifest; when the app received that broadcast, it would check whether cleanup was necessary. To migrate to Android O, the app removes that receiver from its manifest. Instead, the app schedules a cleanup job that runs when the device is idle and charging.

Note: A number of implicit broadcasts are currently exempted from this limitation. Apps can continue to register receivers for these broadcasts in their manifests, no matter what API level the apps are targeting. For a list of the exempted broadcasts, see Implicit Broadcast Exceptions.

Migration Guide

These changes do not affect apps that target API level 25 or below. If your app targets Android O, you may need to update your app to comply with the new limitations.

Check to see how your app uses services. If your app relies on services that run in the background while your app is idle, you will need to replace them. Possible solutions include:

Review the broadcast receivers defined in your app's manifest. If your manifest declares a receiver for an implicit broadcast, you must replace it. Possible solutions include:

This site uses cookies to store your preferences for site-specific language and display options.


This class requires API level or higher

This doc is hidden because your selected API level for the documentation is . You can change the documentation API level with the selector above the left navigation.

For more information about specifying the API level your app requires, read Supporting Different Platform Versions.

Take a one-minute survey?
Help us improve Android tools and documentation.