Request: need more explanation about AppSetId and "Sync consent across multiple apps"

[Liran Barsisa]

I tried to use this new feature on Android:
https://support.google.com/admob/answer/16472823
https://developers.google.com/admob/android/privacy/sync-consent#kotlin

I've set the "Consent group" to include my apps.
However, I still have some questions, as I don't think things are working as they should.

To me, I think it's supposed to prevent UMP dialog to appear in one app of mine from the "Consent group" if another app from this "Consent group" already had it before and the user granted the consent. 

My questions:
1. Is this what it's about? Is this how it's supposed to work?

2. What happens if the user didn't grant consent to all? 

3. It says "Once consent syncing is live...". Does it mean it's not live yet? I can't find any date about it... 

4. According to my tests, even though all of my apps are now in the "Consent group", I get a different AppSetId for each of them. Is this normal? I thought it should be the same across apps, as it's an ID for the user, no?
After all, it says : "The identifier you provide must uniquely identify the user across all of your apps where consent is being synced", so doesn't the AppSet.getClient.appSetIdInfo already provide it?

5. Why does it say " Hash or encrypt the identifier to preventsending personally identifiable information (PII) to Google " , if the snippet doesn't show it?  Why doesn't the ID have something of Google to send, just as it uses Firebase and Admob itself for user ID? Or maybe here the hashing is about when we get a user ID in other ways?
Also, hashing doesn't mean it will stay unique anymore, as multiple users might get the same hash, which means the SDK won't work properly anymore as it could prevent the ad-consent appearing for multiple users. Uniqueness has to stay. 

6. The function works as a callback, and the snippet uses addOnSuccessListener . Does it mean it always succeeds? How long can it take for the callback to be called? If it can take some time, doesn't it mean we can't query the ad-consent yet, delaying ad-loading even further? Wouldn't it be better to instead have one call to the servers of Google/Admob that will fetch both of them (ID and ad-consent) together?

7. Isn't it time to make things simpler in the UMP SDK ? It became more and more complicated to work with it, yet still what I was told about it still didn't happen, that it will at least stop requiring Activity instance in functions that shouldn't need it (such as requestConsentInfoUpdate, which doesn't really need to do anything related to the UI) . Please try to make things easier , with less steps and restrictions, yet also handle edge cases on SDK side.

[Liran Barsisa]

8 It's quite weird we are being requested to have a unique user ID, being given an example of something that's not unique, and asked to hash/encrypt the user ID without explanation if it's needed on the snippet too.

Is is perhaps ok to just use the ad-ID when possible?
Meaning this one, when isLimitAdTrackingEnabled is false:

            val idInfo = AdvertisingIdClient.getAdvertisingIdInfo(context)
            val isLimitAdTrackingEnabled = idInfo.isLimitAdTrackingEnabled
            Log.d("AppLog", "isLimitAdTrackingEnabled?$isLimitAdTrackingEnabled id:${idInfo.id}")

            
 ?

And even then, is it ok to use it as it is, instead of encrypting/hashing it?
The "encryption" isn't quite encryption either, because APK files can be deobfuscated and then the key is known. And hashing as I wrote is problematic as it can belong to multiple users because it's not unique.

[Liran Barsisa]

As AppSetID doesn't seem to be fetched correctly in this SDK, I wonder why the need for a server call for AppSetID.

It could have worked this way:

Upon app's onCreate, communicate with all of the apps in the group, querying if any of them has created an ID yet.
If there is one, use it for ad-consent.
If none, and we finished with the ad-consent, generate it, save it, and have it being used by the other apps in the group if they call it.
No need here for Google, or Play Services...
Perfect solution for Admob as it can be used anywhere.

[Mobile Ads SDK Forum Advisor]

Hi Liran,

Thank you for contacting the Mobile Ads SDK Support team.  

Please note that this feature is currently in beta release. Meanwhile, I will raise this issue with the wider team and will notify you once I receive any updates. Meanwhile, your patience is important.

Thanks,
 

Mobile Ads SDK Team

Feedback
How was our support today?

               
[2025-11-04 23:25:45Z GMT] This message is in relation to case "ref:!00D1U01174p.!500Ht01vSSlj:ref" (ADR-00338232)

[Liran Barsisa]

Thank you.

You should also train Gemini about it.
It claimed the feature exists for a very long time, of fetching the AppSetID.

It also claimed it could be because of the signature key of my app that should be the same as on the other apps, which doesn't make sense. I even checked it on debug signature key which is the same, and it's not right.

And I checked on release signature key.

[Süleyman Temir]

😍☕

rad...@radar5.org

