Request: offer to query for the consent information (requestConsentInfoUpdate) using a generic Context and not just Activity

[Liran Barsisa]

Such a function doesn't use UI at all. It's just a query that uses the Internet.

It shouldn't need an Activity. 
Please offer to use just Context for it.

This can help in case the app starts in the background, including on boot, and thus we could initialize the Admob SDK much sooner, before anything is even shown to the user.

https://developers.google.com/admob/android/privacy#get_the_users_consent_information

https://developers.google.com/admob/android/reference/privacy/com/google/android/ump/ConsentInformation#requestConsentInfoUpdate(android.app.Activity,com.google.android.ump.ConsentRequestParameters,com.google.android.ump.ConsentInformation.OnConsentInfoUpdateSuccessListener,com.google.android.ump.ConsentInformation.OnConsentInfoUpdateFailureListener)

Also, please offer a reliable way to check the cached value of it to avoid checking when it's expired, because it says this: "

Warning: Using other ways of checking consent status, such as the cache on your app or a previously saved consent string, can lead to a TCF 3.3 error if consent is expired.

"

[Mobile Ads SDK Forum Advisor]

Hi,

Thank you for contacting the Mobile Ads SDK support team.

Below are the insights regarding your suggestions:
1.Activity param in request is used to collect screen cut-outs. This is crucial for displaying the consent form properly, as different devices may have various screen cutouts, such as notches, cameras, etc. Therefore, this parameter is an important one that cannot be ignored. You can find all ConsentInformation related methods and used parameters here.

2.If you use Google consent management solutions and the UMP SDK in your app, confirm that the UMP SDK has been correctly implemented and requestConsentInfoUpdate is being called at app start every time. This method checks whether consent is needed, and after it expires, it will automatically set ConsentStatus to "Required" and trigger the consent form to be shown again. I would recommend you to refer this.
Also As stated here: Using other ways of checking consent status, such as the cache on your app or a previously saved consent string, can lead to a TCF 3.3 error if consent is expired.

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

Thanks,
 

Mobile Ads SDK Team

Feedback
How was our support today?

               
[2025-03-28 22:45:07Z GMT] This message is in relation to case "ref:!00D1U01174p.!5004Q02vHDWE:ref" (ADR-00297237)

[Liran Barsisa]

1. That's irrelevant, because a dialog doesn't need this kind of information and should always be protected from the display cut-outs anyway, especially if you change the API to start the dialog in a new Activity, as it should be (like when we request a permission), instead of having a callback inside our own Activity which can be destroyed easily by configuration change.

The UI of the consent shouldn't be in the display cutouts. You can find it later when it's time to be shown.

Your link doesn't explain anything about why you need it there. 

The query isn't for UI. It's for consent information, meaning if it's GDPR/CCPA, and only later we show the dialog. That's the wrong step that you are talking about.

Even if it's not a dialog, you can have a layout that's protected against display cutouts, using fitsSystemWindows:

https://developer.android.com/reference/android/view/View#attr_android:fitsSystemWindows

So, still no technical reasons for it.

You can also change the API of Android to fit your needs of finding display cutouts. Now it's the best time, as there is Android 16 coming...

Here, created this request: https://issuetracker.google.com/issues/407024464

2. As I've explained, you can't call it "at app start every time", because apps sometimes start in the background, such as on boot, so there isn't an Activity yet.

3. As I've explained, I requested a way to use the cached result reliably and I even showed it in a quote. Offer a way to use the cache for as long as it's not expired. 

[Liran Barsisa]

Also, a scenario that proves you that even if it's required to get this information so early, it's still incorrect:
Suppose I have a device that can change its display cuts between Activities.

For example, a foldable phone. On one Activity it will use this function of fetching the consent information, then I fold/unfold, and the display cuts change, and then in a new Activity the app would show the dialog.

So you can see how bad this API design is. 
You not only get the UI information for an API that doesn't handle UI, but you also can get the wrong UI information.

The correct way to do it is to handle the UI in a dynamic way, when the time comes to show the UI. 

For all other functions, there is no reason to require Activity and they should be fine with using Context or nothing at all.

That's the same as for permissions: query about the status of the permission can be done without Activity, and requesting the permission can be done with Activity just because it uses a flow that works like startActivityForResult.

Here it should be the same: No need to work inside the Activity of ours. Should be in your own Activity, separate and protected from others, removing the possibility of memory leak and weird behaviors.

[Liran Barsisa]

Created a new request for display cut because whoever checks the issue tracker can't understand that the request isn't about Admob, but about Android instead:
https://issuetracker.google.com/issues/407116789

[Mobile Ads SDK Forum Advisor]

Hi Liran,

Thank you for providing more context on the request.

I will check with our team regarding a request to handle the UI in a dynamic way and one of my team members will reach out to you once we have an update on this. Meanwhile, your patience is highly appreciated.

Thanks,
 

Mobile Ads SDK Team

Feedback
How was our support today?

               

[2025-04-01 08:55:40Z GMT] This message is in relation to case "ref:!00D1U01174p.!5004Q02vHDWE:ref" (ADR-00297237)

[Liran Barsisa]

I was told by Google that you can already get the display cut without Activity, so even if you really need it for some reason for UMP, you can get it without having Activity as a parameter:

https://issuetracker.google.com/issues/407024464#comment6

Here, given a generic Context, you can get the display cutout from API 30:

inline fun <reified T : Any> Context.getSystemServiceCompat(): T =
ContextCompat.getSystemService(applicationContext, T::class.java)!!

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.R) {
   val windowManager: WindowManager = getSystemServiceCompat()
   val displayCutout = windowManager.currentWindowMetrics.getWindowInsets().displayCutout
   Log.d("AppLog", "displayCutout:$displayCutout")
} 

You guys should communicate more between one another.

Also, the display cutout shouldn't be an issue for just checking the status of the consent, if it's needed or not. Later you can prepare it better when we request it, in a new Activity/DialogFragment of your own. It shouldn't depend on our Activity which can change.

[Mobile Ads SDK Forum Advisor]

Hi,

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,
 

Mobile Ads SDK Team

Feedback
How was our support today?

               

[2025-04-07 14:50:01Z GMT] This message is in relation to case "ref:!00D1U01174p.!5004Q02vHDWE:ref" (ADR-00297237)

[Mobile Ads SDK Forum Advisor]

Hi Liran,

Please note that this is an intended behavior, The requestConsentInfoUpdate() method requires an Activity because it needs access to display-related information specific to the Activity that will eventually be used to show the consent form. This display data, such as display cutouts, is sent to the backend to ensure the proper form metadata can be provided.

Thanks,
 

Mobile Ads SDK Team

Feedback
How was our support today?

               

[2025-05-16 08:47:56Z GMT] This message is in relation to case "ref:!00D1U01174p.!5004Q02vHDWE:ref" (ADR-00297237)

[Liran Barsisa]

Hi,
Please read the comments above. I already explained that what you wrote doesn't make sense and shouldn't work this way from the first place.

I will try again to explain, as you've skipped everything we've discussed so far. Please read it this time:

1. Requesting information about consent shouldn't require anything related to UI. For UI you should handle the exact moment there is a need to show the UI.
The reason is that the query with the server requires time in the background, and during this time the Activity might be gone anyway and we would have a different one with different configuration.

2. UI should be handled in a dynamic way and when it's time to show it. Not managed by the server, let alone a long time before showing the UI. Remember that Android supports to change the configuration in various ways, such as orientation change and even light-vs-dark theme.
Yet here it's actually a dialog. Read how to handle screens sizes on Android:
https://developer.android.com/develop/ui/views/layout/responsive-adaptive-design-with-views

3. You should just use an Activity of your own for the UI, full screen always. Use something like startActivityForResult to reach it, so that we won't need to do it on our own Activity, with a workaround to lock the orientation because your API doesn't handle configuration change correctly at all.
Another approach is to use DialogFragment, but as the UI already has so much content and can scroll a lot, it's better to have it in a normal Activity, full screen, all to yourself.

4. The information about display-cut doesn't need Activity.
You don't need Activity for information about the GDPR status and not for the display-cuts.
Here's how you get the display-cuts information, for example:

inline fun <reified T : Any> Context.getSystemServiceCompat(): T =
ContextCompat.getSystemService(applicationContext, T::class.java)!!

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.R) {
   val windowManager: WindowManager = getSystemServiceCompat()
   val displayCutout = windowManager.currentWindowMetrics.getWindowInsets().displayCutout
   Log.d("AppLog", "displayCutout:$displayCutout")
}

5. Writing "intended behavior" doesn't make it right, and doesn't make it something that's not a bug/flaw in design.
If you see a game that shows a dice to roll, you expect it to have 1/6 chance for each value. If you see text somewhere that says otherwise, it makes it a terrible bug in design of the game (and I even saw something very similar to this in a real game).

6. I already had a video chat with one of Admob's team (Eric Leichtenschlag) on March 27th. The talk there was mainly about various topics of GDPR&CCPA and a bit of Admob in general, and he agreed there that we should have a better API for the data to send to the ad-networks, and he also agreed and even was surprised that we need Activity for the query of the ad-consent. He was sure we actually don't need an Activity and presented me with a function he thought should be able to do it (which is sadly incorrect).
He agreed it shouldn't work this way, that we should be able to query in the background without the specific need of Activity. He said he will have another talk with me about it but for some reason it didin't happen.

7. We should also be able to take the cached value as long as it's not expired, which can also help with background handling but also with faster responsiveness.

Please, we can have a video chat again and talk about it. 

[Mobile Ads SDK Forum Advisor]

Hi Liran,

Thank you for sharing the details with us.

I will share this information with the team and will get back to you.

Thanks,
 

Mobile Ads SDK Team

Feedback
How was our support today?

               

[2025-05-19 03:12:59Z GMT] This message is in relation to case "ref:!00D1U01174p.!5004Q02vHDWE:ref" (ADR-00297237)

[paGla]

• Thank you for the explanation. I understand the intended behavior.
• I appreciate the clarification, but I still have concerns about requiring an Activity.
• I understand. Please keep me updated if there are any changes in the future.

paGla

--

---
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/38dfa220-dde3-45ea-9d84-8b96b3c8b0d3n%40googlegroups.com.

[paGla]

• Thank you for the explanation. I understand the intended behavior.
• I appreciate the clarification, but I still have concerns about requiring an Activity.
• I understand. Please keep me updated if there are any changes in the future.

paGla