Play asks whether the app uses advertising ID "including any SDKs that your app imports that use
advertising ID", and that clause is the whole difficulty: the ID comes from
play-services-ads-identifier, which merges AD_ID into the manifest by itself - so one unrelated
dependency could turn this answer into a false statement without a line of app code changing. The
answer is No, and the checklist now records how that was established on 2026-10-14 against the
artefacts rather than against intentions:
- the release runtime classpath contains no gms/firebase/ads/billing/play-services entry at all, so
there is no direct *or transitive* SDK that would ask for the ID
- aapt2 dump badging on the release APK lists the seven permissions the audit table already
documents plus the framework's DYNAMIC_RECEIVER_NOT_EXPORTED_PERMISSION - no AD_ID, and no
Privacy Sandbox permission either
- the same check on base/manifest/AndroidManifest.xml inside the .aab finds nothing, which matters
because the bundle is the artefact Play's own scanner reads
- the shipped classes.dex contains no com.google.android.gms classes, and the app has no INTERNET
permission, so an ID could not be transmitted even if one were read
The last two rows are the ones to re-run after any dependency change: they are cheap, and this is
the declaration a stray library answers wrongly on the app's behalf. The same reasoning answers Data
safety's device-identifiers question, which the item now says out loud.
ROADMAP: the remaining-paperwork row names the advertising ID question rather than leaving it
implied by "ads".
SoftwareApp
64431d5757