Opções de tarefas em segundo plano da transferência de dados

Muitos apps precisam transferir dados em segundo plano. Esta página ajuda a encontrar a abordagem certa para suas necessidades.

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. DownloadManager manages the app's lifecycle, and takes care of retrying downloads after failures, device reboots, and connectivity changes. However, DownloadManager does not offer all the debugging and testing features that are available in WorkManager and JobScheduler.

Transferring data to or from a local device

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

Completing a short, critical task

Use a shortService foreground service.

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

Additional resources

For more information about this change to foreground services, see the following additional resources: