firebase-android-sdk
firebase-android-sdk copied to clipboard
ANR from crashlytics related to Firebase
[REQUIRED] Step 2: Describe your environment
Versions:
classpath 'com.google.firebase:firebase-crashlytics-gradle:2.9.2'
implementation 'com.google.firebase:firebase-crashlytics-ktx:18.3.2'
implementation 'com.google.firebase:firebase-analytics-ktx:21.2.0'
[REQUIRED] Step 3: Describe the problem
We facing this issue for almost 3 months now. But recently the ANR count is insanely high as you can see in the above From crashlytics:
main (timed waiting):tid=1 systid=19557
at jdk.internal.misc.Unsafe.park(Unsafe.java)
at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:234)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1079)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1369)
at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:278)
at com.google.firebase.crashlytics.internal.common.Utils.awaitEvenIfOnMainThread(Utils.java:22)
at com.google.firebase.crashlytics.internal.common.CrashlyticsController.handleUncaughtException(CrashlyticsController.java:94)
at com.google.firebase.crashlytics.internal.common.CrashlyticsController$1.onUncaughtException(CrashlyticsController.java:94)
at com.google.firebase.crashlytics.internal.common.CrashlyticsUncaughtExceptionHandler.uncaughtException(CrashlyticsUncaughtExceptionHandler.java:26)
at java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:1073)
at java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:1068)
at java.lang.Thread.dispatchUncaughtException(Thread.java:2306)
Relevant Code:
// TODO(you): code here to reproduce the problem
I found a few problems with this issue:
- I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight.
- This issue does not seem to follow the issue template. Make sure you provide all the required information.
Hi @graymind75, thanks for reporting. Are you using any code related to Crashlytics? Also were there any changes related to Firebase prior to this issue happening?
No, It's just initializing with FirebaseApp.initializeApp(applicationContext)
Thanks for the details, @graymind75. While we investigate this. Just to confirm, were you using a prior version of Crashlytics before experiencing this issue? If yes, could you share which version were you using?
Hi, Sorry I forgot to put the versions
before any problem:
classpath: 2.9.0
crashlytics: 18.2.11
analytics: 21.0.0
first ANR:
classpath: 2.9.1
crashlytics: 18.2.12
analytics: 21.1.0
and the devices ANR submitted from:
Hi, we are facing the same ANR being reported twice with different logs:
main (timed waiting):tid=1 systid=27674
at sun.misc.Unsafe.park(Unsafe.java)
at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:230)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1063)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1358)
at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:278)
at com.google.firebase.crashlytics.internal.common.Utils.awaitEvenIfOnMainThread(Utils.java)
at com.google.firebase.crashlytics.internal.common.CrashlyticsController.handleUncaughtException(CrashlyticsController.java)
at com.google.firebase.crashlytics.internal.Logger.canLog(Logger.java)
at com.facebook.internal.instrument.InstrumentUtility.isSDKRelatedException(InstrumentUtility.java)
at java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:1073)
at java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:1068)
at java.lang.Thread.dispatchUncaughtException(Thread.java:2203)
main (timed waiting):tid=1 systid=23250
at jdk.internal.misc.Unsafe.park(Unsafe.java)
at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:234)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1079)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1369)
at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:278)
at com.google.firebase.crashlytics.internal.common.Utils.awaitEvenIfOnMainThread(Utils.java:22)
at com.google.firebase.crashlytics.internal.common.CrashlyticsController.handleUncaughtException(CrashlyticsController.java:93)
at com.google.firebase.crashlytics.internal.common.CrashlyticsController$1.onUncaughtException(CrashlyticsController.java:93)
at com.google.firebase.crashlytics.internal.common.CrashlyticsUncaughtExceptionHandler.uncaughtException(CrashlyticsUncaughtExceptionHandler.java:25)
at com.facebook.internal.instrument.crashreport.CrashHandler.uncaughtException(CrashHandler.java:409)
at java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:1073)
at java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:1068)
at java.lang.Thread.dispatchUncaughtException(Thread.java:2306)
We use Crashlytics too and the versions are the ones that come with Firebase BOM 31.1.0
.
We are just upgrading to 31.1.1
but won't have data until the next release which will be at some point in January.
They are our top ANRs, here are the stats of the last 30 days:


