Android Mopub 5.4.0 ANR


MoPub SDK 5.4 generates ANR errors - fine in 5.3 without any other app code changes.
SDK initilization is done properly.

getRequestQueue() is called in two threads while it is being synchronized.

“main” prio=5 tid=1 Blocked
| group=“main” sCount=1 dsCount=0 obj=0x748008b0 self=0x7f93640a00
| sysTid=19536 nice=0 cgrp=default sched=0/0 handle=0x7f974e9a98
| state=S schedstat=( 867098798 46070312 654 ) utm=74 stm=12 core=1 HZ=100
| stack=0x7fe9660000-0x7fe9662000 stackSize=8MB
| held mutexes=
at (SourceFile:69)

  • waiting to lock <0x01a9b16f> (a java.lang.Class<>) held by thread 31
    at (SourceFile:255)
    at (SourceFile:154)
  • locked <0x042a8e7c> (a java.lang.Object)
    at com.mopub.mobileads.AdViewController.b (SourceFile:519)
    at com.mopub.mobileads.AdViewController.a (SourceFile:270)
    at com.mopub.mobileads.AdViewController.f (SourceFile:250)
    at com.mopub.mobileads.AdViewController.loadAd (SourceFile:232)
    at com.mopub.mobileads.MoPubView.loadAd (SourceFile:108)
    at com.xxxxxx.a.b.e.d (SourceFile:104)
    at com.xxxxxx.a.b.a.e (SourceFile:152)
    at com.xxxxxx.a.b.c.c (SourceFile:158)
    at com.xxxxxx.a.b.c.a (SourceFile:37)
    at com.xxxxxx.a.b$1.onInitializationFinished (SourceFile:47)
  • locked <0x0d70a305> (a java.util.ArrayList)
    at com.mopub.common.MoPub$ (SourceFile:322)
    at android.os.Handler.handleCallback (
    at android.os.Handler.dispatchMessage (
    at android.os.Looper.loop (
    at (
    at java.lang.reflect.Method.invoke! (Native method)
    at$ (
    at (

“AsyncTask #2” prio=5 tid=31 Waiting
| group=“main” sCount=1 dsCount=0 obj=0x12c1a160 self=0x7f6b325a00
| sysTid=19822 nice=10 cgrp=bg_non_interactive sched=0/0 handle=0x7f6a873450
| state=S schedstat=( 121453707 25078639 263 ) utm=9 stm=3 core=1 HZ=100
| stack=0x7f6a771000-0x7f6a773000 stackSize=1037KB
| held mutexes=
at java.lang.Object.wait! (Native method)

  • waiting on <0x0a87577b> (a java.lang.Object)
    at xk.b (SourceFile:173)
    at xk.d (SourceFile:186)
  • locked <0x0a87577b> (a java.lang.Object)
    at (SourceFile:204)
  • locked <0x0a87577b> (a java.lang.Object)
    at android.webkit.WebSettings.getDefaultUserAgent (
    at (SourceFile:149)
  • locked <0x01a9b16f> (a java.lang.Class<>)
    at (SourceFile:75)
  • locked <0x01a9b16f> (a java.lang.Class<>)
    at (SourceFile:110)
    at (SourceFile:148)
    at com.mopub.mobileads.MoPubConversionTracker.reportAppOpen (SourceFile:86)
    at com.mopub.common.privacy.PersonalInfoManager$5.onInitializationFinished (SourceFile:566)
    at com.mopub.common.privacy.MoPubIdentifier.a (SourceFile:221)
    at com.mopub.common.privacy.MoPubIdentifier.a (SourceFile:201)
    at com.mopub.common.privacy.MoPubIdentifier.a (SourceFile:188)
    at com.mopub.common.privacy.MoPubIdentifier$a.doInBackground (SourceFile:2105)
    at android.os.AsyncTask$ (
    at (
    at java.util.concurrent.ThreadPoolExecutor.runWorker (
    at java.util.concurrent.ThreadPoolExecutor$ (
    at (


Also facing this issue after updating mopub sdk to latest version 5.4.0. Its occurring at the time of ad load call


I have reverted to 5.3.0 and no more ANR errors - no other changes made. Simply revert from 5.4.0 to 5.3.0.



Thanks for reporting this.

While we released a fix in the 5.4.0 Android SDK version that helped mitigate the ANR (Application Not Responding), it seems there is another door causing ANRs in 5.4.

Our engineering team is currently investigating it and we hope to a fix soon.

If you any other questions, feel free to reach out to



me too.


I didn’t even notice ANRs on 5.3 but I am having many ANR report with MoPub 5.4


I’m having this issue too. Since updating to 5.4.1 I’ve seen a huge increase in ANR (Application not responding) issues in my app, 3% of sessions are affected by the app freezing :frowning:

How is the fix progressing?



@rmayayo, we believe we’ve identified a fix for that ANR, and are shipping that fix in the next SDK release. Hold tight!

In the meantime, publishers can add a call to Networking.getRequestQueue(Context) right before making the call to MoPub.initializeSdk([args]) to alleviate what we believe to be the issue.


We use 5.2.0 in Unity, and see the exact same ANRs. Oddly, we’ve been using the same SDK for the past 2 months, and we suddenly saw a surge in the ANRs over the Dec 29th weekend.
Can you share light on what conditions cause the ANR?


Thanks for letting us know! Our SDK engineering team has shared a detailed explanation of the cause here. Look for this fix in the upcoming SDK release!


So, is the recommendation to do both :

  1. Add delayed timer after initialization request is done

  2. add a call to Networking.getRequestQueue(Context)


@khambadkone, since you’re on Unity, there’s no way to call the Android method Networking.getRequestQueue(Context) from C#, so our recommendation would be to add the delay after initialization and before the ad request. This approach is not as foolproof so there might still be remaining ANR instances until the permanent fix in the upcoming MoPub Android SDK release.


We call getRequestQueue using unity’s AndroidJavaClass helper. Would that suffice?


That will do!


Here is a repository you can run to reproduce the issue consistently.


@chauduyphanvu We tried adding a 1 second delay between sdk initialization and the first ad load in production, and are still getting slaughtered by this ANR. From my own testing, I can sometimes reproduce even with a 2 second delay, but less often. The problem with increasing the delay is it reduces impressions. This bug means less money for mopub and the publisher.


Thanks for letting us know! There are two workarounds provided on this thread - did you try the other one? Publishes can add a call to Networking.getRequestQueue(Context) right before making the call to MoPub.initializeSdk([args]) to alleviate what we believe to be the issue.

A new SDK is scheduled to be released later this month that contains the official fix. Make sure to watch for that and update!


@chauduyphanvu For the sample project, adding Networking#getRequestQueue before the initializeSdk call prevents the ANR from being 100% replicable.

The wording earlier was that adding that call before initializeSdk would “alleviate” the bug, so I think for our next release we are leaning towards just downgrading to 5.3 or 5.2 (we were on 5.2 before).


Has there been any traction on publishing the new release? Our team is waiting on an update so we can stop using the outdated MoPub version.


We are waiting too