Modern apps can perform many of their tasks asynchronously, outside the direct flow of user interaction. Some examples of these asynchronous tasks are:
- Updating network resources.
- Downloading information.
- Updating background tasks.
- Scheduling system service calls.
Scheduling this work intelligently can improve your app’s performance,
along with aspects of system health such as battery life.
does this scheduling work for you.
There are several APIs that your app can use to schedule background work. Chief
among these options is
JobScheduler API allows you to specify robust
conditions for executing tasks,
along with centralized task scheduling across the device for optimal
JobScheduler also offers highly
scalable functionality: it is suitable for small tasks like clearing a cache,
and for large ones such as syncing a database to the cloud.
In addition to
JobScheduler, there are several other
facilities available to help your app schedule work. These include:
This page provides brief introductions to
and other APIs that can help your app schedule work to maximize app performance
and system health. To see an example of the APIs in use, navigate to the
JobScheduler Sample on GitHub.
Android Framework JobScheduler
JobScheduler is the Android framework API
for scheduling tasks or work. It first became available in Android 5.0 (API
level 21), and remains under active development. Notably, Android 7.0 (API
level 24) added the ability to trigger jobs based on
JobScheduler is implemented in the platform, which
allows it to collect information about jobs that need to run across all apps.
This information is used to schedule jobs to run at, or around, the same time.
Batching job execution in this fashion allows the device to enter and stay in
sleep states longer, preserving battery life.
JobScheduler by registering jobs, specifying
their requirements for network and timing. The system then gracefully schedules
the jobs to execute at the appropriate times. At the same time, it also defers
job execution as necessary to comply with
Doze and App Standby restrictions.
JobScheduler provides many methods to define
AlarmManager API is another option that the framework
provides for scheduling tasks. This API is useful in cases in which an app
needs to post a notification or set off an alarm at a very specific time.
You should only use this API for tasks that must execute at a specific time,
but don't require the other, more robust, execution conditions that
JobScheduler allows you to specify, such as device
idle and charging detect.
Firebase JobDispatcher is an open-source library that provides an API similar to
JobScheduler in the Android platform.
Firebase JobDispatcher serves as a
JobScheduler-compatibility layer for apps targeting
versions of Android lower than 5.0 (API level 21).
Firebase JobDispatcher supports the use of Google Play services as an
implementation for dispatching (running) jobs, but the library also allows you
to define and use other implementations: For example, you might decide to use
JobScheduler or write your own, custom code.
Because of this versatility, we recommend that you use this
Firebase JobDispatcher if your app targets a version of Android lower
than 5.0 (API level 21).
In addition to the APIs and libraries described above, there are also sync adapters and services that can enable your app, under specific conditions, to perform better and more robustly.
The framework continues to provide the
SyncAdapter class for
managing tasks that sync data between the device and a server. Sync adapters are
designed specifically for syncing data between a device and the cloud; you
should only use them for this type of task. Sync adapters are more complex to
implement than the libraries and APIs mentioned above, because they require at
least a fake
content provider implementation. For these reasons, you typically should
not create a sync adapter just to sync data to the cloud in the
background. Wherever possible, you should instead use
Firebase JobDispatcher, or
Network Manager .
The Services framework allows you to perform long-running operations in the background. We recommend foreground services for tasks, such as playing music, which need to stay resident for the user. Bound services also continue to be useful for various use cases: for example, when a service needs to run only when a user is viewing a fragment or activity.
You should avoid using started services that run perpetually or perform periodic work, since they continue to use device resources even when they aren't performing useful tasks. Instead, you should use other solutions that this page describes, and that provide native lifecycle management. Use started services only as a last resort. The Android platform may not support started services in the future.
Regardless of the solution you adopt, keep the following points in mind:
- Captive Internet Portals, VPNs, and proxies can pose Internet-connectivity detection problems. A library or API may think the Internet is available, but your service may not be accessible. Fail gracefully and reschedule as few of your tasks as possible.
- Depending on the conditions you assign for running a task, such as network availability, after the task is triggered, a change may occur so that those conditions are no longer met. In such a case, your operation may fail unexpectedly and repeatedly. For this reason, you should code your background task logic to notice when tasks are failing persistently, and perform exponential back-off to avoid inadvertently over-using resources.
- Remember to use exponential backoff when rescheduling any work,
especially when using
AlarmManager. If your app uses
JobScheduler, Firebase JobDispatcher, or sync adapters, exponential backoff is automatically used.