Question: What happens if I'm requesting an ad while MobileAds.initialize hasn't finished yet?

151 views
Skip to first unread message

Liran Barsisa

unread,
Feb 23, 2025, 3:22:06 AMFeb 23
to Google Mobile Ads SDK Developers
Scenario:
I have multiple ad-networks being used for mediation, each takes some time to initialize. Some are quick, some are sometimes slow.
Suppose "MobileAds.initialize" takes 8 seconds in the current session, and after 4 seconds I decide it's enough waiting, and I request a new ad (that has mappings to the ad networks), and I get the ad.

It says about "MobileAds.initialize" :
"If this method is not called, the first ad request automatically initializes the Google Mobile Ads SDK.
"

It's also recommended to use this function in the background:
https://ads-developers.googleblog.com/2024/07/reduce-anrs-when-implementing-mobile-ads.html

According to my test, the callback of "MobileAds.initialize" can sometimes be called after the ad was received, so this raises some questions...

What are the consequences of this scenario:
1. Would the ad-request use all the mappings of all ad-networks that were fully initialized so far, or only Admob? Or something else?
2. Would it still prevent ANR?
3. The ad-request avoid calling "MobileAds.initialize" as it was called already, right? 

Mobile Ads SDK Forum Advisor

unread,
Feb 24, 2025, 1:10:02 AMFeb 24
to lbl...@gmail.com, google-adm...@googlegroups.com

Hi,

Thank you for contacting Google Mobile Ads SDK Support Team.

Please find the below responses to your queries:



Would the ad-request use all the mappings of all ad-networks that were fully initialized so far, or only Admob? Or something else?

The ad-request would generally use only the ad networks that have been fully initialized and are ready to serve ads. So, if only AdMob was initialized, the ad-request would typically only use AdMob for serving ads unless you have a mediation setup in place. When you configure multiple ad networks for mediation, you have to specify what order to request these networks by setting their respective CPM



 Would it still prevent ANR?

 If MobileAds.initialize() was already called, and the ad-request is made after that, it should not cause an ANR, assuming the initialization was completed successfully. MobileAds.initialize() is typically an asynchronous process, meaning it won't block the main UI thread (which is the main cause of ANRs). To prevent ANR, Initializes the Google Mobile Ads SDK as early as possible after the app launches to reduce latency on the session's first ad request. Please utilize the optimize initialization parameter and also please refer to the Initialize the Google Mobile Ads SDK and call the initialize() method on a background thread within an Activity.

The ad-request avoids calling "MobileAds.initialize" as it was called already, right?
Yes, once MobileAds.initialize() is called and the initialization is complete (successfully or with error), there's no need to call it again. Calling it multiple times would not cause any issues in most cases, but it’s not necessary and redundant.

Thanks,

Google Logo Mobile Ads SDK Team

Feedback
How was our support today?

