IssueTracker

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