Data transfer background task options

Stay organized with collections Save and categorize content based on your preferences.

Many apps need to transfer data in the background. This guide outlines choices for reliable background data transfer, and provides examples for how to implement them.

Common background data transfer scenarios

This section describes some common situations where apps need to transfer data to or from the device, and helps you choose the right tool for your situation.

When selecting between APIs, you should consider the following questions:

• Is the transfer user-initiated?
• Is there an existing API that handles this transfer?
• Does the work need to run immediately?

If your scenario is not listed under common scenarios, consult the following sections to find the most appropriate API for your use case. It is likely that WorkManager will be appropriate.

Use the user-initiated data transfer job type

If your app needs to transfer data to a remote server, you may want to use a user-initiated data transfer job. This job type is appropriate if the following is true:

• The user began the data transfer
• You need to keep the user notified of the data transfer progress
• It is detrimental to user experience if the system interrupts the transfer

If any of these conditions is not satisfied, you should use WorkManager instead.

For example, a media app might let users download albums to play locally. If a user wants to download a playlist and play it right away, you might want to use the user-initiated data transfer job type. On the other hand, if the user wants the downloaded playlist to update periodically in the background without user initiation, WorkManager would be a better choice.

For more information, including how to create and run a user-initiated data transfer job, see the documentation on user-initiated data transfer jobs.

Use WorkManager for data transfer

In most cases, WorkManager is the best option when you need to schedule work. Keep in mind that you must design the tasks in such a way that they can be interrupted or deferred by the system. For more information, see the WorkManager documentation.

Here are a few things to keep in mind as you use WorkManager for background data transfer:

• If you need to run the work as soon as possible, you can schedule an expedited work request. This option is especially useful if you're scheduling the work in response to a broadcast, exact-alarm, or high-priority FCM message.
• If you need the work to run periodically, you can schedule periodic work. A periodic work request lets you specify roughly how often the work will run, but does not guarantee a specific time. That allows the system to schedule work requests from different apps to balance the demands on the device.
• You should define work constraints to specify the right circumstances to run your job. For example, if your app needs to download non-urgent resources, you might specify that the job should run while the device is charging and connected to an unmetered network. WorkManager can then run your job at a time that balances the load on the system.
• WorkManager is free to cancel and retry a job if necessary. For example, the user might turn off the device while a job is running; the system can then retry the job when the device is available again. Make sure you design and test your workflow to make sure the cancel-and-retry cycle works properly.
• Long running (foreground service) workers: WorkManager can support work that takes longer than 10 minutes by creating a foreground service for your app. This means that it is subject to the same restrictions as a foreground service and jobs, including restrictions on launching from the background and execution limits (jobs taking longer than 10 minutes will be rescheduled by the system).

JobScheduler is an alternative option for scheduling background work. In contrast to WorkManager, it requires you to do more configuration, but as an advantage, you have access to APIs that are not currently available in WorkManager, such as setPrefetch, setUserInitiated, and getPendingJobReasons.

Use a specific API

Use a specific API if one is available (like the companion device manager); otherwise, use a connectedDevice foreground service.

I want to transfer data from an Android mobile device to [device_type]. Is there a specific API available?

Use a more specific foreground service type

If WorkManager and JobScheduler are not appropriate for the particular background task, you may need to use a foreground service.

As always, when you're considering using a foreground service, you should consider whether there's a better alternative API tailored to your use case.

Use a short service foreground service

If your app needs to perform a short, critical task, a shortService foreground service may be the best option. Here are some situations where a shortService foreground service might be appropriate:

• The user initiates an action (like syncing data to the server) and you want to make sure the operation finishes even if the user immediately sends the app to the background.
• Saving in-memory information to persistent storage.
• Encrypting or decrypting information.

For full information, see the shortService documentation.

Use a connected device foreground service

If you need to transfer data to another local device, you may want to use a connectedDevice foreground service. Here are some common situations where you might need to do this:

• Communicating with a Bluetooth accessory, like headphones or a smart watch
• Transferring data to a locally connected device, by a USB connection, NFC, or a local internet connection

However, in these situations, you might be able to use the companion device manager to connect with the device instead of using a foreground service. As always, if a special-purpose API is available for your use case, that's usually a better choice than using a foreground service.

Use the new media processing foreground service

If you need to process media data, you can use the mediaProcessing foreground service. This service type is available if your app targets Android 15 or higher. For example, this service type is appropriate if your app needs to transcode media from one format to another for playback. For more information, see the media processing foreground service documentation.

Additional resources

• User-Initiated Data Transfer guidance
• Foreground services overview