3 Kas 2025 Pzt 01:17 tarihinde Liran Barsisa <lbl...@gmail.com> şunu yazdı:

--

---
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/7588d982-a550-40ab-ab00-8dd336851bcbn%40googlegroups.com.

[Liran Barsisa]

I think I know why I got different values for AppSetID, and it even says it on the docs:

Under any of the following conditions, the app set ID SDK returns an ID unique to the calling app itself on a given device:

The app is installed by an installer other than the Google Play store.
Google Play services is unable to determine an app's Google Play developer account.
The app is installed on a device without Google Play services.

https://developer.android.com/identity/app-set-id#app-scope

So this means we can't test it well using the IDE, unless we use adb command to mimic installation from Play Store... Not only that, but it says I shouldn't cache it, and always query it:

Under any of the following conditions, the app set ID for a given set of Google Play store-installed apps on a device can be reset:

The app set ID API hasn't been accessed by the groups of apps that share the same ID value for over 13 months.
The last app from a given set of apps is uninstalled from the device.
The user performs a factory reset of the device.
Your app must use the SDK to retrieve the ID value every time it's needed.

https://developer.android.com/identity/app-set-id#dont-rely-on-cached-value

So this makes it quite unreliable and annoying to test. I think the best thing would be to use what I've suggested, that apps communicate with one another. It doesn't even need Play Services for this, and not a server either.

Even (encoded) ad-ID could be better in some cases here

On Wednesday, November 5, 2025 at 1:26:42 AM UTC+2 Mobile Ads SDK Forum Advisor wrote:

[Mobile Ads SDK Forum Advisor]

Hi Liran,

Thank you for your findings.

Please note that our team is actively working on this and will let you know as soon as an update is ready. Meanwhile, your patience is highly appreciated.

Thanks,
 

Mobile Ads SDK Team

Feedback
How was our support today?

               

[2025-11-06 23:38:38Z GMT] This message is in relation to case "ref:!00D1U01174p.!500Ht01vSSlj:ref" (ADR-00338232)

[Liran Barsisa]

Thank you.
After some experimenting, I've come to the conclusion that not only that AppSetId has various disadvantages that I've mentioned and are documented, but it's 3-8 times slower than getting the ad-ID...

How could a newer API be worse than older API in all possible ways...

[Mobile Ads SDK Forum Advisor]

Hi,

 

Thank you for getting back to us.

 

We’ve added the concern about the AppSetId API being slower than the Ad ID API to the existing request. We will get back to you once I receive any updates on it. Meanwhile, your patience is highly appreciated.

Thanks,
 

Mobile Ads SDK Team

Feedback
How was our support today?

               

[2025-11-10 06:51:51Z GMT] This message is in relation to case "ref:!00D1U01174p.!500Ht01vSSlj:ref" (ADR-00338232)

[ประธาน ชูเกลี้ยง]

ในวันที่ ส. 8 พ.ย. 2025 11:10 PM Liran Barsisa <lbl...@gmail.com> เขียนว่า:

--

---
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/1d84c302-30fd-4246-a7cf-d448ba335e0en%40googlegroups.com.

[Liran Barsisa]

Today when I've uploaded a new version of my app, that uses encoded ad-ID , it was rejected despite the fact that it should be allowed according to your own documentation:
" The identifier you provide must uniquely identify the user across all of your apps where consent is being synced. Hash or encrypt the identifier to prevent sending personally identifiable information (PII) to Google."

https://support.google.com/admob/answer/16472823#:~:text=The%20identifier%20you%20provide%20must%20uniquely%20identify%20the%20user%20across%20all%20of%20your%20apps%20where%20consent%20is%20being%20synced.%20Hash%20or%20encrypt%20the%20identifier%20to%20prevent%20sending%20personally%20identifiable%20information%20(PII)%20to%20Google.

https://developers.google.com/admob/android/privacy/sync-consent#kotlin:~:text=The%20identifier%20you%20provide%20must%20uniquely%20identify%20the%20user%20across%20all%20of%20your%20apps%20where%20consent%20is%20being%20synced.%20Hash%20or%20encrypt%20the%20identifier%20to%20prevent%20sending%20personally%20identifiable%20information%20(PII)%20to%20Google.

Please talk with the privacy policy team of the Play Store to be in sync with the new APIs.

[Liran Barsisa]

The Play Policy team won't accept using encoded ad-ID for this API when the app targets age of 0-4, despite the fact it should be fine according to your own docs as I've mentioned.

Please talk to them to fix this issue.

For now sadly I use AppSetID there. 

I think that it's not even needed for such apps, as I didn't see ad-consent dialog appearing in such an app.