IssueTracker

I'm not sure how to edit the description. But forgot to add that this will work when the app is in the foreground. It just doesn't work when you lock your device. I test this by moving the app to the background and then locking my device and checking the logs in Android Studio.

We also experienced issues with the new version 2.10.0. In our app a Job that is launched at start of the app is triggered and then immediatly cancelled because constraints are not meet anymore. I tried everything from putting it as a foreground job removing all constraints on the job but the behavior stay the same. I will rollback to 2.9.1 until it's fixed. You will find attached some logs of the WM in our app, take a look at job fec664f7-e40c-4df1-baca-3cbc7e1b1ff9.

This is happening for us as well when we are targeting 34. This is happening 100% background (not an user perceived ANR) but the count is too high. We are using workmanager 2.8.1 version. We have also checked if there is some third party dependencies running worker based on JobScheduler (not using workmanager). No dependencies is running JobScheduler directly. But this ANR is still happening in multiple mid range devices.

       main (native):tid=1 systid=26276 
#00 pc 0x99000 libc.so (syscall + 32) (BuildId: d1a98b526f2f94260a53c3055979a4f6)
#01 pc 0x232670 libart.so (art::ConditionVariable::WaitHoldingLocks + 140) (BuildId: 2452917c4ff69cbb6e75e5512260946b)
#02 pc 0x45a5e4 libart.so (artJniMethodEnd + 336) (BuildId: 2452917c4ff69cbb6e75e5512260946b)
#03 pc 0x5be67c libart.so (art_jni_method_end + 12) (BuildId: 2452917c4ff69cbb6e75e5512260946b)
       at android.os.BinderProxy.transactNative(Native method)
       at android.os.BinderProxy.transact(BinderProxy.java:685)
       at android.app.job.IJobCallback$Stub$Proxy.acknowledgeStartMessage(IJobCallback.java:434)
       at android.app.job.JobServiceEngine$JobHandler.ackStartMessage(JobServiceEngine.java:384)
       at android.app.job.JobServiceEngine$JobHandler.handleMessage(JobServiceEngine.java:196)
       at android.os.Handler.dispatchMessage(Handler.java:106)
       at android.os.Looper.loopOnce(Looper.java:257)
       at android.os.Looper.loop(Looper.java:368)
       at android.app.ActivityThread.main(ActivityThread.java:8839)
       at java.lang.reflect.Method.invoke(Native method)
       at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:572)
       at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1049)

We also encountered this issue after upgrading the target SDK to 34, with 99% of occurrences happening on OnePlus devices. Is there anyone who can help reach out to the OnePlus development team?

Additionally, aside from the issue mentioned in #5, I've noticed some ANR stacks that are related to Firebase. It’s possible that the #5 issue could also be related to Firebase.JobInfoSchedulerService

       main (runnable):tid=1 systid=31731 
       at androidx.camera.camera2.internal.Camera2CameraControlImpl$$InternalSyntheticLambda$9$8980faf06f5f4f7e61ac44ef69905a4e414b39b03b58a1268b7134d61a1ef654$0.<init>(Camera2CameraControlImpl.java)
       at com.google.android.datatransport.runtime.scheduling.jobscheduling.JobInfoSchedulerService.onStartJob(JobInfoSchedulerService.java:49)
       at android.app.job.JobService$1.onStartJob(JobService.java:106)
       at android.app.job.JobServiceEngine$JobHandler.handleMessage(JobServiceEngine.java:195)
       at android.os.Handler.dispatchMessage(Handler.java:106)
       at android.os.Looper.loopOnce(Looper.java:257)
       at android.os.Looper.loop(Looper.java:368)
       at android.app.ActivityThread.main(ActivityThread.java:8826)
       at java.lang.reflect.Method.invoke(Native method)
       at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:572)
       at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1049)

Firebase Uploader

          main (runnable):tid=1 systid=22285 
       at com.google.android.datatransport.runtime.scheduling.jobscheduling.Uploader.upload(Uploader.java:95)
       at com.google.android.datatransport.runtime.scheduling.jobscheduling.JobInfoSchedulerService.onStartJob(JobInfoSchedulerService.java:49)
       at android.app.job.JobService$1.onStartJob(JobService.java:106)
       at android.app.job.JobServiceEngine$JobHandler.handleMessage(JobServiceEngine.java:195)
       at android.os.Handler.dispatchMessage(Handler.java:106)
       at android.os.Looper.loopOnce(Looper.java:257)
       at android.os.Looper.loop(Looper.java:368)
       at android.app.ActivityThread.main(ActivityThread.java:8826)
       at java.lang.reflect.Method.invoke(Native method)
       at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:572)
       at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1049)

