Firebase IAM(In-App Messaging) Crash 💣 BUG

[pom1004]

Basic info:
Android Studio version: Android Studio Giraffe | 2022.3.1 Patch 4
Firebase Component: In-App Messaging
Component version: firebase-bom:32.3.1
Describe the problem
We created a new campaign and for some of the users, the application failed during the showing In-App Message.

Here is the crash from crashlytics:

Caused by android.view.WindowManager$BadTokenException
Unable to add window -- token null is not valid; is your activity running?
android.view.ViewRootImpl.setView (ViewRootImpl.java:1395)
android.view.WindowManagerGlobal.addView (WindowManagerGlobal.java:411)
android.view.WindowManagerImpl.addView (WindowManagerImpl.java:150)
com.google.firebase.inappmessaging.display.internal.FiamWindowManager.show (FiamWindowManager.java:67)
com.google.firebase.inappmessaging.display.FirebaseInAppMessagingDisplay$4$4.run (FirebaseInAppMessagingDisplay.java:416)
android.app.Activity.runOnUiThread (Activity.java:7620)
com.google.firebase.inappmessaging.display.FirebaseInAppMessagingDisplay$4.onSuccess (FirebaseInAppMessagingDisplay.java:412)
com.google.firebase.inappmessaging.display.internal.FiamImageLoader$Callback.onResourceReady (FiamImageLoader.java:157)
com.google.firebase.inappmessaging.display.internal.FiamImageLoader$Callback.onResourceReady (FiamImageLoader.java:135)
com.bumptech.glide.request.SingleRequest.onResourceReady (SingleRequest.java:631)
com.bumptech.glide.request.SingleRequest.onResourceReady (SingleRequest.java:575)
com.bumptech.glide.load.engine.EngineJob.callCallbackOnResourceReady (EngineJob.java:158)
com.bumptech.glide.load.engine.EngineJob$CallResourceReady.run (EngineJob.java:424)
android.os.Handler.handleCallback (Handler.java:958)
android.os.Handler.dispatchMessage (Handler.java:99)
android.os.Looper.loopOnce (Looper.java:205)
android.os.Looper.loop (Looper.java:294)
android.app.ActivityThread.main (ActivityThread.java:8177)
java.lang.reflect.Method.invoke (Method.java)
com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:552)
com.android.internal.os.ZygoteInit.main (ZygoteInit.java:971)

Steps to reproduce:
I can give you all devices which were affected, and maybe it can be helpful for you:
57% - Samsung

15% - Google

10% - Motorola

9% - Xiaom

9% - Other (3)
[4% - Sanmu - FIH Foxconn
3% - LGE
2% - TCT Mobile Limited (Alcatel)]

Relevant Code:
Nothing to share, it was implemented according to your documentation.

[google-oss-bot]

I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight.

[argzdev]

Hey @pom1004, thanks for reaching out. I noticed that in the stacktrace it looks like you're loading an image with a URL com.bumptech.glide.request.SingleRequest.onResourceReady. The crash may be due to a slow response of the URL to return the image. This can happen when the URL response itself is slow or if there is a massive influx of requests all at the same time. In this case, you should be able to get around this by uploading an actual image instead of using a URL. Let me know if this helps. Thanks!

[winsontan520]

@argzdev
I also encounter the same issue with this. For our case, the image is uploaded via the Firebase in-app messaging dashboard, the image url link is under domain "...firebasestorage.googleapis.com...." and folder FIAMImages which can be found under Firebase Storage.
Is that means the Firebase Storage services unable to handle the massive influx of requests all at the same time? Should I report to Firebase Storage support?

[argzdev]

Ah that is an interesting point, I was going to recommend using the image upload might help with the issue. But if the issue is still occurring even with this setup then there's definitely something wrong here. Let me bring this up to our engineering sync and see if we can get some feedback regarding this.

[argzdev]

Upon further investigation, this issue might be fixed with #5504. I'll reach out to our engineers and see if this is a plausible fix for this.

[winsontan520]

Upon further investigation, this issue might be fixed with #5504. I'll reach out to our engineers and see if this is a plausible fix for this.

@argzdev thanks for the follow up. Based on you experiences, do you know how long usually it would take for the fixes to be released? Because I need to plan for alternative solution for the business as it is impacting the users.

[argzdev]

We expect merged fixes to be in a release that is targeted for next week. However, in this case, the fix has yet to be validated and merged by our engineer. Our engineers haven't replied yet but let me see if we could it merged before the code freeze date.

[winsontan520]

@argzdev just to update to prevent ticket auto closed, did the fixes in the targeted release last week?