Observing a huge number of ANRs, 100% Background as reported by crashlytics

[shabinder-singh]

[REQUIRED] Describe your environment

• Android Studio version: Build #AI-243.24978.46.2431.13208083 Android Studio Meerkat | 2024.3.1 Patch 1
• Firebase Component: Crashlytics & CloudMessagingReceiver
• Component version: "33.12.0" (FirebaseBOM)

[REQUIRED] Describe the problem

 main (native):tid=1 systid=1177 
#00 pc 0x3419c libc.so (syscall + 28)
#01 pc 0x130dd9 libart.so (art::ConditionVariable::WaitHoldingLocks(art::Thread*) + 88)
#02 pc 0x2a6097 libart.so (art::JNI<false>::IsSameObject(_JNIEnv*, _jobject*, _jobject*) + 402)
#03 pc 0x5df98 split_config.armeabi_v7a.apk!libpairipcore.so + 1458176
       at com.pairip.VMRunner.executeVM(Native method)
       at com.pairip.VMRunner.invoke(VMRunner.java:66)
       at com.google.android.gms.cloudmessaging.CloudMessagingReceiver.onReceive(CloudMessagingReceiver.java)
       at android.app.ActivityThread.handleReceiver(ActivityThread.java:4032)
       at android.app.ActivityThread.access$1400(ActivityThread.java:237)
       at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1924)
       at android.os.Handler.dispatchMessage(Handler.java:106)
       at android.os.Looper.loop(Looper.java:223)
       at android.app.ActivityThread.main(ActivityThread.java:7656)
       at java.lang.reflect.Method.invoke(Native method)
       at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:592)
       at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:947)
        

[lehcar09]

Hi @shabinder-singh, thank you for raising the issue. By any chance, were you able to reproduce the issue? Can you share an MCVE to help us investigate the issue? fa

Aside from that, does the issue occur on certain devices and/or android versions? Can you share the dependencies and the complete stack trace? Please ensure that there are no PII's from them. Thanks!

[shabinder-singh]

were you able to reproduce the issue? Can you share an MCVE to help us investigate the issue? fa

Unfortunately, I couldn't repro, hence unable to provide any concrete steps or a mcve, fa ?

Aside from that, does the issue occur on certain devices and/or android versions? Can you share the dependencies and the complete stack trace? Please ensure that there are no PII's from them.

Complete Trace:
com.viewlift.hoichoi_issue_06837043dda25f536e8fc4d4850314c9_ANR_session_68087FD9032600010D24A922353E0E0E_DNE_0_v2_stacktrace.txt

More Details:

[lehcar09]

Thank you for sharing that @shabinder-singh. Looking through the stack trace, the ANR is caused by CloudMessagingReceiver onReceive method that's blocking the main thread.

By any chance, can you share any code snippets that are related to Firebase Cloud Messaging? This will help us investigate this further. Thanks!

[shabinder-singh]

I think we only have clevertap configured, nothing custom or any service extending FirebaseMessagingService or CloudMessagingReceiver, especially in our TV builds.

[lehcar09]

Thank you for that info. Just to clarify though, you’re not using Firebase Cloud Messaging for your notifications? I’m not familiar with Clevertap. Could you share how you receive notifications? Thanks!

[shabinder-singh]

you’re not using Firebase Cloud Messaging for your notifications

No, We don't, the issue is from TV Builds, we don't have notifications in TV Builds.

Could you share how you receive notifications?

We don't, not in our code-logic anyhow in our TV Builds as I can see in the codebase.

Also, just a follow up, let's say there is some 3rd party library that maybe registering the notification, wouldn't that show up in the trace ?
I see com.pairip.VMRunner.executeVM (seemslike related), is this some internal google/firebase security thing going on which might block the main thread ?

[lehcar09]

From what I gather, if a third-party library is used, this might appear in the stack trace if an error occurs during its operation or how it is implemented.

The com.google.android.gms.cloudmessaging.CloudMessagingReceiver is a standard Android component for handling notifications. You mentioned that you’re using CleverTap and per checking they offer push notifications service via FCM. However, you’re not using FCM in your app, so I’m quite not sure why you would encounter this error.

Let me consult this with our engineers. I’ll get back to you once I hear back from them. Thanks!

[gsakakihara]

You indicated that you're using Firebase BoM version 33.12.0, which would include a recent version of the FCM SDK, but it sounds like you may not be including the SDK directly, but instead through CleverTap. Can you tell which version of the FCM SDK your app is using?

Also, is this a recent issue? Were there any changes that may have slowed down your app's startup time? An ANR like this can happen if your app takes too long to start up or if the main thread is blocked by another operation (though if this is only happening in the background, app startup may be more likely).

[google-oss-bot]

Hey @shabinder-singh. We need more information to resolve this issue but there hasn't been an update in 5 weekdays. I'm marking the issue as stale and if there are no new updates in the next 5 days I will close it automatically.

If you have more information that will help us get to the bottom of this, just add a comment!

[shabinder-singh]

You indicated that you're using Firebase BoM version 33.12.0, which would include a recent version of the FCM SDK, but it sounds like you may not be including the SDK directly, but instead through CleverTap. Can you tell which version of the FCM SDK your app is using?

I think theres a misunderstanding here, we use the mentioned BoM directly as a dependency, you can forget the mention of clevertap, as that doesn't imapct our tv builds which this anr relates to.

Also, is this a recent issue? Were there any changes that may have slowed down your app's startup time? An ANR like this can happen if your app takes too long to start up or if the main thread is blocked by another operation (though if this is only happening in the background, app startup may be more likely).

Not a recent issue, since in background, app startup is kept as light as possible only Firebase being the one instantiated, everything else is lazyloaded/ deferred until an activity is shown.