Optimal Integration Flow for AdMob, UMP, and GDPR Compliance

[Moh]

Hello Google AdMob/Developer Community,

I’d like to confirm the recommended integration order for the Google Mobile Ads SDK and the User Messaging Platform (UMP) SDK to ensure full compliance with GDPR, Google Play Developer Program Policies, and Google’s EU User Consent Policy.

My current proposed sequence at app launch is:

1. Initialize the Google Mobile Ads SDK (e.g., MobileAds.initialize()),

   Note: At this stage, I do not request or load any ads yet.

2. Request and present the UMP consent form if required (e.g., ConsentInformation.requestConsentInfoUpdate() followed by loading and showing the consent form).

3. Request and display ads (e.g., AdView.loadAd(adRequestAds())) only after consent has been obtained or confirmed.

Questions:

• Is this the optimal and recommended flow for AdMob + UMP integration under GDPR?

• Specifically, is it correct (and policy‑compliant) to initialize the Mobile Ads SDK before showing the consent form, given that I do not request any ads until after consent is handled?

• Would this sequence fully satisfy GDPR, Google Play policies, and Google’s EU User Consent Policy?

Thank you very much for your guidance!

[Mobile Ads SDK Forum Advisor]

Hi,

Thank you for contacting the Mobile Ads SDK Support team.

Yes, your proposed integration flow is optimal and compliant with GDPR, Google Play Developer Program Policies, and Google’s EU User Consent Policy.

Questions: 

1. Is this the optimal and recommended flow for AdMob + UMP integration under GDPR?

Yes. Your proposed flow is the correct, recommended, and compliant integration method for using the Google Mobile Ads SDK with the User Messaging Platform (UMP) SDK under GDPR.

2. Specifically, is it correct (and policy‑compliant) to initialize the Mobile Ads SDK before showing the consent form, given that I do not request any ads until after consent is handled?

Yes. It is policy-compliant and allowed to initialize the Mobile Ads SDK before showing the UMP consent form, as long as no ads are requested or loaded before consent is obtained. Initialization (MobileAds.initialize()) can be called at app launch and does not process personal data.

3. Would this sequence fully satisfy GDPR, Google Play policies, and Google’s EU User Consent Policy?

Yes. The sequence fully satisfies GDPR, Google Play policies, and Google’s EU User Consent Policy.

I hope this helps! Let me know if you have any other questions.

Thanks,
 

Mobile Ads SDK Team

Feedback
How was our support today?

               
[2025-07-30 06:59:47Z GMT] This message is in relation to case "ref:!00D1U01174p.!500Ht01sxDN0:ref" (ADR-00321136)

[Moh]

Hi,

Thanks again for confirming the recommended AdMob + UMP integration flow.

I’m facing an issue where the UMP consent form sometimes triggers the following warning on the very first app launch after installation:

Consent form not shown: Activity is invalid.

When this happens, the app UI briefly flickers before the consent form appears. Although the form eventually shows and works, the flicker negatively impacts the first‑time user experience. On subsequent app launches, this issue does not occur.

Notes:

• I initialize Mobile Ads SDK at app launch (MobileAds.initialize()), but I do not load ads until after consent.

• I follow the recommended sequence: initialize SDK → run UMP consent flow → request ads.

• A retry mechanism ensures the consent flow starts once the SDK is ready.

Questions:

• Is this flickering on first launch expected behavior?

• If not, what is the best practice to avoid the “Activity is invalid” warning and ensure the consent form appears smoothly on the first run?

Thanks for your guidance!

[Mobile Ads SDK Forum Advisor]

Hi,

Thank you for getting back to us.

Please note that the Mobile Ads SDK should be fully initialized before triggering the UMP consent flow. The best way to optimize initialization is to call MobileAds.initialize() on a background thread, as described in the Get Started guide. 

No, this is not expected behavior. The UMP consent form should ideally appear smoothly without flickering on the first launch. The warning (Activity is invalid) usually means the consent flow is trying to run before the Activity context is properly ready to handle the consent form. 

If the issue still persists, kindly provide the below information via reply to author option for further investigation:

• app ID
• ad unit ID
• Mobile Ads SDK Version

Thanks,
 

Mobile Ads SDK Team

Feedback
How was our support today?

               

[2025-07-31 07:27:57Z GMT] This message is in relation to case "ref:!00D1U01174p.!500Ht01sxDN0:ref" (ADR-00321136)

[Alessandro Iurlano]

Hello. 

I was reading the Get Started Guide that was mentioned in this thread and I came upon something that seems to contradict the given answer:

