Background Operations Overview

This page describes the ways your app can perform tasks even while it isn't running in the foreground.

In many cases, an app needs to perform some operations while the user is not interacting with it. For example, a photo-album app might need to optimize its storage by compressing its photos; the app would not want to do that while the user is interacting with it, because that might degrade its performance. However, if an app does work while it isn't running in the foreground, there's the danger that it might interfere with the performance of other apps. For this reason, it's important for an app to choose the right way to perform its background work.

The Android platform offers a number of ways for an app to perform work while it's in the background:

Scheduled Jobs

Scheduled Jobs are usually your best choice. You define a job, and specify the circumstances when you want that job to run. For example, if you want to refresh your app's cached data, you might specify that you want your job to run when the device is connected to power (so you don't run down the device battery) and to an unmetered network (so you don't waste the user's data allotment). The system starts the job at the appropriate time, even if your app isn't currently running. The system also batches the jobs intelligently; for example, it does more work when the system is otherwise idle.

Services

Services are a good choice in certain situations. For example, if you have a music app, you would want to define a service to handle the audio playback. In a case like that, you would use a foreground service. Foreground services do work that is noticeable by the user, and they have to display a status bar icon.

Apps can also use background services, which are not noticed by the user. However, this can impair system performance if the user is working with another app at the time. For this reason, the system restricts apps that target API level 26 or higher from using background services unless the app itself is in the foreground. Apps can only use background services for a brief duration after the user finishes working with the app; for example, this is useful if your app is performing an operation, and you want to quickly finish things up when the user navigates away from your app. In most cases, if you want your app to do something silently while the user is not interacting with it, you're better off using a scheduled job.

Broadcasts

Your app can register to receive system broadcasts, and perform actions when it receives those broadcasts. However, there's a danger that if several apps all try to respond to the same broadcast, the system performance might be impaired. For this reason, the system restricts apps that target API level 26 or higher from registering to receive most general (implicit) broadcasts in their manifest, since registering in this way causes the app to be launched when the broadcast is sent. Once again, in cases like that, your best option is probably to use a scheduled job. Apps can still use their manifests to register for explicit broadcasts, since they are targeted at the app directly. Apps can also register for implicit broadcasts by calling registerReceiver() at runtime, since that way, they'll only receive the broadcast if they're already running when the broadcast is sent.

Alarms

Your app can use AlarmManager when you need to start your app up at a specific time. At the specified time, the device wakes up if necessary, and sends an intent to your app to wake it up. However, you should only use this approach when you need your app to do something at a particular time. If you just need to perform an operation at a specified interval, or under particular conditions, you should use a scheduled job.