Mopub v 5.0.0 cause a lot of ANRs in Google Play dev console


#1

I have updated to mopub sdk 5.0.0 and found 40x increase in ANR number in Google Play dev console.

This is stacktrace:

at com.mopub.network.Networking.getRequestQueue (Networking.java:65)

  • waiting to lock <0x08a28be7> (a java.lang.Class<com.mopub.network.Networking>) held by thread 29
    at com.mopub.mobileads.AdViewController.b (AdViewController.java:506)
    at com.mopub.mobileads.AdViewController.a (AdViewController.java:274)
    at com.mopub.mobileads.AdViewController.l (AdViewController.java:252)
    at com.mopub.mobileads.AdViewController.loadAd (AdViewController.java:234)
    at com.mopub.mobileads.MoPubView.loadAd (MoPubView.java:104)
    at com.mopub.mobileads.MoPubInterstitial.a (MoPubInterstitial.java:138)
  • locked <0x0f802394> (a com.mopub.mobileads.MoPubInterstitial)
    at com.mopub.mobileads.MoPubInterstitial.a (MoPubInterstitial.java:98)
    at com.mopub.mobileads.MoPubInterstitial.load (MoPubInterstitial.java:259)
    at com.appodeal.ads.b.aa.a (unavailable)
    at com.appodeal.ads.b.aa.a (unavailable)
    at com.appodeal.ads.t$1.run (unavailable)
    at android.os.Handler.handleCallback (Handler.java:751)
    at android.os.Handler.dispatchMessage (Handler.java:95)
    at android.os.Looper.loop (Looper.java:154)
    at android.app.ActivityThread.main (ActivityThread.java:6349)
    at java.lang.reflect.Method.invoke! (Native method)
    at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run (ZygoteInit.java:893)
    at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:783)

#2

Hi!

This issue was also related to some publishers not following the correct steps to init the SDK.

Please make sure to only start requesting ads once the SDK has finished initializing.

Also, we just released SDK version 5.2. that provides a fix for this issue:

So we encourage you to update your version when possible.

Thanks!


#3

Great news! Thank you!


#4

Please provide a way to know why the SDK didn’t initialize on the SdkInitializationListener interface so we can retry initialization or handle the situation in some other way.

As of now we’re getting about 40% of sessions that never get the onInitializationFinished() callback and our impressions dropped dramatically after using “MoPub.initializeSdk” given you require it to request ads now.


#5

Hi!
Did you log this issue into support@mopub.com?
If that is the case, can you let us know Case number?
Many thanks!


#6

Hi, same problem here with sdk v5.3.0. In google play console i see a lot of ANR with this stacktrace:

“main” prio=5 tid=1 Blocked
| group=“main” sCount=1 dsCount=0 flags=1 obj=0x72764f60 self=0x729baa3a00
| sysTid=29234 nice=-10 cgrp=default sched=0/0 handle=0x7320f129a8
| state=S schedstat=( 549724479 36196359 1675 ) utm=41 stm=13 core=1 HZ=100
| stack=0x7fe61f9000-0x7fe61fb000 stackSize=8MB
| held mutexes=
at com.mopub.network.Networking.getRequestQueue (Networking.java:65)

  • waiting to lock <0x090c6ff3> (a java.lang.Class<com.mopub.network.Networking>) held by thread 12
    at com.mopub.nativeads.ServerPositioningSource.requestPositioningInternal (ServerPositioningSource.java:130)
    at com.mopub.nativeads.ServerPositioningSource.loadPositions (ServerPositioningSource.java:123)
    at com.mopub.nativeads.MoPubStreamAdPlacer.loadAds (MoPubStreamAdPlacer.java:243)
    at com.mopub.nativeads.MoPubStreamAdPlacer.loadAds (MoPubStreamAdPlacer.java:208)

Are you working on this issue?


#7

Hi!
It would be great if you could reach out to support@mopub.com and share with us all the details, like MoPub SDK, adapters version, networks SDK version and affected ad unit IDs.
Many thanks!