We are experiencing the same issue. It looks mostly like this:

          main (native):tid=1 systid=17000 
#00 pc 0x99ccc libc.so (syscall + 28) (BuildId: a87e89fc2c0a5753053f536add4d7ae1)
#01 pc 0x232670 libart.so (art::ConditionVariable::WaitHoldingLocks + 140) (BuildId: 2452917c4ff69cbb6e75e5512260946b)
#02 pc 0x45a5e4 libart.so (artJniMethodEnd + 336) (BuildId: 2452917c4ff69cbb6e75e5512260946b)
#03 pc 0x5be67c libart.so (art_jni_method_end + 12) (BuildId: 2452917c4ff69cbb6e75e5512260946b)
       at android.os.BinderProxy.transactNative(Native method)
       at android.os.BinderProxy.transact(BinderProxy.java:685)
       at android.app.job.IJobCallback$Stub$Proxy.acknowledgeStartMessage(IJobCallback.java:434)
       at android.app.job.JobServiceEngine$JobHandler.ackStartMessage(JobServiceEngine.java:384)
       at android.app.job.JobServiceEngine$JobHandler.handleMessage(JobServiceEngine.java:196)
       at android.os.Handler.dispatchMessage(Handler.java:106)
       at android.os.Looper.loopOnce(Looper.java:257)
       at android.os.Looper.loop(Looper.java:368)
       at android.app.ActivityThread.main(ActivityThread.java:8826)
       at java.lang.reflect.Method.invoke(Native method)
       at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:572)
       at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1049)

We are also using WorkManager, not JobScheduler directly.

Looking at our Crashlytics logs, the issue seems strongly correlated with lost network connectivity (we log network updates from ConnectivityManager on a background thread). A typical ANR report includes a very recent log for lost network connectivity.

Another equally (if not even more) strong correlation is the BillingClient losing connectivity at about the same time as the ANR happening. A typical ANR report includes a very recent log for the BillingClient being disconnected, with multiple reconnection attempts that succeed, each followed by a disconnect in the next moment.

We are also observing a significant increase in BG ANRs for OnePlus devices as mentioned in https://partnerissuetracker.corp.google.com/issues/353295716#comment6. This seems to have worsened significantly starting early August.

I shared more details on impacted devices / timing of crash spike on our existing email thread.

Can anyone repro the crash on Oppo/ OnePlus? We have heard accounts that this is happening on certain manufacturers more often. If we can identify a specific issue with a manufacturer, please create share a system trace and file a bug report. We currently do not have enough information to share with the manufacturers.

With respect to the ANR "No response to onStopJob" please note the following:

1. This is not a WorkManager bug, it is a behavior change in JobScheduler intended to surface potential scenarios where the app is doing work on the main thread that is blocking the system calling onStopJob callback. You can read more in https://developer.android.com/about/versions/14/behavior-changes-14#jobscheduler-reinforces-behavior however I realize that this description is not helpful if you're not doing blocking work in onStopJob which you should not be when using WorkManager, the library defaults onStopJob callback to be async. If the ANR is happening despite onStopJob being async, this means that there is other work that is blocking the main thread when the callback occurs. You will need to dive into the trace to understand what may be blocking the main thread.
2. There is currently no evidence that there is a potential Android OS bug, we haven't yet seen a consistent reason why developers are seeing the ANR. Rather, this ANR is adding additional visibility to issues already happening with jobscheduler, which prior to A14, would already drop the job silently if it could not complete onStartJob/onStopJob within the expected time limit of several seconds. The expected user impact of the A14 update is that this will increase cold starts if the ANR occurs while the app in the background. Data currently shows that this ANR rarely happens while the app is in the foreground.

Finally, how do you debug ANRs of this nature? Please check out our ANR guide on diagnosing ANRs. Some recommended approaches would be using ApplicationExitInfo and recording a system trace.

Again, if you have a specific issue you would like to discuss further, please repro the issue and attach the bug report and system trace.

Hi, Looks like Firebase Crashlytics dependency - com.google.android.datatransport/transport-runtime is using JobScheduler internally which is causing these ANRs. Crashlytics team acknowledged this and is working on fix in upcoming versions (19.2.0). https://github.com/firebase/firebase-android-sdk/issues/4345#issuecomment-2346270624