Google Play's documentation names the Data safety data-type categories and
what each one covers -- it is the source of truth this tool's own category
list is checked against. What it does not do is read your specific
AndroidManifest.xml, your specific Gradle files, or your specific
declared list and tell you which category your app actually triggers, in
which file, or whether your declaration already covers it. That cross-check
has always meant either a guess informed by the docs, or a definite answer
from a Play Console policy warning -- or a listing taken down -- after the
fact.
Google's documentation is complete and authoritative about
what the categories are and what they cover. It is not a scanner: it cannot
look at your project and tell you that app/build.gradle line 6
pulls in Firebase Analytics with no matching Data safety entry, because it
has never seen your code.
A Play Console policy warning will eventually tell you, with certainty -- after publishing, a policy review, and a warning naming the gap, sometimes after the listing is already live. For a category pulled in transitively by a dependency's own dependency rather than one your team added on purpose, that warning may be the first time anyone learns the SDK collects that category at all.
This checker runs the same permission-and-SDK-to-category cross-check a policy review would, against your manifest, Gradle files, and declared list, before you submit -- in the browser (nothing uploaded) or as a Node CLI you can gate CI on.
| Question | Where to answer it |
|---|---|
| Which category does my app trigger, and where? | This checker's scan -- file and line, free, nothing uploaded. |
| What does a given category cover? | This checker lists them alongside your results; both it and Google's docs agree, since this tool's list is checked against Google's published one. |
| Will Play Console actually accept my declaration? | Neither. Only Google's own policy review determines that -- this is evidence about your manifest, Gradle files, and declared list as they stand today. |
| Is my project uploaded anywhere? | No. The browser tool reads files with the File API; the CLI never makes a network call. |
It lists the Data safety data-type categories and what each one covers, and it is the source of truth this tool's own category list is checked against. What it doesn't do is read your specific AndroidManifest.xml, your specific Gradle files, or your specific declared list and tell you which category your app actually triggers, in which file, on which line. That cross-check is what used to mean either guessing from the docs or finding out from a policy warning.
At minimum, a policy-warning email and a fix-and-resubmit cycle; at worst, a listing taken down for an inaccurate Data safety disclosure while you scramble to correct it live. For a category pulled in transitively by a dependency's own dependency rather than one you added on purpose, the warning may be the first time anyone on the team learns the SDK collects that category at all. Scanning your manifest and Gradle files before you submit catches the same gap without spending a review cycle -- or a live listing -- to find it.
You can, and for a small project it may be faster than downloading a tool. The risk is coverage: 20-plus permissions across every AndroidManifest.xml in a multi-module project, plus every Gradle dependency coordinate a transitive library might have pulled in without anyone adding it directly. This tool runs the same permission and SDK list against every file you point it at, in the browser or as a CI-gating CLI, so a category buried in a module or a transitive dependency you didn't think to check is not the one that reaches a policy warning first.
No, and it is not built to. This is pattern-matching against known permission names and Gradle dependency coordinates -- it cannot see what a permission is actually used for, dynamically loaded code, or a compiled third-party library's real runtime behaviour, and Google can change its Data safety categories or a listed SDK's practices at any time. A clean report means your current manifest, Gradle files, and declared list agree with each other; it is not a guarantee Play Console will accept your submission, so verify against Google's current documentation before you publish.