Ads may be preloaded by the Google Mobile Ads SDK or mediation partner SDKs upon initialization. If you need to obtain consent from users in the European Economic Area (EEA), set any request-specific flags, such as setTagForChildDirectedTreatment() or setTagForUnderAgeOfConsent(), or otherwise take action before loading ads, ensure you do so before initializing the Google Mobile Ads SDK.

So my understanding is that the app should first gather consent, then initialize the SDK and finally load the ads.
Am I reading this wrong? Anyone could please clarify here?
Thanks

[Moh]

@Alessandro Iurlano

As I understand it, you should follow the following: 

1- RequestConfiguration requestConfiguration = MobileAds.getRequestConfiguration()....  // configureForKids();

2- MobileAds.initialize(getApplicationContext(), initializationStatus -> {
            Log.d(LOG_TAG, "Mobile Ads SDK initialized");
        });

3- User Messaging Platform (UMP)....

4- Request and load Ads

.....................

I present to you my current complete method:

I've attached the final method I've arrived at, and I'll start working on it from today until I review the instructions again. You can use the same files and method if you like.

You have a file:

1- MyApplication.java
2- AdsHelper.java

Use them as they are.
And in the MainActivity, you should call this way:

private final String TAG = "AdsHelper";
private AdsHelper adsHelper;

@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
ScreenOrientationHelper.setLandscapeOrientation(this);
setContentView(R.layout.activity_main);

adsHelper = new AdsHelper(this);
adsHelper.initAdsFlow();
//.... the rest of your code here
}

Then in

@Override
protected void onDestroy() {
super.onDestroy();

if (adsHelper != null) {
adsHelper.cleanup();
}
}

And also

@Override
protected void onResume() {
super.onResume();

adsHelper.initAdsOnResumeFlow(); // fallback to check if it worked in onCreate
}

..............

Please note that this is intended for children apps. If you want to use it for all ages, you can simply disable configureForKids(); found on line 30 of the MyApplication.java file.

Also in the AdsHelper.java file, modify .setTagForUnderAgeOfConsent(true)
Line 100 to  .setTagForUnderAgeOfConsent(false) .

Finally If you are displaying ads in the MainActivity, execute them inside the AdsHelper file.
Line 153 contains instructions.

Thank you.

[Mobile Ads SDK Forum Advisor]

Hi,

Yes you are correct, As per the get started Get Started, Consent must be handled before SDK initialization, otherwise preloaded ads may not respect user preferences or regulatory requirements.You can check the Google sample application for a reference implementation.

Thanks,
 

Mobile Ads SDK Team

Feedback
How was our support today?

               

[2025-08-01 22:49:19Z GMT] This message is in relation to case "ref:!00D1U01174p.!500Ht01sxDN0:ref" (ADR-00321136)

[Moh]

Hello gain,

I'm facing an issue that appeared after I updated the Google Mobile Ads SDK to version 36. My app's "Slow warm start rate" metric has significantly increased, which I believe is a result of this update.

The problem seems to be that when a user opens the app without an internet connection, the UMP (User Messaging Platform) and Mobile Ads SDKs attempt to initialize, but the process hangs and eventually times out. This causes a long delay before the main content is displayed.

To address this, I've implemented a network check at the start of my app. If the device is offline, I completely skip the initialization of both SDKs. This has made the app's startup much faster for users without a network connection.

I'd like to ask the community if this is the standard or recommended approach to address this specific "slow warm start" issue. Are there any other best practices for handling ad and consent initialization when a device is offline?

Thank you for your insights!

[Mobile Ads SDK Forum Advisor]

Hi,

Thank you for getting back to us.

Could you please confirm if the SDK is being initialized on a background thread?

It is important to note that initializing the SDK using the MobileAds.initialize() method is optional. Also, if you decided not to call this method, the SDK will be initialized automatically on your very first Ad request which might increase the Ads load time to a few milliseconds more. That said, you should be able to load Ads with or without implementing the MobileAds.initialize() as it is mainly for the purpose of initializing the SDK ahead to decrease load time on the first Ad request.

We do not recommend skipping SDK initialization, especially for consent handling, since consent needs to be collected before showing the ads.

If you skip the UMP SDK initialization when the device is offline, consent cannot be requested or collected.

Instead of skipping the initialization entirely, initialize the SDK later when the device goes online but must not show ads until proper consent has been collected

 

Thanks,
 

Mobile Ads SDK Team

Feedback
How was our support today?

               

[2025-09-02 20:31:51Z GMT] This message is in relation to case "ref:!00D1U01174p.!500Ht01sxDN0:ref" (ADR-00321136)

