Android advertising ID: check the AD_ID permission before targeting Android 13

Android advertising ID work can look like a one-line manifest change. The risky part is deciding whether your app or one of its included libraries uses the identifier, then checking that the final package and Play Console declarations agree with what the app actually does.

Google Play’s guidance ties the com.google.android.gms.permission.AD_ID permission to apps that update their target to Android 13 or later. A library can contribute that permission through its own manifest, which Android’s build process merges into the app manifest. Separately, when a user deletes the advertising ID in Android settings, access returns a string of zeros instead of the old identifier. Those facts make this a release-readiness check across dependencies, the merged package, and your app’s disclosures—not a reason to paste a permission into every project.

Start with the behavior, not the permission lineCopy Anchor Link

The advertising ID is a resettable and deletable identifier provided by Google Play services for advertising. It is not a universal analytics ID. Google Play’s guidance says that when it is available, it must be used for advertising purposes instead of other device identifiers. For essential non-advertising use cases such as analytics or fraud prevention, Google points developers to App Set ID.

Start by asking what the shipped app and its dependencies do. Does code request the Advertising ID API? Does an ads library include support that can access it? Is the identifier used for advertising, or is a team trying to reuse it for analytics or another purpose? A dependency name, permission line, or package listing alone may not answer all three questions.

Do not infer that a particular SDK reads the ID just because it is present. Check that SDK’s own current documentation and the app’s implementation. Google’s help page gives Google Mobile Ads as an example of an SDK that may declare AD_ID in its library manifest; it does not establish that every version or every other SDK uses the identifier. Keep claims about your own dependency set tied to the versions and documentation you actually reviewed.

Make an inventory before changing target SDKCopy Anchor Link

Before increasing target SDK, create a short inventory of identifier-related behavior. Include direct dependencies, transitive SDKs, and any internal modules that add Android libraries. For each one, record the version, the relevant data or advertising behavior documented by its publisher, and the evidence you used. If you cannot determine whether a dependency uses the Advertising ID, mark that as an open question for its maintainer rather than treating it as fact.

Then check whether your app calls the Advertising ID API directly. Search application code and any native modules under your control. This does not replace dependency review: code can be present in a library even when your own source never names the API. Conversely, a manifest permission by itself does not prove that the app actually reads the identifier.

This is also a good point to separate three things that teams often collapse into one checkbox:

• Whether the final Android package declares the AD_ID permission.
• Whether app code or included libraries access or transmit the Advertising ID.
• Whether Play Console’s advertising-ID and data disclosures accurately describe the app’s behavior.

Those checks inform each other, but they are not interchangeable. A permission is a package declaration. A disclosure is a statement about app behavior. If either one is changed, review the other against the implementation and the relevant Play guidance.

Inspect the merged manifestCopy Anchor Link

The key manifest to inspect is the one produced for the build you will ship, not only the source manifest at the top of the project. Android libraries can provide manifest entries that merge into the final app manifest. Google Play’s Advertising ID guidance specifically notes that some SDK library manifests may declare AD_ID and that the permission can be merged into the app’s main manifest by default.

For an Android Gradle build, inspect the merged manifest for the exact variant that will be packaged. Use Android Studio’s Merged Manifest view or the build output for that variant, and confirm the full permission name:

<uses-permission android:name="com.google.android.gms.permission.AD_ID" />

Record which input manifest contributed the line if the tooling identifies it. If the line is absent, do not immediately add it: first determine whether the app actually uses the Advertising ID and whether its target SDK makes the declaration relevant. If the line is present, do not assume that the app necessarily reads or sends the identifier; trace the responsible code and dependency behavior. The distinction matters for both engineering changes and accurate user-facing disclosure.

For a cross-platform app, the native Android build is still the artifact that matters. A JavaScript package manifest or a framework configuration file may be an input to the Android build, but neither is proof of the merged manifest that Play receives. Build the Android variant you plan to submit and inspect that output. If you do not have access to the merged-manifest view in your current workflow, ask whoever owns the native build pipeline to capture it for the release candidate.

Check the deletion caseCopy Anchor Link

Test the behavior your app expects when a user has deleted the advertising ID. Google’s guidance says access attempts receive a string of zeros after deletion. Treat that as “identifier unavailable,” not as a stable user value, a fresh identifier, or an opportunity to fall back to another persistent device identifier for advertising.

Follow the behavior documented by the API and the libraries you use. In particular, review code paths that compare identifiers, create profiles, deduplicate users, or cache an identifier for later requests. The practical question is whether those paths behave safely when the identifier is absent. Do not design a fallback that defeats the user’s deletion choice.

If the product needs an identifier for a non-advertising use case, revisit the appropriate option in Google’s guidance rather than repurposing Advertising ID. Confirm the purpose with the product and privacy owners; technical availability does not by itself establish an appropriate use.

Reconcile the Play Console declarationsCopy Anchor Link

Before release, compare the final package and observed data behavior with the Advertising ID and data disclosures in Play Console. If an SDK or service changes what the app collects, uses, or shares, review those declarations before submitting. Keep the source of each conclusion: dependency documentation, the merged manifest, code review, and the relevant app behavior.

Do not set a declaration from a guess about a popular SDK, or from the permission line alone. Equally, do not assume that a library is irrelevant because its behavior is not visible in your application code. If you cannot resolve what a dependency does, check its current publisher documentation or ask its maintainer. Your release record should say what you verified and what remains uncertain.

A concise review note can capture:

1. The target SDK for the release candidate.
2. Whether the merged manifest contains AD_ID and which dependency contributed it.
3. Whether app code or reviewed dependencies access the Advertising ID, with documentation or code evidence.
4. How deletion is handled in the app’s relevant flows.
5. Whether Play Console’s declarations still match the behavior you confirmed.

This makes a future target-SDK update easier to review because the decision is attached to a particular build and dependency set. Re-run the check when those inputs change; an old screenshot or manifest report does not prove a later release is the same.

Make it a release gateCopy Anchor Link

Treat the check as a small release gate whenever you add or update an advertising, analytics, attribution, or identity-related dependency, and whenever you raise the Android target. Review the dependency change, inspect the merged manifest, and compare the result with the app’s actual behavior and Play declarations. If nothing changed, keep the evidence and move on. If something changed, resolve the mismatch before submission.

For the broader privacy review, see how to make privacy labels defensible for an AI-built app. If you ship on iOS too, Apple’s App Tracking Transparency requirements cover a separate platform-specific decision. Do not treat either article as a substitute for checking this Android build.

SourcesCopy Anchor Link

• Google Play Console Help: Advertising ID