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