On this page (11 sections)
Declaration vs actual behaviour
The Data safety section is a declaration about the whole app: your code, your backend and every third-party SDK compiled into the build. Google reviews it against observed behaviour and against the privacy policy. A rejection means at least one of these is inconsistent:
- What the app collects (sent off the device) and shares (transferred to a third party)
- The data types involved: identifiers, location, contacts, personal info, financial info, health, messages, photos, files, diagnostics, app activity
- The purposes: analytics, advertising, personalisation, fraud prevention, app functionality
- Whether collection is optional or required, whether data is encrypted in transit, and whether users can request deletion
- Whether the privacy policy says the same thing
SDKs are the usual culprit
Check every library, not just your code
Analytics, crash reporting, advertising, attribution, push notification, authentication, payment and social SDKs routinely collect device identifiers, diagnostics, coarse location and app activity. Several publish Data safety guidance for their integrators; use it. If an SDK is in the build, its collection is your collection.
Typical surprises: an ads SDK sharing the advertising ID with partners; a crash reporter collecting device and diagnostic data; an analytics library recording screen views as “app interactions”; a social login SDK collecting identifiers; a maps or weather SDK using location.
Identifiers, analytics and location
- Device or other IDs — the advertising ID, installation IDs and similar are “collected” the moment they leave the device. Most analytics and ads SDKs do this.
- Approximate vs precise location — declare what is actually accessed. A library using coarse network location still counts.
- App activity and diagnostics — screen views, in-app search, crash logs and performance data are declarable types.
Permissions and the declaration
Permissions in the merged manifest are evidence of capability. If the app holds camera, contacts, location or storage permissions, the reviewer expects the corresponding data types to be either declared or convincingly not collected. Remove permissions you no longer use; they create mismatches on their own.
Privacy policy consistency
The privacy policy must be reachable from the store listing and inside the app, and it must describe the same collection and sharing as the Data safety form. A generic template policy that fails to mention the SDKs you actually use is a common rejection cause.
Account deletion
If users can create an account in the app, Google requires an in-app path to delete it and a web link for deletion requests, both declared in the Data safety form. Missing deletion is a frequent hidden cause of “Data safety” rejections. See Google’s account deletion requirements (linked in the sources).
Encryption in transit
Declare encryption in transit only if all collected data is actually transmitted over secure connections. Cleartext traffic allowed in the network security configuration, or an SDK using plain HTTP, makes that declaration false.
AI integrations
Sending user text, images or audio to an AI API is data collection and, when the provider is a third party, data sharing. Declare the data types involved and describe the purpose and the provider in the privacy policy. Many recent mismatches come from AI features added after the original declaration was written.
Update the declaration, or change the app?
| Situation | Right fix |
|---|---|
| SDK collects data you genuinely use | Declare it accurately, update the privacy policy, add disclosure/consent where required |
| SDK collects data you do not need | Remove or reconfigure the SDK, then declare what remains |
| Permission left over from an old feature | Remove the permission from the manifest |
| Account creation without deletion | Implement in-app and web deletion, then declare it |
| Cleartext traffic somewhere | Fix the transport, then declare encryption in transit |
Do not blindly over-declare
Declaring collection that does not happen is also a mismatch, misleads users, and can drag the app into stricter policy requirements (for example, declaring location or health data you do not process). Declare what is true.
Our technical audit process
- Inventory every SDK and its version from the build, not the documentation.
- Review the merged manifest for permissions and network security configuration.
- Observe network traffic from a release build to confirm what actually leaves the device and where it goes.
- Map findings to Data safety data types, purposes and sharing.
- Reconcile with the privacy policy and the account deletion requirement.
- Implement changes (remove, reconfigure, add consent or deletion) and produce the corrected declaration.
Resubmission checklist
- Every SDK’s collection and sharing is declared or the SDK is gone
- Merged manifest holds only permissions the app uses
- Privacy policy names the data types, purposes and third parties and is linked in the listing and the app
- Account deletion exists in-app and on the web, and is declared
- Encryption in transit is declared only if it is universally true
- Prominent disclosure and consent implemented where the User Data policy requires it