Author/Android Developer Relations Ben Weiss

The recently released WorkManager 2.5.0 at 📝 is more suitable for use in multi-process environments and provides several stability improvements.

Therefore, if you have an application that manages multiple processes and needs a robust way to manage background work (no initialization errors ⚠), this version is your first choice.

You need to make several changes to the code, so read on to learn more.

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

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"Copy the code

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

The Configuration using configuration. Provider is as follows.

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

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

When using work-Multiprocess, you need to use RemoteWorkManager instead of WorkManager to manage your work requests. RemoteWorkManager will always queue your work using the specified process. This ensures that you do not accidentally initialize the new WorkManager in the calling process. The in-process scheduler also runs in the same specified process.

advantage

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

Behavior change 🔀

Work coordination

Previously, when ActivityManager was unable to instantiate JobService to start a job, the job was silently deleted because of an underlying problem in the platform. WorkManager can now ensure that there is a backup scheduler job for each WorkRequest when an instance of the “application” is created by coordinating WorkRequest objects with jobs.

Limit internal database growth

We found that one of the reasons for app crashes was the lack of storage space on the device. This happens mostly on devices that already have very little storage space. However, the WorkManager is partly responsible for running out of storage space on devices when applications schedule a lot of work.

By default, the internal WorkManager database keeps records of completed jobs for seven days. Now, this period has been reduced to one day, greatly reducing the size of the database.

We have shortened the buffer duration so that you can control how long jobs should be retained with the help of the keepResultsForAtLeast() API.

New test API ✨

If you use ListenableFuture with WorkManager, Test work can be easier – TestListenableWorkerBuilder Kotlin extensions can now receive any class extension ListenableWorker, thus in the testing process to provide you with higher flexibility.

Problem fix 🐛

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

How can WorkManager be improved

Contribute content to WorkManager via GitHub 👩💻

WorkManager and several other Jetpack libraries accept content contributed via GitHub.

Alan Viverette has written a detailed blog post about the whole process.

Let us know if you have any problems at 📝

Most of the bugs fixed in version 2.5.0 were reported through the open problem tracker.

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

It’s time to go ahead and update the WorkManager libraries you use in your application.