TooManyRequestsException due to AdMod SDK - Ad preloading (Alpha)
Gal
Excessive accumulation of ConnectivityManager registrations caused by com.google.android.ags.ads.nonagon.util.preload when using Ad Preloading (Alpha), leading to application crashes in production. Disabling Ad Preloading mitigates the issue.
Background:
This issue initially appeared to be related to WorkManager (reference: https://issuetracker.google.com/issues/231499040).
After collaboration with the WorkManager team and the application of their provided fix, we determined the root cause lies elsewhere.
Root Cause Investigation:
Upon analyzing heap dumps and monitoring ConnectivityManager registrations, we discovered that an unusually high number of instances of com.google.android.ags.ads.nonagon.util.preload are registering to ConnectivityManager very early in the app session.
We assume that without intervention, the number of these registrations would continue to grow over time, eventually causing a crash.
This behavior ultimately results in app crashes due to the following stack trace:
android.net.ConnectivityManager.convertServiceException (ConnectivityManager.java:3510)
android.net.ConnectivityManager.sendRequestForNetwork (ConnectivityManager.java:3714)
android.net.ConnectivityManager.registerDefaultNetworkCallback (ConnectivityManager.java:4115)
android.net.ConnectivityManager.registerDefaultNetworkCallback (ConnectivityManager.java:4092)
androidx.work.impl.utils.NetworkApi24.registerDefaultNetworkCallbackCompat (NetworkApi24.java:26)
androidx.work.impl.constraints.trackers.NetworkStateTracker24.startTracking (NetworkStateTracker.kt:165)
androidx.work.impl.constraints.trackers.ConstraintTracker.addListener (ConstraintTracker.java:52)
androidx.work.impl.constraints.controllers.BaseConstraintController$track$1.invokeSuspend (ContraintControllers.kt:62)
androidx.work.impl.constraints.controllers.BaseConstraintController$track$1.invoke (ContraintControllers.kt:13)
androidx.work.impl.constraints.controllers.BaseConstraintController$track$1.invoke (ContraintControllers.kt:13)
kotlinx.coroutines.flow.ChannelFlowBuilder.collectTo$suspendImpl (Builders.kt:316)
kotlinx.coroutines.flow.ChannelFlowBuilder.collectTo (Builders.kt:1)
kotlinx.coroutines.flow.CallbackFlowBuilder.collectTo (Builders.kt:330)
kotlinx.coroutines.flow.internal.ChannelFlow$collectToFun$1.invokeSuspend (ChannelFlow.kt:56)
kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith (ContinuationImpl.kt:33)
kotlinx.coroutines.DispatchedTask.run (DispatchedTask.kt:100)
androidx.work.impl.utils.SerialExecutorImpl$Task.run (SerialExecutorImpl.java:96)
java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1167)
java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:641)
java.lang.Thread.run (Thread.java:929)
This stack trace can be misleading because it references WorkManager; however, the underlying cause is the excessive number of ConnectivityManager registrations triggered by Ad Preloading logic.
Impact on Production:
This issue affects many real end-user devices.
Disabling Ad Preloading (Alpha) in our app resulted in an approximate 100% reduction in these crashes across production.
Request:
Please investigate the excessive ConnectivityManager registrations performed by the Ad Preloading (Alpha) logic.
Given that disabling Ad Preloading entirely mitigates the problem, we suspect an unintended memory or resource leak in the SDK implementation.
Mobile Ads SDK Forum Advisor
Hi,
Thank you for contacting the Mobile Ads SDK Support team.
Could you confirm whether the mentioned issue is reproducible in our sample project?
Kindly provide the below information privately for further investigation:
- Sample project reproducing the issue
- Steps to replicate the issue
- Affected devices
If the file(s) you are looking to share are less than 25mb in total you can attach them to this case on your next reply. If you are having trouble attaching your file to this case or if your file(s) are larger than 25mb, you can share your files via reply to author or by performing the following steps:
1. Navigate to
2. Fill out all fields, and attach your file(s).
3. Please reply back on this thread when you have uploaded your file(s). Please do not share this link.
Thanks,
 |
Mobile Ads SDK Team |
Feedback
How was our support today?
[2025-06-13 07:36:41Z GMT] This message is in relation to case "ref:!00D1U01174p.!500Ht01rfBNe:ref" (ADR-00314149)
Gal
Thank you for your response.
Unfortunately, the crash is not reproducible on our side under lab or controlled testing conditions. We've tested on multiple devices internally, but the issue never reproduced.
However, in production, this crash affects a significant number of real users. Once we disabled the Ad Preloading (Alpha) feature, the crash rate dropped to virtually zero.
The likely reason for the discrepancy is that our test environment does not replicate the real-world conditions users experience — such as memory pressure, multiple active apps, long app sessions, and varying network states. These conditions appear to be critical for triggering the issue, and they’re hard to simulate reliably in QA environments or with the sample app.
Therefore, we believe reproducing this in the sample project would not be meaningful, as our own builds — even on real devices — do not reproduce the crash under test conditions. The issue only arises under live usage scenarios.
We’ve analyzed system dumps, and they show a growing number of instances of com.google.android.ags.ads.nonagon.util.preload registered to ConnectivityManager. We believe this growth continues throughout the session until the app crashes.
There should typically be no more than one instance per library, but in this case, we observed many.
We would appreciate it if your team could investigate why the Ad Preloading (Alpha) implementation may be registering multiple instances unnecessarily, leading to a resource pressure over time.
Please let us know if there is any other information we can provide to help move this forward.
Mobile Ads SDK Forum Advisor
Hi,
Thank you for getting back to us.
Upon checking the logs, I can confirm that the logs don't contain anything related to Mobile Ads SDK. It is hard to validate the crash issue without having a com.google.android.gms.ads symbol.
I'm afraid that we'll need detailed debug information from a device where it's observed in order to actually make any progress in diagnosing this. The only way for us to investigate further is by creating a project where the issue is reproducible so that we can check with the wider team.
If the file(s) you are looking to share are less than 25mb in total you can attach them to this case on your next reply. If you are having trouble attaching your file to this case or if your file(s) are larger than 25mb, you can share your files via reply to author or by performing the following steps:
1. Navigate to
2. Fill out all fields, and attach your file(s).
3. Please reply back on this thread when you have uploaded your file(s). Please do not share this link.
Thanks,
|
Mobile Ads SDK Team |
Feedback
How was our support today?
[2025-06-16 06:10:46Z GMT] This message is in relation to case "ref:!00D1U01174p.!500Ht01rfBNe:ref" (ADR-00314149)