[Moh]

Hello  Mobile Ads SDK Team,

Thank you for your valuable guidance. I have implemented the changes you suggested, and the results are excellent.

I've moved the MobileAds.initialize() call to MyApplication.java, and it is now executed only if a network connection is detected. This has successfully resolved the "Slow warm start rate" issue, and the app now launches instantly for offline users.

However, I've observed one specific scenario where a slight delay still occurs: when the user's Wi-Fi or mobile data is turned off, but a VPN is active. In this case, my app detects a network connection (due to the VPN) and attempts to initialize the UMP SDK. This attempt eventually times out after approximately 10 seconds or a little less, leading to the log message: Consent info update failed: Error making request.

I was not able to test this on a poor internet connection, as my own connection is relatively fast.

This seems to be the intended behavior of the UMP SDK's timeout mechanism, and the app does eventually proceed. I believe this is an edge case, but I wanted to provide you with this detailed feedback as part of the debugging process.

Proposed Solution

To handle this edge case, I've implemented a more robust internet connectivity check. Instead of simply checking the network state, I now perform a direct connection test to a public URL with a short timeout. This ensures that the app only proceeds with the SDK initialization if a genuine internet connection is available.

Here is the code I used to achieve this within my AdsHelper.java file:

private void checkIfOnline() {
        new Thread(() -> {
            try {
                int timeoutMs = 2500; // 2.5 second timeout
                java.net.URL url = new java.net.URL("https://www.google.com");
                java.net.HttpURLConnection connection = (java.net.HttpURLConnection) url.openConnection();
                connection.setRequestProperty("User-Agent", "Android");
                connection.setRequestProperty("Connection", "close");
                connection.setConnectTimeout(timeoutMs);
                connection.connect();

                if (connection.getResponseCode() == 200) {
                    // Connection successful, proceed with consent flow
                    activity.runOnUiThread(() -> handleConsentAndInitAds());
                } else {
                    // Connection failed, notify callback
                    Log.e(TAG, "Real internet check failed with response code: " + connection.getResponseCode());
                    activity.runOnUiThread(() -> callback.onAdsFailed());
                }
            } catch (Exception e) {
                // Connection failed, notify callback
                Log.e(TAG, "Real internet check failed: " + e.getMessage());
                activity.runOnUiThread(() -> callback.onAdsFailed());
            }
        }).start();
    }

    public void initAdsFlow() {
        Log.d(TAG, "initAdsFlow called. Starting real internet check.");
        checkIfOnline();
    }

I believe this approach provides a more reliable user experience in various network conditions. Do you think this is a good solution, or would you recommend a different approach? 

Thank you again for your time and support.

[Mobile Ads SDK Forum Advisor]

Hi,

Yes, your approach to performing a connectivity check is correct. It’s recommended to use: connection.setRequestMethod("HEAD"); instead of GET because a HEAD request only checks for a valid response without downloading the full content, making it faster and more efficient for checking internet connectivity.

Thanks,
 

Mobile Ads SDK Team

Feedback
How was our support today?

               

[2025-09-03 08:37:26Z GMT] This message is in relation to case "ref:!00D1U01174p.!500Ht01sxDN0:ref" (ADR-00321136)

[Moh]

Dear Mobile Ads SDK Team ,

I'm writing to share feedback on the Mobile Ads SDK, specifically concerning performance and the UMP consent flow. I've encountered some challenges that I believe could be addressed by incorporating solutions directly into the library.

1. Startup Delays with Offline/VPN Connections: The MobileAds.initialize() call can cause significant app startup delays (over 10 seconds) when the device has an internet signal but no real connectivity. This happens because the library waits for a network timeout, which is a major concern for user experience and Play Console metrics.

   • Proposed Solution: Integrate a fast, internal network reachability check. If a real connection isn't detected within a short timeout, the SDK should fail gracefully and quickly, preventing long startup delays.

2. UMP Consent Flow in Multi-Activity Apps: When a user navigates to a new activity before the UMP form appears, the consent flow can be interrupted. The current callback-based approach is tied to a specific activity, which can lead to lost callbacks and requires complex, custom state management.

   • Proposed Solution: The SDK should manage the consent state centrally (e.g., via a singleton). This would allow any activity to simply query the current status and display the UMP form when needed, without risking a broken consent flow.

I hope you'll consider this feedback. Integrating these solutions into the SDK would greatly improve its robustness and developer experience.

I have kept this message brief, but I am happy to provide more details about our implementation and the issues we've debugged. Please feel free to ask any questions you have.

Thank you.