The Android advertising ID: personal data, not a technical setting

An identifier built to be shared

The advertising identifier is assigned to the device by Google Play services. Its decisive property fits in one sentence: every app on the phone reads the same value. That is its purpose, letting advertising actors join what each app knows about the same person, to target, cap and attribute an install to a campaign.

The CNIL gives the best explanation of it, in a footnote to its mobile app recommendation: unlike cookies, whose value is set independently for each advertising third party, these identifiers are generated randomly when the phone first starts and are the same for every third party, which makes it easy for those third parties to join up the data they each collect about one individual. It adds the multiplier: paired with a signed-in environment, they also link that data to activity on the user’s other devices where they have signed in.

The user can reset or delete it in the settings. But while it is there, every SDK that reads it sends it along with the rest: phone model, system version, IP address. A stable identifier, shared across apps and tied to a profile, is exactly what tracking calls for.

Personal data in the full sense

The GDPR lists online identifiers among what makes a person identifiable (Recital 30), and this one is designed precisely to follow the same person from app to app: the advertising identifier is personal data.

In France, reading it on the phone also falls under Article 82 of the French Data Protection Act, like any reading or writing of information on a terminal. The CNIL’s recommendation draws the consequence: short of strict necessity for the service, the gesture requires consent, and the technical authorization granted by the system does not stand in for it.

The text goes further: it settles who answers for that read when an SDK performs it. In the worked example it sets out, the publisher and the SDK provider are joint controllers as regards the SDK provider’s access to the advertising identifier, which the text describes as a read and/or write operation within the meaning of Article 82, because they jointly determine the purposes and means of that operation. Liability does not travel out with the line of code.

What Google has already locked down

The platform itself has tightened access, in two steps.

Late 2021 first: the advertising identifier is deleted when a user deletes it in the Android settings, and anyone trying to access it then receives a string of zeros. The rollout covered Android 12 devices from late 2021, then all Google Play certified devices from 1 April 2022.

Android 13 next: an app targeting API level 33 or higher must declare a dedicated permission, com.google.android.gms.permission.AD_ID, in its manifest. Without it, the Android documentation states, the advertising ID is automatically removed and replaced with a string of zeros.

real value        the user changed nothing
                  AND the app declares the AD_ID permission

string of zeros   the user deleted the identifier in the Android
                  settings
                  OR the app targets Android 13 or higher without
                  declaring the AD_ID permission

The permission you never wrote

A detail that matters for publishers: this permission can land in your app without anyone on your team ever writing it. Google documents it plainly, about its own kits: if your app uses those SDKs as dependencies, the AD_ID permission from the SDK library’s manifest is merged into your app’s manifest by default, even when you do not declare the permission explicitly in your own main manifest.

In other words, what your app embeds decides what it asks for, permissions included. The only way to know what your manifest really declares is to look at the published package, not the source.

For apps aimed at children, it is zero outright

Google Play’s Families policy does not hedge, and its list is worth reading in full: apps exclusively targeting children must not transmit the Android advertising identifier (AAID), SIM serial, build serial, BSSID, MAC address, SSID, IMEI or IMSI. It adds that those apps must not request the AD_ID permission when targeting API level 33 or higher.

That is a ban on transmission, not a consent requirement: no banner lifts it. It meets the front the CNIL has opened on apps used by minors, where several publishers received formal notices in 2025.

Zeros are not a blank cheque

A string of zeros in place of the identifier is a readable refusal, not a gap to fill. The temptation exists all the same: compensating the loss with another device identifier, or with a fingerprint built from the model, the language and the screen resolution.

That is exactly the kind of workaround authorities sanction. On 29 December 2022 the CNIL fined a mobile games development company 3 million euros, on the ground of consent to trackers. Its mobile app recommendation cites that decision, no. SAN-2022-026, among the precedents where non-compliant use of mobile identifiers drew a sanction, alongside another one targeting an app store the same day.

Google says the same thing from the other end of the chain: its developer programme policy requires that, for advertising, all updates and new apps uploaded to Google Play use the advertising ID where available on the device, in place of any other device identifier, and apps using a persistent identifier other than the advertising ID may receive a policy warning. The workaround is billed twice, by the regulator and by the store.

The reading rule is simple: the choice expressed covers the purpose, not the technique used. Switching identifiers does not switch the refusal.

What to use instead, and for what

Not every use of an identifier is advertising. For internal analytics or fraud prevention, Google points to another mechanism: for essential non-advertising use cases, such as analytics and fraud prevention, use the app set ID.

That app set ID has a deliberately narrow scope. For apps installed from Google Play, it is scoped to the set of apps published under the same Google Play developer account: two apps from the same publisher installed on one phone share the same value, and a third party does not find it anywhere else. It resets if the API has not been accessed for over 13 months, if the last app in the set is uninstalled, or on a factory reset.

The difference with the advertising identifier is exactly the one the CNIL describes: one is the same for every third party and enables joining, the other stops at the edge of your own catalogue. That does not remove the need for a legal basis, but it changes the nature of the processing, and so the necessity analysis.

How it leaves without anyone deciding

The most common scenario is not a publisher’s decision, it is a default configuration. Google documents it: “By default, the Firebase SDK collects identifiers for mobile devices (for example, Android Advertising ID and Advertising Identifier for iOS) and utilizes technologies similar to cookies.” And further down: “By default, on Android the SDK collects the Advertising ID.”

This is not hypothetical. In September 2026 the Spanish authority published a decision declaring a breach of the minimisation principle against a public body whose app was sending a third party thirty-six categories of data, the advertising identifier included, because of a misconfigured notification module. The publisher did not know, and the case rests on traffic captures: that is the notification SDK story.

What a publisher must be able to answer

Four questions sum up the subject, and they are an inspection’s questions. Does your published manifest declare the AD_ID permission, and if so, because of which SDK? Does the identifier leave before consent is given? To which actors does it go, knowing each can join it with what it collects elsewhere? And after a refusal, is the zeroed value honored, or does another identifier take over?

None of these answers can be read in documentation. They are observed in the app’s real traffic, request by request, timestamps attached. That is exactly what a GDPR compliance audit of your mobile app establishes: the list of actors that receive the identifier, and the moment of each send relative to the user’s choice, data point by data point.

Sources

Every finding in this article traces back to one of these documents.

1. Google PlayAdvertising ID: string of zeros, AD_ID permission, manifest mergingPlay Console Help, Google
2. Android 13Behavior changes: Apps targeting Android 13 or higherAndroid Developers documentation, Google
3. AndroidApp set ID: scope, reset conditions, non-advertising use casesAndroid Developers documentation, Google
4. Google PlayGoogle Play Families Policies: identifiers that must not be transmittedPlay Console Help, Google
5. GoogleData collection: identifiers collected by default by the Google Analytics for Firebase SDKFirebase documentation, help centre
6. CNIL ’25Recommendation on mobile applications, amended versionCNIL, deliberation no. 2025-024 of 27 March 2025
7. CNIL ’22Sanction of 29 December 2022, mobile games development company, 3 million euros (deliberation no. SAN-2022-026)CNIL, list of sanctions issued
8. GDPRRegulation (EU) 2016/679, Recital 30: online identifiersOfficial Journal of the European Union