Google Play's Data safety section (App content > Data safety in Play Console) asks every developer to declare what user data their app collects and shares, and for what purpose. Google's policy requires that declaration to be accurate -- and the most common way it stops being accurate is silent drift: a permission or a third-party SDK starts collecting a category of data that the form was never updated to mention.
Two sources, both easy to miss because neither shows up as a compile error:
| Source | Example | Implied category |
|---|---|---|
| A requested permission | ACCESS_FINE_LOCATION, READ_CONTACTS, RECORD_AUDIO | Location, Contacts, Audio files |
| A third-party SDK | Firebase Analytics, AdMob, a crash reporter, an ad network | App activity, Device or other IDs, App info and performance |
A permission added for one feature (say, location for a store-locator screen) is trivial to forget when the Data safety form was filled in months earlier at first submission. An SDK is worse: many are added transitively by another dependency, so nobody on the team consciously chose to add data collection at all.
The checker on this site scans your
AndroidManifest.xml and Gradle files for the permissions and known
SDKs that imply a category, and compares the result against a plain list of
what you've already ticked in Play Console -- naming the exact file and line
behind anything undeclared. It runs as a browser tool (nothing uploaded) or a
Node CLI you can add to your own pre-release check.
This is evidence of what the manifest, the Gradle files, and your declared list say -- not a determination that Play Console will accept the submission. See the checker and its disclaimer for what it can and can't see, and verify against Google Play's current Data safety documentation before you publish.