Using WorkManager in multi-process applications

:memo: The recently released WorkManager 2.5.0 is more suitable for use in a multi-process environment and provides many stability improvements.

So if you have an app that manages multiple processes and needs a robust way to manage background work (no more initialization errors ⚠), this is the version for you.

You need to make a few changes to the code, read on to find out more.

At the end of this article, I'll also list some other behavior changes and additions to this version of the WorkManager library.

Introducing: work-multiprocess

This new multi-process artifact provides performance improvements by unifying job scheduling into a single process. To start using this artifact, add it to your application.

 Implementation "androidx.work:work-multiprocess:2.5.0"  

You can now select a specific process that the WorkManager uses to queue the WorkRequest and run its in-process scheduler.

• choose

  hhttps://developer.android.google.cn/topic/libraries/architecture/workmanager/advanced/custom-configuration

The configuration using Configuration.Provider is shown below.

 class MyApplication() : Application(), Configuration.Provider { override fun getWorkManagerConfiguration() =
 Configuration.Builder()
      .setProcessName( "com.example:remote" )
 .build()
 }

Note: You need to pass the fully qualified process name as the parameter to setProcessName , which consists of your app package name followed by a colon and the host's process name, for example com.example:remote .

When using work-multiprocess, you need to use RemoteWorkManager (not WorkManager) to manage your work requests. RemoteWorkManager will always queue your work using the specified process. This ensures that you do not accidentally initialize a new WorkManager in the calling process. The in-process scheduler will also run in the same process specified.

• RemoteWorkManager

  https://developer.android.google.cn/reference/androidx/work/multiprocess/RemoteWorkManager

Advantages

When you configure WorkManager as described above and schedule jobs using RemoteWorkManager, your work will be managed more quickly and reliably in multi-process applications. This is because SQLite contention is greatly reduced (because we no longer rely on file-based locking), and cross-process job coordination is no longer required because your application only runs a single WorkManager instance in the process you specify.

• Contention

  https://en.wikipedia.org/wiki/Resource_contention

Behavior change: twisted_rightwards_arrows:

Operation coordination

Previously, when ActivityManager failed to instantiate a JobService to start a job, the job would be silently dropped due to underlying issues in the platform. WorkManager now ensures that when creating an "app" instance by coordinating a WorkRequest object with a job, each WorkRequest will have a backing scheduler job.

Limiting internal database growth

We found that one of the reasons for the app crashing was low device storage. This mainly happened on devices with low storage. However, when the app was scheduling a lot of work, the low device storage was partially caused by WorkManager.

By default, the internal WorkManager database retains records of completed jobs for 7 days. This period has now been reduced to 1 day, significantly reducing the size of the database.

We've reduced the buffer duration so that you can control how long jobs should be kept with the keepResultsForAtLeast() API.

New testing API :sparkles:

If you use ListenableFuture with WorkManager, testing just got easier — the TestListenableWorkerBuilder Kotlin extension now takes any class extending ListenableWorker , giving you more flexibility during testing.

Bug fixes:

In addition to new features, this release also includes multiple bug fixes to improve the stability, reliability, and performance of WorkManager. You can view all changes and bug fixes in the release notes.

• Version Notes

  https://developer.android.google.cn/jetpack/androidx/releases/work#2.5.0

How to improve WorkManager

Contribute to WorkManager via GitHub :woman:‍:computer:

WorkManager, along with several other Jetpack libraries, accepts contributions via GitHub.

Alan Viverette wrote a thorough blog post about the entire process.

• Alan Viverette

  https://medium.com/@alan.viverette

• Detailed blog post

  https://medium.com/androiddevelopers/introducing-jetpack-on-github-c2c9f12e62a9

Please let us know if you encounter any problems :memo:

Most of the bugs fixed in the 2.5.0 release were reported via the public issue tracker.

• Public issue tracker

  https://issuetracker.google.com/issues?q=componentid:409906

The best way to create a fixable issue is to create an issue that we can reproduce . To help us reproduce the issue, we recommend that you use this WorkManager example or provide your sample code with the issue description.

• Creating a reproducible problem

  https://issuetracker.google.com/issues/new?component=409906

• WorkManager Example

  https://github.com/android/architecture-components-samples/tree/main/WorkManagerSample

It's time to take action and update the WorkManager library used in your application.