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.
| **Key Term:** An app is *running in the background* if none of its activities are visible to the user, and the app isn't running any [foreground services](https://developer.android.com/develop/background-work/services/fgs).

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](https://developer.android.com/develop/background-work/services/fgs/restrictions-bg-start#background-start-restriction-exemptions).)

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](https://developer.android.com/develop/background-work/background-tasks#asynchronous-work), the
[task scheduling APIs](https://developer.android.com/develop/background-work/background-tasks#background-work),
and [foreground services](https://developer.android.com/develop/background-work/background-tasks#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](https://developer.android.com/develop/background-work/background-tasks#asynchronous-work), the
[task scheduling APIs](https://developer.android.com/develop/background-work/background-tasks#background-work), or
[foreground services](https://developer.android.com/develop/background-work/background-tasks#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.
| **Note:** In most cases, your best option for running background tasks is to use WorkManager. However, there are a few situations where another option is better. This page will help you understand which solution fits your needs best.

There are two main scenarios to consider for background tasks:

- [The task initiated by the user while the app is visible](https://developer.android.com/develop/background-work/background-tasks#user-initiated)
- [The task is initiated in response to an event, either internal or
  external](https://developer.android.com/develop/background-work/background-tasks#event-driven)

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](https://developer.android.com/guide/background/asynchronous) 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](https://developer.android.com/guide/components/activities/process-lifecycle) (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](https://developer.android.com/guide/background/persistent),
though in some cases it may be appropriate to use the platform
[`JobScheduler`](https://developer.android.com/reference/android/app/job/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](https://developer.android.com/guide/background/persistent#workmanager-features).

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`](https://developer.android.com/training/location/receive-location-updates#request-background-location) permission on Android 10 or higher)
- Uploading content based on a content trigger, such as photos created by the camera

| **Note:** If a task is particularly urgent, you can mark it as *expedited* to instruct the system to prioritize the task to run as soon as possible. For more information, see [schedule expedited
| work](https://developer.android.com/guide/background/persistent/getting-started/define-work#expedited).

## 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](https://developer.android.com/develop/background-work/services/fgs).

There are two methods for creating a foreground service. You can declare your
own [`Service`](https://developer.android.com/reference/android/app/Service) and specify that the service is
a foreground service by calling
[`Service.startForeground()`](https://developer.android.com/reference/android/app/Service#startForeground(int,%20android.app.Notification,%20int)). Alternatively, you can
use WorkManager to create a foreground service, as discussed in [support for
long-running workers](https://developer.android.com/guide/background/persistent/how-to/long-running).
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](https://developer.android.com/develop/background-work/services/fgs/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:

- Using [user-initiated data
  transfers](https://developer.android.com/develop/background-work/background-tasks/uidt) to do large downloads or uploads, instead of creating a data sync foreground service
- Using the [companion device
  manager](https://developer.android.com/develop/connectivity/bluetooth/companion-device-pairing) for Bluetooth pairing and data transfer, instead of using a connected device foreground service
- Using [picture-in-picture mode](https://developer.android.com/develop/ui/views/picture-in-picture) to play video, instead of creating a media-playback foreground service

## 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'.](https://developer.android.com/static/images/develop/background-work/background-tasks/index/user-tasks-flowchart.svg) **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](https://developer.android.com/develop/background-work/background-tasks#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](https://developer.android.com/develop/background-work/background-tasks#background-work) options.
| **Note:** If a background work task takes longer than 10 minutes to complete, it's highly likely to be interrupted. You should try to find ways to break tasks like that into smaller sub-tasks. If you need to create a long-running task and you can't break it into subtasks, and you don't want the task to be interrupted, a [foreground service](https://developer.android.com/develop/background-work/background-tasks#foreground-services) may be the best option.

### Is it a short, critical task?

If the task cannot be delayed and it will complete quickly, you can use a
[foreground service](https://developer.android.com/develop/background-work/background-tasks#foreground-services) with the type
[`shortService`](https://developer.android.com/develop/background-work/services/fgs/service-types#short-service). 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.
| **Note:** Beginning with Android 12, most foreground services do not show notifications to the user until they've been running for 10 seconds.

### 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](https://developer.android.com/develop/background-work/background-tasks#foreground-services). 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](https://developer.android.com/develop/background-work/background-tasks#alternative-apis) 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](https://developer.android.com/develop/sensors-and-location/location/geofencing) 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'.](https://developer.android.com/static/images/develop/background-work/background-tasks/index/event-tasks-flowchart.svg) **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:

- [Broadcast messages](https://developer.android.com/guide/components/broadcasts)
- [Firebase Cloud Messaging (FCM) messages](https://firebase.google.com/docs/cloud-messaging)
- [Alarms](https://developer.android.com/training/scheduling) set by the app

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](https://developer.android.com/develop/background-work/background-tasks#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](https://developer.android.com/develop/background-work/services/fgs/restrictions-bg-start#background-start-restriction-exemptions). 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](https://developer.android.com/develop/background-work/background-tasks#background-work).