Background tasks overview

Apps frequently need to do more than one thing at a time. The Android APIs provide a lot of different ways to let you do this. Choosing the right option is very important; an option might be right for one situation but very wrong for another. Choosing the wrong APIs can hurt your app's performance or resource efficiency, which can drain the battery and degrade performance of the user's device as a whole. In some cases, choosing the wrong approach could prevent your app from being listed in the Play Store.

This document explains the different options available to you, and helps you choose the right one for your situation.

Terminology

Some important terms related to background tasks might be used in multiple, contradictory ways. For this reason, it's important to define our terms.

If an app is running in the background, the system puts a number of restrictions on it. (For example, in most cases, an app in the background can't launch foreground services.)

For the purposes of this document, we'll use the term "task" to mean an operation an app is doing outside its main workflow. To ensure alignment in understanding, we've put this into three main categories of types of tasks: asynchronous work, the task scheduling APIs, and foreground services.

Choose the right option

In most scenarios, you can figure out the right APIs to use for your task by figuring out the category (asynchronous work, the task scheduling APIs, or foreground services) the task falls under.

If you're still unsure, you can use the flow charts we provide which add more nuance to the decision. Each of these options is described in more detail later in this document.

There are two main scenarios to consider for background tasks:

These two scenarios have their own decision trees.

Asynchronous work

In many cases, an app just needs to do concurrent operations while it's running in the foreground. For example, an app might need to do a time-consuming calculation. If it did the calculation on the UI thread, the user wouldn't be able to interact with the app until the calculation finished; this might result in an ANR error. In a case like this, the app should use an asynchronous work option.

Common asynchronous work options include Kotlin coroutines and Java threads; you can find more information in the asynchronous work documentation. It's important to note that unlike the background task APIs, asynchronous work is not guaranteed to finish if the app stops being in a valid lifecycle stage (for example, if the app leaves the foreground).

Task scheduling APIs

The task scheduling APIs are a more flexible option when you need to do tasks that need to continue even if the user leaves the app. In most cases, the best option for running background tasks is to use WorkManager, though in some cases it may be appropriate to use the platform JobScheduler API.

WorkManager is a powerful library that lets you set up simple or complicated jobs as you need. You can use WorkManager to schedule tasks to run at specific times, or specify the conditions when the task should run. You can even set up chains of tasks, so each task runs in turn, passing its results to the next one. To understand all the options available, read through the WorkManager feature list.

Some of the most common scenarios for background tasks include:

  • Fetching data from server periodically
  • Fetching sensor data (for example, step counter data)
  • Getting periodic location data (you must be granted ACCESS_BACKGROUND_LOCATION permission on Android 10 or higher)
  • Uploading content based on a content trigger, such as photos created by the camera

Foreground services

Foreground services offer a powerful way to run tasks immediately that ought not to be interrupted. However, foreground services can potentially put a heavy load on the device, and sometimes they have privacy and security implications. For these reasons, the system puts a lot of restrictions on how and when apps can use foreground services. For example, a foreground service has to be noticeable to the user, and in most cases apps can't launch foreground services when the apps are in the background. For more information, see the foreground services documentation.

There are two methods for creating a foreground service. You can declare your own Service and specify that the service is a foreground service by calling Service.startForeground(). Alternatively, you can use WorkManager to create a foreground service, as discussed in support for long-running workers. However, it's important to know that a foreground service created by WorkManager has to obey all the same restrictions as any other foreground service. WorkManager just provides some convenience APIs to make it simpler to create a foreground service.

Alternative APIs

The system offers alternative APIs which are designed to perform better for more specific use cases. If an alternative API exists for your use case, we recommend using that API instead of a foreground service as it should help your app perform better. The foreground service types documentation notes when there's a good alternative API to use instead of a particular foreground service type.

Some of the most common scenarios for using alternative APIs are:

Tasks initiated by the user

Flowchart showing how to choose the appropriate API. This chart summarizes the material in the section 'Tasks initiated by the user'.
Figure 1: How to choose the right API for running a user-initiated background task.

If an app needs to perform background tasks, and the operation is initiated by the user while the app is visible, answer these questions to find the right approach.

Does the task need to continue running while the app is in the background?

If the task does not need to continue running while the app is in the background, you should use asynchronous work. There are a number of options for doing asynchronous work. The important thing to understand is that these options all stop operating if the app goes into the background. (They also stop if the app is shut down.) For example, a social media app might want to refresh its content feed, but it wouldn't need to finish the operation if the user left the screen.

Will there be a bad user experience if the task is deferred or interrupted?

It's important to consider whether the user experience would be harmed if a task is postponed or canceled. For example, if an app needs to update its assets, the user might not notice whether the operation happens right away, or in the middle of the night while the device is recharging. In cases like this, you should use the background work options.

Is it a short, critical task?

If the task cannot be delayed and it will complete quickly, you can use a foreground service with the type shortService. These services are easier to create than other foreground services, and don't require as many permissions. However, short services must complete within three minutes.

Is there an alternative API just for this purpose?

If the task is not invisible to the user, the correct solution may be to use a foreground service. These services run continuously once started, so they're a good choice when interrupting the task would have a bad user experience. For example, a workout-tracking app might use location sensors to let users record their jogging route on a map. You wouldn't want to do this with a background work option, because if the task got paused, the tracking would immediately stop. In a situation like this, a foreground service makes the most sense.

However, because foreground services can potentially use a lot of device resources, the system puts a lot of restrictions on when and how they can be used. In many cases, instead of using a foreground service, you can use an alternative API that handles the job for you with less trouble. For example, if your app needs to take an action when the user arrives at a certain location, your best option is to use the geofence API instead of tracking the user's location with a foreground service.

Tasks in response to an event

Flowchart showing how to choose the appropriate API. This chart summarizes the material in the section 'Tasks in response to an event'.
Figure 2: How to choose the right API for running an event-triggered background task.

Sometimes an app needs to do background work in response to a trigger, such as:

This might be an external trigger (like an FCM message), or it might be in response to an alarm set by the app itself. For example, a game might receive a FCM message telling it to update some assets.

If you can be sure that the task will finish in a few seconds, use asynchronous work to perform the task. The system will allow your app a few seconds to perform any such tasks, even if your app was in the background.

If the task will take longer than a few seconds, it may be appropriate to start a foreground service to handle the task. In fact, even if your app is currently in the background, it might be permitted to start a foreground service, if the task was triggered by the user and it falls into one of the approved exemptions from background start restrictions. For example, if an app receives a high-priority FCM message, the app is permitted to start a foreground service even if the app is in the background.

If the task will take longer than a few seconds, use the task scheduling APIs.