Many apps need to transfer data in the background. This page helps you find the right approach for your needs.
Migration use cases
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.
- Transferring data over the network
-
If the transfer was initiated by the user and you need to keep the user informed about the transfer's progress, use the user-initiated data transfer APIs. Otherwise, use WorkManager or an appropriate foreground service type.
If you need to schedule a download, you can also use
DownloadManager.DownloadManagermanages the app's lifecycle, and takes care of retrying downloads after failures, device reboots, and connectivity changes. However,DownloadManagerdoes not offer all the debugging and testing features that are available inWorkManagerandJobScheduler.- Transferring data to or from a local device
Use a specific API if one is available (like the companion device manager); otherwise, use a
connectedDeviceforeground service.- Transcoding media
- Completing a short, critical task
- Processing files (for example, transferring data to or from an SD card, resizing content, or encrypting or decrypting data)
If the task can complete in less than three minutes, use a
shortServiceforeground service. Otherwise, use WorkManager.
Use the user-initiated data transfer APIs
If your app needs to transfer data to a remote server, you may want to use the new user-initiated data transfer APIs. These APIs are 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 APIs. 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, see the documentation on migrating foreground services to user-initiated data transfer jobs.
Use WorkManager
In most cases, WorkManager is the best option when you need to schedule work. 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 notes that may be helpful as you migrate from a foreground service to WorkManager:
- 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.
Use a more specific foreground service type
If you can't switch to some other way of doing background work, you may still
need to use a foreground service. In that case, you should find an appropriate
service type to use instead of dataSync. Since your code is already using a
foreground service, this migration is straightforward; you just need to choose
the appropriate foreground service type, and make sure your app meets that
service's requirements.
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 new 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
For more information about this change to foreground services, see the following additional resources: