Component used: WorkManager
Version used: android.arch.work:work-runtime:1.0.0-alpha03
Devices/Android versions >= API 23

After updating to alpha03 we started receiving new ANR via Android Vitals:
Broadcast of Intent { act=android.intent.action.BOOT_COMPLETED flg=0x9000010 cmp=com.badoo.mobile/androidx.work.impl.background.systemalarm.RescheduleReceiver (has extras) }
androidx.work.impl.background.systemalarm.RescheduleReceiver

Stacktrace is not really telling, but I think I know the reason. In this version you added a new logic:
// This helps set up rescheduling of Jobs with JobScheduler. We are doing nothing
// for 10 seconds, to give ForceStopRunnable a chance to reschedule.
Handler handler = new Handler(Looper.getMainLooper());
final PendingResult pendingResult = goAsync();
handler.postDelayed(new Runnable() {
@Override
public void run() {
pendingResult.finish();
}
}, TimeUnit.SECONDS.toMillis(10));

But if you check the documentation for goAsync() :

<p>As a general rule, broadcast receivers are allowed to run for up to 10 seconds
* before they system will consider them non-responsive and ANR the app. Since these usually
* execute on the app's main thread, they are already bound by the ~5 second time limit
* of various operations that can happen there (not to mention just avoiding UI jank), so
* the receive limit is generally not of concern. However, once you use {@goAsync}, though
* able to be off the main thread, the broadcast execution limit still applies, and that
* includes the time spent between calling this method and ultimately
* {@link PendingResult#finish() PendingResult.finish()}.</p>

You are not allowed to do nothing for 10 seconds here. Please consider another approach for achieving compatibility with ForceStopRunnable.

Thanks