Same occurred to us as well with below logs:
main (timed waiting):tid=1 systid=32460 at jdk.internal.misc.Unsafe.park(Unsafe.java) at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:234) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1079) at java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1369) at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:278) at com.google.firebase.crashlytics.internal.common.Utils.awaitEvenIfOnMainThread(Utils.java:124) at com.google.firebase.crashlytics.internal.common.CrashlyticsCore.checkForPreviousCrash(CrashlyticsCore.java:485) at com.google.firebase.crashlytics.internal.common.CrashlyticsCore.onPreExecute(CrashlyticsCore.java:184) at com.google.firebase.crashlytics.FirebaseCrashlytics.init(FirebaseCrashlytics.java:149) at com.google.firebase.crashlytics.CrashlyticsRegistrar.buildCrashlytics(CrashlyticsRegistrar.java:60) at com.google.firebase.crashlytics.CrashlyticsRegistrar.$r8$lambda$Pfd5XmDCFzNyAT9o9H6rDnTBQE4(CrashlyticsRegistrar.java) at com.google.firebase.crashlytics.CrashlyticsRegistrar$$InternalSyntheticLambda$3$ab347a8933944304e42539e3f0bc7a2eb5ded1d56c7a52feedae47ac52780cf7$0.create(CrashlyticsRegistrar.java:2) at com.google.firebase.tracing.ComponentMonitor.lambda$processRegistrar$0(ComponentMonitor.java:38) at com.google.firebase.tracing.ComponentMonitor.$r8$lambda$nUgWIWAyyZxi6mRt6KSZMmA5LxE(ComponentMonitor.java) at com.google.firebase.tracing.ComponentMonitor$$InternalSyntheticLambda$3$5d14153249ab9155b8414252ecf49149174a086fa7b21bebac19047e371b22f6$0.create(ComponentMonitor.java:4) at com.google.firebase.components.ComponentRuntime.lambda$discoverComponents$0(ComponentRuntime.java:140) at com.google.firebase.components.ComponentRuntime.$r8$lambda$4FqOW9eOQsvFYo-HpMfxCOnPQr0(ComponentRuntime.java) at com.google.firebase.components.ComponentRuntime$$InternalSyntheticLambda$2$784536aca87f12f75d3504e86fd606a2ca102f8312a2daf2c8c51b9b25617f63$0.get(ComponentRuntime.java:4) at com.google.firebase.components.Lazy.get(Lazy.java:53) at com.google.firebase.components.ComponentRuntime.doInitializeEagerComponents(ComponentRuntime.java:302) at com.google.firebase.components.ComponentRuntime.initializeEagerComponents(ComponentRuntime.java:292) at com.google.firebase.FirebaseApp.initializeAllApis(FirebaseApp.java:605) at com.google.firebase.FirebaseApp.initializeApp(FirebaseApp.java:307) at com.google.firebase.FirebaseApp.initializeApp(FirebaseApp.java:271) at com.google.firebase.FirebaseApp.initializeApp(FirebaseApp.java:256) at com.google.firebase.provider.FirebaseInitProvider.onCreate(FirebaseInitProvider.java:51) at android.content.ContentProvider.attachInfo(ContentProvider.java:2404) at android.content.ContentProvider.attachInfo(ContentProvider.java:2374) at com.google.firebase.provider.FirebaseInitProvider.attachInfo(FirebaseInitProvider.java:45) at android.app.ActivityThread.installProvider(ActivityThread.java:7459) at android.app.ActivityThread.installContentProviders(ActivityThread.java:6976) at android.app.ActivityThread.handleBindApplication(ActivityThread.java:6747) at android.app.ActivityThread.access$1500(ActivityThread.java:256) at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2091) at android.os.Handler.dispatchMessage(Handler.java:106) at android.os.Looper.loopOnce(Looper.java:201) at android.os.Looper.loop(Looper.java:288) at android.app.ActivityThread.main(ActivityThread.java:7870) at java.lang.reflect.Method.invoke(Method.java) at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:548) at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1003)
Firebase BOM Version - 31.0.2
Same occurred to us as well with below logs:
main (timed waiting):tid=1 systid=32460 at jdk.internal.misc.Unsafe.park(Unsafe.java) at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:234) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1079) at java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1369) at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:278) at com.google.firebase.crashlytics.internal.common.Utils.awaitEvenIfOnMainThread(Utils.java:124) at com.google.firebase.crashlytics.internal.common.CrashlyticsCore.checkForPreviousCrash(CrashlyticsCore.java:485) at com.google.firebase.crashlytics.internal.common.CrashlyticsCore.onPreExecute(CrashlyticsCore.java:184) at com.google.firebase.crashlytics.FirebaseCrashlytics.init(FirebaseCrashlytics.java:149) at com.google.firebase.crashlytics.CrashlyticsRegistrar.buildCrashlytics(CrashlyticsRegistrar.java:60) at com.google.firebase.crashlytics.CrashlyticsRegistrar.$r8$lambda$Pfd5XmDCFzNyAT9o9H6rDnTBQE4(CrashlyticsRegistrar.java) at com.google.firebase.crashlytics.CrashlyticsRegistrar$$InternalSyntheticLambda$3$ab347a8933944304e42539e3f0bc7a2eb5ded1d56c7a52feedae47ac52780cf7$0.create(CrashlyticsRegistrar.java:2) at com.google.firebase.tracing.ComponentMonitor.lambda$processRegistrar$0(ComponentMonitor.java:38) at com.google.firebase.tracing.ComponentMonitor.$r8$lambda$nUgWIWAyyZxi6mRt6KSZMmA5LxE(ComponentMonitor.java) at com.google.firebase.tracing.ComponentMonitor$$InternalSyntheticLambda$3$5d14153249ab9155b8414252ecf49149174a086fa7b21bebac19047e371b22f6$0.create(ComponentMonitor.java:4) at com.google.firebase.components.ComponentRuntime.lambda$discoverComponents$0(ComponentRuntime.java:140) at com.google.firebase.components.ComponentRuntime.$r8$lambda$4FqOW9eOQsvFYo-HpMfxCOnPQr0(ComponentRuntime.java) at com.google.firebase.components.ComponentRuntime$$InternalSyntheticLambda$2$784536aca87f12f75d3504e86fd606a2ca102f8312a2daf2c8c51b9b25617f63$0.get(ComponentRuntime.java:4) at com.google.firebase.components.Lazy.get(Lazy.java:53) at com.google.firebase.components.ComponentRuntime.doInitializeEagerComponents(ComponentRuntime.java:302) at com.google.firebase.components.ComponentRuntime.initializeEagerComponents(ComponentRuntime.java:292) at com.google.firebase.FirebaseApp.initializeAllApis(FirebaseApp.java:605) at com.google.firebase.FirebaseApp.initializeApp(FirebaseApp.java:307) at com.google.firebase.FirebaseApp.initializeApp(FirebaseApp.java:271) at com.google.firebase.FirebaseApp.initializeApp(FirebaseApp.java:256) at com.google.firebase.provider.FirebaseInitProvider.onCreate(FirebaseInitProvider.java:51) at android.content.ContentProvider.attachInfo(ContentProvider.java:2404) at android.content.ContentProvider.attachInfo(ContentProvider.java:2374) at com.google.firebase.provider.FirebaseInitProvider.attachInfo(FirebaseInitProvider.java:45) at android.app.ActivityThread.installProvider(ActivityThread.java:7459) at android.app.ActivityThread.installContentProviders(ActivityThread.java:6976) at android.app.ActivityThread.handleBindApplication(ActivityThread.java:6747) at android.app.ActivityThread.access$1500(ActivityThread.java:256) at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2091) at android.os.Handler.dispatchMessage(Handler.java:106) at android.os.Looper.loopOnce(Looper.java:201) at android.os.Looper.loop(Looper.java:288) at android.app.ActivityThread.main(ActivityThread.java:7870) at java.lang.reflect.Method.invoke(Method.java) at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:548) at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1003)
Firebase BOM Version - 31.0.2
Even after upgrading to BOM Version - 31.1.1 still the same.
Is there any update on this issue, we are also facing a large volume of ANRs.
We're seeing a similar issue with Firebase BOM 31.1.1
:
main (native):tid=1 systid=7347
#00 pc 0xa76bc libc.so (__rt_sigsuspend + 12)
#01 pc 0x631cc libc.so (sigsuspend + 56)
#02 pc 0x5c14a8 split_config.arm64_v8a.apk
#03 pc 0x89c [vdso]
#04 pc 0xa7cb8 libc.so (__epoll_pwait + 8)
#05 pc 0x17cc0 libutils.so (android::Looper::pollInner(int) + 192)
#06 pc 0x17b9c libutils.so (android::Looper::pollOnce(int, int*, int*, void**) + 116)
#07 pc 0x1687b0 libandroid_runtime.so (android::android_os_MessageQueue_nativePollOnce(_JNIEnv*, _jobject*, long, int) + 48)
at android.os.MessageQueue.nativePollOnce(MessageQueue.java)
at android.os.MessageQueue.next(MessageQueue.java:335)
at android.os.Looper.loopOnce(Looper.java:186)
at android.os.Looper.loop(Looper.java:313)
at android.app.ActivityThread.main(ActivityThread.java:8741)
at java.lang.reflect.Method.invoke(Method.java)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:571)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1067)
awaitEvenIfOnMainThread task continuation executor1 (waiting):tid=23 systid=7448
at jdk.internal.misc.Unsafe.park(Unsafe.java)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2081)
at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:433)
at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1063)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1123)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:637)
at com.google.firebase.crashlytics.internal.common.ExecutorUtils$1$1.onRun(ExecutorUtils.java:64)
at com.google.firebase.crashlytics.internal.common.BackgroundPriorityRunnable.run(BackgroundPriorityRunnable.java:27)
at java.lang.Thread.run(Thread.java:1012)
We are aware of this issue. We have some work planned that will reduce the load on the main thread, which should resolve this issue as well. I will keep this thread updated.
The issue started to surface roughly one year ago - surely you have the resources to do more than just "should resolve...".
This is a product used by millions world wide and it really should get a higher priority.
Hey @mrober, we appreciate the update.
While we await a resolution, are you able to provide any workarounds to prevent this from occurring in the meantime? For example, temporarily disabling Firebase Analytics/Crashlytics? Any information would be useful, as we currently have an ANR rate that is 4X the PlayStore quality bar.
Hey @mrober, we appreciate the update.
While we await a resolution, are you able to provide any workarounds to prevent this from occurring in the meantime? For example, temporarily disabling Firebase Analytics? Any information would be useful, as we currently have an ANR rate that is 4X the PlayStore quality bar.
is the problem with crashlytics or analytics?
Same for me too.
Stacktrace:
Thread-30087 (waiting):tid=272 systid=18410
at jdk.internal.misc.Unsafe.park(Native method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:885)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1039)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1345)
at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:232)
at com.google.firebase.crashlytics.internal.common.Utils.awaitEvenIfOnMainThread(Utils.java:128)
at com.google.firebase.crashlytics.internal.common.CrashlyticsController.handleUncaughtException(CrashlyticsController.java:229)
at com.google.firebase.crashlytics.internal.common.CrashlyticsController$1.onUncaughtException(CrashlyticsController.java:151)
at com.google.firebase.crashlytics.internal.common.CrashlyticsUncaughtExceptionHandler.uncaughtException(CrashlyticsUncaughtExceptionHandler.java:55)
at java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:1073)
at java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:1068)
at java.lang.Thread.dispatchUncaughtException(Thread.java:2306)
@mrober please answer, In case a permanent solution will take some time, Do you have any temporary solution ?
@themiswang to provide a temporary workaround while we migrate the Crashlytics SDK to firebase-android-executors.
FYI I've been using before any problem
versions on my comment above and faced no issue since.
Hi folks,
The Crashlytics uncaught exception handler is doing a bit too much work on the crashing thread. If that is the main thread, and has already been blocked for a few seconds, this can lead to an ANR. We are currently working on refactoring the SDK to avoid this, and the first fix will be included in the next release scheduled for March 23. In the meantime, you can manually add a timeout by doing this in your app, and below is an example:
public class CrashlyticsUncaughtExceptionHandler {
/** Must be run after Crashlytics has initialized. */
static void addTimeoutToCrashlyticsUncaughtExceptionHandler() {
Thread.UncaughtExceptionHandler crashlyticsHandler = Thread.getDefaultUncaughtExceptionHandler();
// If the Crashlytics uncaught exception handler timeout, the report
// will be uploaded on the next app launch in a background thread.
Thread.setDefaultUncaughtExceptionHandler(
(thread, ex) -> {
if (crashlyticsHandler != null) {
CountDownLatch latch = new CountDownLatch(1);
new Thread(
() -> {
crashlyticsHandler.uncaughtException(thread, ex);
latch.countDown();
})
.start();
com.google.firebase.crashlytics.internal.common.Utils.awaitUninterruptibly(latch, 2, TimeUnit.SECONDS);
}
});
}
}
Is it safe to just abort the Crashlytics uncaught exception handler when it's taking too long, because Crashlytics will send any pending reports on the next app launch. Thank you again for your patience!
@themiswang There is another stack trace different from UncaughtExceptionHandler
that you mentioned above.
awaitEvenIfOnMainThread task continuation executor1 (waiting):tid=23 systid=7448
at jdk.internal.misc.Unsafe.park(Unsafe.java)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2081)
at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:433)
at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1063)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1123)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:637)
at com.google.firebase.crashlytics.internal.common.ExecutorUtils$1$1.onRun(ExecutorUtils.java:64)
at com.google.firebase.crashlytics.internal.common.BackgroundPriorityRunnable.run(BackgroundPriorityRunnable.java:27)
at java.lang.Thread.run(Thread.java:1012)
Will this also be fixed?
The Crashlytics uncaught exception handler is doing a bit too much work on the crashing thread. If that is the main thread, and has already been blocked for a few seconds, this can lead to an ANR. We are currently working on refactoring the SDK to avoid this, and the first fix will be included in the next release scheduled for March 23. In the meantime, you can manually add a timeout by doing this in your app, and below is an example:
@themiswang Which version fixes this problem? I see that yesterday's release did not mention fixing this issue。
Hey @gongwen,
Sorry for the late replying, the fix is in Crashlytics 18.3.6
which announced on March 24th. With the change it will reduce the ANR and we are still working on SDK thread refactoring.
this error is coming in chinese devices
main (timed waiting):tid=1 systid=26556 at jdk.internal.misc.Unsafe.park(Native method) at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:234) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1079) at java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1369) at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:278) at com.android.internal.util.SyncResultReceiver.waitResult(SyncResultReceiver.java:55) at com.android.internal.util.SyncResultReceiver.getIntResult(SyncResultReceiver.java:68) at android.view.autofill.AutofillManager.tryAddServiceClientIfNeededLocked(AutofillManager.java:2009) at android.view.autofill.AutofillManager.notifyViewEnteredLocked(AutofillManager.java:1070) at android.view.autofill.AutofillManager.notifyViewEntered(AutofillManager.java:1054) at android.view.autofill.AutofillManager.notifyViewEntered(AutofillManager.java:1011) at android.view.View.notifyEnterOrExitForAutoFillIfNeeded(View.java:8226) at android.view.View.performClick(View.java:7512) at android.view.View.performClickInternal(View.java:7471) at android.view.View.access$3700(View.java:843) at android.view.View$PerformClick.run(View.java:29098) at android.os.Handler.handleCallback(Handler.java:938) at android.os.Handler.dispatchMessage(Handler.java:99) at android.os.Looper.loopOnce(Looper.java:233) at android.os.Looper.loop(Looper.java:344) at android.app.ActivityThread.main(ActivityThread.java:8248) at java.lang.reflect.Method.invoke(Native method) at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:589) at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1071)
main (native):tid=1 systid=26052
#00 pc 0xc8b38 libc.so (__epoll_pwait + 8) (BuildId: f24f65acf653c409ca4332aced817a71)
#01 pc 0x168d4 libutils.so (android::Looper::pollInner(int) + 180) (BuildId: 0c269320029489b4040b2307f9282499)
#02 pc 0x167b8 libutils.so (android::Looper::pollOnce(int, int*, int*, void**) + 112) (BuildId: 0c269320029489b4040b2307f9282499)
#03 pc 0x14d19c libandroid_runtime.so (android::android_os_MessageQueue_nativePollOnce(_JNIEnv*, _jobject*, long, int) + 44) (BuildId: c646cf84c51fc07b4bb81680ce4aed68)
#04 pc 0x43e154 libart.so (art_quick_generic_jni_trampoline + 148) (BuildId: 28c5aa8a2e8fc5df069f717d6e94f7fe)
#05 pc 0x20fc1f4 memfd:jit-cache (android.os.MessageQueue.next + 244)
#06 pc 0x204a76c memfd:jit-cache (android.os.Looper.loopOnce + 188)
#07 pc 0x209a9c libart.so (nterp_helper + 1948) (BuildId: 28c5aa8a2e8fc5df069f717d6e94f7fe)
#08 pc 0x47063a framework.jar (android.os.Looper.loop + 178)
#09 pc 0x209334 libart.so (nterp_helper + 52) (BuildId: 28c5aa8a2e8fc5df069f717d6e94f7fe)
#10 pc 0x1b4dd6 framework.jar (android.app.ActivityThread.main + 270)
#11 pc 0x434a00 libart.so (art_quick_invoke_static_stub + 576) (BuildId: 28c5aa8a2e8fc5df069f717d6e94f7fe)
#12 pc 0x467134 libart.so (_jobject* art::InvokeMethod<(art::PointerSize)8>(art::ScopedObjectAccessAlreadyRunnable const&, _jobject*, _jobject*, _jobject*, unsigned long) + 1960) (BuildId: 28c5aa8a2e8fc5df069f717d6e94f7fe)
#13 pc 0x466964 libart.so (art::Method_invoke(_JNIEnv*, _jobject*, _jobject*, _jobjectArray*) (.__uniq.165753521025965369065708152063621506277) + 48) (BuildId: 28c5aa8a2e8fc5df069f717d6e94f7fe)
#14 pc 0x43e154 libart.so (art_quick_generic_jni_trampoline + 148) (BuildId: 28c5aa8a2e8fc5df069f717d6e94f7fe)
#15 pc 0x20a2b0 libart.so (nterp_helper + 4016) (BuildId: 28c5aa8a2e8fc5df069f717d6e94f7fe)
#16 pc 0x2a944e framework.jar (com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run + 22)
#17 pc 0x20b074 libart.so (nterp_helper + 7540) (BuildId: 28c5aa8a2e8fc5df069f717d6e94f7fe)
#18 pc 0x2af672 framework.jar (com.android.internal.os.ZygoteInit.main + 714)
#19 pc 0x434a00 libart.so (art_quick_invoke_static_stub + 576) (BuildId: 28c5aa8a2e8fc5df069f717d6e94f7fe)
#20 pc 0x57df48 libart.so (art::JValue art::InvokeWithVarArgs<_jmethodID*>(art::ScopedObjectAccessAlreadyRunnable const&, _jobject*, _jmethodID*, std::__va_list) + 900) (BuildId: 28c5aa8a2e8fc5df069f717d6e94f7fe)
#21 pc 0x5f194c libart.so (art::JNI
Just bumping up this thread. Hi @graymind75, are you still experiencing ANRs with the latest version of Crashlytics? 18.3.7
?
@krunalpatel3 looking at your stacktrace, this seems to be separate issue. Could you file a new issue with details of our template? This is so that we can conduct an initial investigation regarding your issue. Thanks!
Hi @argzdev,
We're still experiencing ANRs on 18.3.6
, would bumping Crashlytics up to 18.3.7
make a difference in the mitigation of these ANRs?
Thanks!
Hi @jeffmon, did version 18.3.6
make any difference with your ANRs? It should help mitigate these ANRs.
Looking through the release notes for version 18.3.7
, there's no entry regarding fixes about ANRs so I don't think that would make a huge difference in your case. If the update on version 18.3.6
didn't help, then there might be an issue somewhere else.
@argzdev Hi, I didn't update the libraries and I'm using the below versions which were the last release without ANRs. I'm afraid I can't update the production without knowing that It's fixed.
classpath: 2.9.0
crashlytics: 18.2.11
analytics: 21.0.0
Hi @graymind75, the fix in 18.3.6
should help with the ANRs. As mentioned by themiswang.
Sorry for the late replying, the fix is in Crashlytics 18.3.6 which announced on March 24th. With the change it will reduce the ANR and we are still working on SDK thread refactoring.
If you're not comfortable in releasing for the updated version, you could do a rollout strategy to test these fixes to your production app.
Other than that, I don't see anyway to move this forward without first being able to verify that it is working or not.