Fixed
Status Update
Comments
ra...@google.com <ra...@google.com> #2
A couple of questions:
1. Have you saw crash in real device or only in simulators?
2. Do you use dynamic feature for language ID?
1. Have you saw crash in real device or only in simulators?
2. Do you use dynamic feature for language ID?
su...@google.com <su...@google.com> #3
Tested on Android 12 Emulator with custom executor, but cannot repro this issue.
Description
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