Privacy Policy and Data Safety Form for Android Apps: What Google Play Expects

App rejections on Google Play rarely come from the code itself. Much more often the problem is paperwork: a privacy policy link that does not open, a Data safety form that does not match what the app really does, or a missing way to delete an account. These are fixable in an afternoon once you know what reviewers look for. This article walks through the three pieces and how they fit together.

This is practical guidance, not legal advice. Policies change, so always confirm details against the current Google Play Developer Policy Center and get legal review if your app handles sensitive data.

1. The privacy policy

Every app on Google Play needs a privacy policy link in Play Console, and apps that handle personal or sensitive user data are also expected to make it available inside the app, for example from a settings or about screen. The policy has to be hosted somewhere reviewers and users can actually open it:

• A public, active web page that does not require a login.
• Not a PDF, and not a shared document that can be edited by others.
• Not geo-blocked; it should load from any country where the app is distributed.
• Clearly about your app or your company, with the app name or developer name visible.

What to include

• Who you are and how users can contact you, with a working email address.
• What data the app collects, both data users enter and data collected automatically (device identifiers, crash logs, usage events).
• Why you collect it: app functionality, analytics, advertising, fraud prevention, and so on.
• Which third parties receive it, including the SDKs bundled in your app.
• How long you keep data and how it is protected.
• How users can request access to or deletion of their data.
• Your approach to children's data if the app could be used by children.

A common mistake is copying a generic template that says "we do not collect any personal data" while the app ships with an ads SDK. Advertising and analytics SDKs almost always collect device or advertising identifiers and some interaction data. Your policy needs to say so and link to the relevant third-party policies.

2. The Data safety form

The Data safety section in Play Console produces the "Data safety" panel users see on your store listing. It is required for every app, even one that collects nothing. Google compares it against your privacy policy and your app's actual behavior, so the three must tell the same story.

Account for your SDKs

You are responsible for data collected by the libraries inside your app, not only your own code. Before filling the form, list every SDK in your build and read its data disclosure guide. Most major SDK providers, including Google's own AdMob and Firebase, publish a page that tells you exactly which Data safety answers apply.

For a typical free game or utility app that shows ads and uses Firebase, expect to declare at least some of the following: device or other IDs, approximate location derived from IP address, app interactions, and crash logs or diagnostics. Mark each one with its purpose (advertising, analytics, app functionality) and whether it is shared with third parties.

Collected versus shared

Google uses specific definitions. "Collected" means data is transmitted off the device. "Shared" means it is transferred to a third party. Data processed only on the device does not count as collected. Data sent to a service provider that processes it on your behalf may be exempt from "shared". Read the definitions in the Play Console help text carefully rather than guessing, because a mismatch is a frequent reason for policy warnings.

Encryption and deletion questions

The form also asks whether data is encrypted in transit and whether users can request deletion. If you use HTTPS for all network traffic, answer yes to encryption in transit. Only answer yes to deletion if you actually provide a way to request it, which brings us to the third piece.

3. Account deletion

If your app lets users create an account, Google Play requires two things: a way to start account deletion from inside the app, and a web page where users can request deletion without reinstalling the app. You enter that web link in the Data safety section.

• The web page should name the app and the developer, so users know they are in the right place.
• It should explain the steps, or provide a form or email address that starts the request.
• It should say which data is deleted, which data is kept (for example, records you must keep for legal reasons), and for how long.
• Deleting the account should delete the associated data, not just deactivate the login.

Apps without accounts do not need a deletion page, but you can still offer a contact address for data requests, which also helps with privacy laws in many regions.

Hosting these pages well

Keep each app's privacy policy and deletion page at a stable, readable URL on your own domain, such as /myapp-privacy-policy. Do not change the URL after submitting it; if you must, keep a redirect so the old link keeps working. If your website is a single-page app, make sure these pages load without JavaScript errors and are served as real HTML, because reviewers and crawlers may not wait for client-side rendering.

A short pre-submission check

1. Open the privacy policy link from Play Console in a private browser window. It must load without a login.
2. Compare the policy, the Data safety answers and your SDK list line by line.
3. If the app has accounts, test the in-app deletion flow and the web deletion page.
4. Make sure the contact email in the policy is monitored.
5. Re-check everything whenever you add an SDK or a new feature that touches user data.