rating1    rating2    rating3    rating4    rating5
[2025-02-24 06:09:00Z GMT] This message is in relation to case "ref:!00D1U01174p.!5004Q02vH3OF:ref" (ADR-00289396



Liran Barsisa

unread,
Feb 24, 2025, 2:56:15 AMFeb 24
to Google Mobile Ads SDK Developers
About the ANR, you didn't answer about the scenario I've explained, meaning:
1. Call "MobileAds.initialize"
2. As "MobileAds.initialize" takes too much time, start requesting an ad (before "MobileAds.initialize" completes ), and get one.

Would this scenario still be optimized, preventing ANR , still?
That's why I wrote "still", because I already know about the normal scenario that is explained on the docs, that if I wait for "MobileAds.initialize" to finish and only then start requesting ads, then it's what's recommended to prevent ANR.

Mobile Ads SDK Forum Advisor

unread,
Feb 24, 2025, 8:42:26 AMFeb 24
to lbl...@gmail.com, google-adm...@googlegroups.com
Hi Liran,

We cannot recommend you to achieve it in this way, as we cannot guarantee the outcome as it may target AdMob default all the time to load the ads and not mediation. It is always best practice to initialize SDK before loading ads. We also noticed that you have raised concern related to callback of initialization for each of the adapters, for which we have already shared with the wider team.
 
Thanks,
 
Google Logo Mobile Ads SDK Team

Feedback
How was our support today?

rating1    rating2    rating3    rating4    rating5

[2025-02-24 13:41:27Z GMT] This message is in relation to case "ref:!00D1U01174p.!5004Q02vH3OF:ref" (ADR-00289396)



Liran Barsisa

unread,
Feb 24, 2025, 9:13:29 AMFeb 24
to Google Mobile Ads SDK Developers
1. But you already guaranteed the outcome just one comment above: You said that it will let all initialized ad-networks to be used at the moment of requesting a new ad:
"
The ad-request would generally use only the ad networks that have been fully initialized and are ready to serve ads. So, if only AdMob was initialized, the ad-request would typically only use AdMob for serving ads unless you have a mediation setup in place."
Now you are changing it to just Admob alone?

2. Also, as I've noticed, it can take some time for some ad-networks to initialize, which is then making my native ads not appear or appear much later.
The current average time for MobileAds.initialize because of the mediation changed to 17 seconds. Compare this to the time it takes on average for Admob alone to initialize which is 1.3 seconds...
For a considerable percentage of 46% of the cases, it takes more than 10 seconds... That's almost half of the times that the app starts...
That's terrible. Imagine if I had shown the user a splash screen to wait till it's all done...
So, you can see there is a benefit to have some timeout mechanism for me, as I'm losing a chance to show any kind of ad when it takes a long time.

3. You haven't answered my question for the third time already: Does this scenario help against ANR? 

Mobile Ads SDK Forum Advisor

unread,
Feb 24, 2025, 1:20:01 PMFeb 24
to lbl...@gmail.com, google-adm...@googlegroups.com
Hi Liran,

I will check with the wider team and get back to you once I have an update.

Thanks,
 
Google Logo Mobile Ads SDK Team

Feedback
How was our support today?

rating1    rating2    rating3    rating4    rating5

[2025-02-24 18:19:17Z GMT] This message is in relation to case "ref:!00D1U01174p.!5004Q02vH3OF:ref" (ADR-00289396)



Liran Barsisa

unread,
Feb 24, 2025, 1:37:57 PMFeb 24
to Google Mobile Ads SDK Developers
Thank you.
About the statistics, it's actually something weird that I find a bit contradicting, that the average is 17 seconds, yet each of the average of the ad-networks are below it.
Maybe it's because I started sampling per-ad-network later, but maybe it's something else...
Can I assume that as soon as all adapters are initialized, right away, I get the callback, and that "latency" is how much time the ad-network took to initialize?
I can see instances of full initialization that takes much longer than even 30 seconds.
When I got this issue reproduced in my case, it never reached more than 30 seconds, as the "description" part of the adapter's initialization result showed "timeout"...
Such weird behaviors, but measurements of full initialization is real, as it was done very easily.

Mobile Ads SDK Forum Advisor

unread,
Feb 24, 2025, 4:02:47 PMFeb 24
to lbl...@gmail.com, google-adm...@googlegroups.com
Hi Liran,

Thanks for sharing the use case. I've already raised this to the wider team for further investigation and to check the feasibility. Currently i don't have any update. I will keep you posted once i receive any update on this. Meanwhile, your patience is important.
 
Thanks,
 
Google Logo Mobile Ads SDK Team

Feedback
How was our support today?

rating1    rating2    rating3    rating4    rating5

[2025-02-24 21:01:53Z GMT] This message is in relation to case "ref:!00D1U01174p.!5004Q02vH3OF:ref" (ADR-00289396)



ELIANA GABRIEL

unread,
Feb 24, 2025, 6:30:29 PMFeb 24
to Mobile Ads SDK Forum Advisor, lbl...@gmail.com, Google Mobile Ads SDK Developers
But I don't really know how to set it up 

19621987

--

---
You received this message because you are subscribed to the Google Groups "Google Mobile Ads SDK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-admob-ads...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/google-admob-ads-sdk/ypnO3000000000000000000000000000000000000000000000SS6BR100sn2oE8ouSAW-JoowpOwh8g%40sfdc.net.
Message has been deleted

Liran Barsisa

unread,
Mar 13, 2025, 6:37:04 PMMar 13
to Google Mobile Ads SDK Developers
I've made Crashlytics to report me about this case, so that if it got a native/banner ad before initialization finishes, and it's not from Admob network, it will notify me about it.
I've gotten recently a report that Vungle/Liftoff got me a native ad before full initializations of all ad networks.
I don't know how much before. Maybe right before, but still , if that's the case, it should be possible to add proper API here.
In any case, please make it better, so that the mediation will be used and use all the adapters that were initialized so far.
There's no reason that an adapter that takes a very long time will punish the others that finished quickly, and there is no reason for me to wait for it either as it might be too late because till then the user might just leave the app.

Maybe there are more things that occur because of it.
Anyway, please support letting me just use what was initialized so far after some time...

Mobile Ads SDK Forum Advisor

unread,
Mar 14, 2025, 1:33:05 AMMar 14
to lbl...@gmail.com, google-adm...@googlegroups.com

Hi Liran,

I will check with the wider team and will reach out to you once we have an update on this. Meanwhile, your patience is highly appreciated.


Thanks,
 
Google Logo Mobile Ads SDK Team

Feedback
How was our support today?

rating1    rating2    rating3    rating4    rating5

[2025-03-14 05:31:44Z GMT] This message is in relation to case "ref:!00D1U01174p.!5004Q02vH3OF:ref" (ADR-00289396)



Reply all
Reply to author
Forward
0 new messages