Bug: time out exception for fetching AppSetId, without any way to overcome it

[Liran Barsisa]

- Steps to reproduce the problem (including sample code if appropriate).
1. Use the new API to get AppSetID:
https://support.google.com/admob/answer/16472823
https://developers.google.com/admob/android/privacy/sync-consent#kotlin
https://developer.android.com/training/articles/app-set-id

I have something like this:

    implementation("com.google.android.gms:play-services-ads:24.7.0")

            AppSet.getClient(app).appSetIdInfo.addOnCompleteListener(object : OnCompleteListener<AppSetIdInfo> {
                @UiThread
                override fun onComplete(task: Task<AppSetIdInfo?>) {
                     ...
                        val appSetId: String? = task.result?.id

                        ...



2. Publish to many users.
3. Check Crashlytics

- What happened.
Got this crash:

          Fatal Exception: com.google.android.gms.tasks.RuntimeExecutionException: java.lang.Exception: The operation to get app set ID timed out. Please try again later.
       at com.google.android.gms.tasks.zzw.getResult(com.google.android.gms:play-services-tasks@@18.1.0:3)
       at com.lb.app_manager.ads.ad_consent.AdConsentSyncIdManager$fetchAppSetId$1.onComplete(AdConsentSyncIdManager.java:193)
       at 

The crash is on the onComplete line (193) and not on the line of " task.result?.id" , without letting me do anything about it.


- What you think the correct behavior should be.
Shouldn't crash. 

[Liran Barsisa]

Video of the crash attached here.

[Mobile Ads SDK Forum Advisor]

Hi,

Thank you for contacting Mobile Ads SDK Support team.

Please note that the Sync consent across apps is currently in a beta phase. 

I have executed our sample project by Setting the consent sync ID on the ConsentRequestParameters object, I was unable to reproduce the reported issue. Could you kindly provide the sample project to facilitate further investigation?

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 option or  by performing the following steps:

1. Navigate to

https://docs.google.com/forms/d/e/1FAIpQLSfkAiXMeYP-fw1W3Z-tT9uwmATEKO5X6S-th0gR2ezdKaaqfg/viewform?usp=pp_url&entry.400550049=Mobile+Ads+SDK&entry.460850823=500Ht00001vTG9JIAW&entry.80707362=00339109

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-11-12 16:27:31Z GMT] This message is in relation to case "ref:!00D1U01174p.!500Ht01vTG9J:ref" (ADR-00339109)

[Liran Barsisa]

The API I'm talking about is of before using the " Sync consent across apps". It's about just getting the AppSetID:
https://developers.google.com/android/reference/com/google/android/gms/appset/package-summary

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

It's even a part of the Admob dependency, so it seems it doesn't require an additional dependency as written on the docs, which is a bit weird...

Setting the consent sync ID is irrelevant. I'm talking about fetching it, which is a step before this one you've mentioned.

As for reproducing, it's published for various users, so you need to do the same, and not rely on your optimal conditions. Or you need to mimic what users can have. 

Maybe have a slow/unreliable connection? You need to reach a point that it causes a timeout.

As for project, it's just the code I've written of.

In my apps, I actually made it prefer encoded ad-ID as it's much faster, but if it can't get it, it will use AppSetID.

Anyway, I added something which might solve this, but I want to ask you if it's indeed the reason:
Is it possible that what I wrote is the problem, as it tries to get the result without checking if it was fine?
Maybe I need to check if it's successful, and only then get the result?

Meaning something like this:

if (!task.isSuccessful) {
  ... handle error
  return

}
val appSetId: String? = task.result?.id

?

But then, how come the exception was showing it was on the callback itself, and not on the line I've written of?
Bug in fetching which line it occurred? 
For now I've made these changes, and also logged to Crashlytics before this code, to see if indeed it's the cause of it or what's before.

[Liran Barsisa]

According to my tests, even though the workaround I've written helps in preventing the crash, the timeout for it is huge: 60 seconds...

I see no reason to use this API, then...

Please offer something better, as I've written above:
1. Use cached ID if saved before.

2. If not found a cached ID, communicate with each of the apps in the group to ask for it. If found, save to cache and use it.

3. If not found, generate a unique ID (decide on which app to do it), cache it, and use it. 

This method removes the need of a server side, and should be quite fast. 

[Mobile Ads SDK Forum Advisor]

Hi,

Thank you for getting back to us.

It is highly recommended to check if task.isSuccessful when working with asynchronous tasks in Android, such as the one you're dealing with for fetching the AppSetId. It allows you to handle both success and failure cases correctly.
If you skip it and directly access the result, you may encounter errors, such as null pointer exceptions or unhandled failures.

The AppSet dependency is already included in the Google Ads SDK. So if you’re using the Ads dependency, you don’t need to add AppSet separately. If you aren’t using the Ads SDK, then you need to add AppSet manually.

The App Set ID can reset automatically under certain conditions:

• 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.

So you should not store it long-term or rely on an old cached value. Instead, your app should always call the SDK to get the current App Set ID whenever it needs it.

About the timeout issue(60 seconds) — We'll discuss this with our wider team.

Thanks,
 

Mobile Ads SDK Team

Feedback
How was our support today?

               

[2025-11-18 08:39:03Z GMT] This message is in relation to case "ref:!00D1U01174p.!500Ht01vTG9J:ref" (ADR-00339109)

[Liran Barsisa]

I know about the restrictions and limitations. That's why I don't understand why you made it work this way.
The ad-ID has less cases that it gets reset. And Admob uses it already. 
So, it's a terrible idea to implement AppSetID this way, and it's also terrible that just for an ID before we even start with ad-consent, we need to wait up to 60 seconds...

No app would wait this much for ads.
This affects all users, not just those in the EU. 

[Mobile Ads SDK Forum Advisor]

Hi Liran,

I will check with our team and get back to you with an update as soon as possible. In the meantime, your patience is appreciated.

Thanks,
 

Mobile Ads SDK Team

Feedback
How was our support today?

               

[2025-11-18 16:35:17Z GMT] This message is in relation to case "ref:!00D1U01174p.!500Ht01vTG9J:ref" (ADR-00339109)

[umarza...@gmail.com]

Received.

Sent from Yahoo Mail for iPhone

--

---
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/l2r11000000000000000000000000000000000000000000000T5MGDV00cJsM9dnoRrGHNcjmZPbcMA%40sfdc.net

.