How to Write a Privacy Policy for an Android App (Google Play Rules)

Every app on Google Play needs a privacy policy, including apps that collect nothing at all. A missing, broken or vague policy is one of the most common reasons an Android app gets rejected or pulled during review.

We publish apps on Google Play and host all of their privacy policies on this site. This guide explains what Google requires, what to put in your policy, and the mistakes we see most often. It isn't legal advice; if your app handles sensitive data, have a lawyer review the final text.

Does my Android app need a privacy policy?

Yes. Google Play's User Data policy says every app must post a privacy policy, and that apps which don't access any personal or sensitive user data must still submit one. In that case the policy simply says so, and your Data safety form should match.

Google Play's requirements, in plain language

Your policy must meet all of these, or the app can be rejected:

• Linked in two places. Add the URL in Play Console (App content › Privacy policy) and link to it, or show the text, inside the app itself.
• A live, public web page. It must be on an active, publicly accessible URL with a valid HTTPS certificate. No PDFs, no login walls, and no blocking by country.
• Not editable by visitors. A shared document that anyone can edit doesn't count.
• Clearly labelled. The page should be titled as a privacy policy.
• Specific to your app. The developer name shown on your Play listing must appear in the policy, or the policy must name the app.
• Complete. It must explain how the app accesses, collects, uses and shares all user and device data, including data collected by SDKs you've added. It isn't limited to what you declared in the Data safety form.

Google's checklist is in Prepare your app for review.

What to include: a section-by-section outline

1. Who you are. Developer or company name, app name, package name and a contact email.
2. Data the app handles. Everything the app touches, and where it lives: on the device, on your servers, or with a third party.
3. Why you use it. One purpose per data type: "to show your budget", "to process your purchase", "to serve ads".
4. Third parties and SDKs. Every outside service, what it receives and a link to its policy. Ads, analytics, crash reporting, payments and login providers all count.
5. Permissions. Each Android permission the app requests and why. A table works well.
6. Security. How data is protected in transit and at rest.
7. Retention and deletion. How long you keep data and how users can delete it.
8. Children. Whether the app is aimed at children, and what you do if a child's data reaches you.
9. User rights. Access, correction and deletion rights under laws such as the GDPR (EU and UK) and CCPA (California), and how to exercise them.
10. Changes and contact. How you'll announce updates, the effective date, and how to reach you.

Mistakes that get apps rejected

Forgetting what your SDKs collect

Your own code may collect nothing while an ad, analytics or crash-reporting SDK collects a lot. Google AdMob, for example, uses the advertising ID and approximate location to serve ads. If it's in your app, it belongs in your policy.

A policy that contradicts the Data safety form

Google compares the two. If your form says "No data collected" but your policy mentions analytics, or the other way round, expect a rejection. Write the policy first, then fill in the form from it.

Copying a template without editing it

Generic templates often name the wrong app, list services you don't use, or miss the ones you do. A policy has to describe your app.

Changing the URL later

Your Play listing, in-app link and Data safety form all point at the policy URL. Pick a permanent address on a domain you control and keep it, updating the text in place. If you ever must move it, redirect the old URL to the new one.

Forgetting account deletion

If users can create an account in your app, Google Play also requires a way to request account deletion, both in the app and through a web link. Explain what gets deleted and what, if anything, you keep.

Real examples

These are live policies for apps on Google Play. Each shows a different situation:

• Veylix: everything stays on the device. It includes an "at a glance" summary, a permissions table and how Google Play Billing fits in.
• PDF Zipper: on-device processing on Android and iOS, with an SDK (Google ML Kit) that sends Google limited technical data.
• Captionix AI: an app that sends some data to its own servers, uses outside services and shows ads, with a table for each.

Where to host your privacy policy

A page on your own website is best: you control the URL, it's always online, and it looks trustworthy to users and reviewers. Keep it fast and readable on a phone, since that's where most people will open it from your Play listing. A plain HTML page is enough.

Quick checklist before you submit

• The policy names your app and the developer shown on your Play listing.
• Every SDK and outside service is listed with what it receives.
• Every permission is explained.
• The Data safety form matches the policy.
• The URL is public HTTPS, not a PDF, and works from every country.
• The policy is linked in Play Console and inside the app.
• It has an effective date and a contact email.