🛡 Legal / Compliance

Privacy Policy Generator for Firebase & Android Apps

Tick the SDKs your app actually ships — Firebase Analytics, Crashlytics, Cloud Messaging, AdMob — and get a privacy policy that names them, plus the data types you will need in Play Console's Data safety form.

Last verified 26 August 2026 · sources checked against Google Play, Firebase and AdMob documentation on that date.

The Free App Maker Privacy Policy Generator builds a Google Play–ready privacy policy for Android apps that use Firebase Analytics, Crashlytics, Cloud Messaging or AdMob. Tick the SDKs your app ships, and it drafts the matching disclosures plus the data types you will need in Play Console's Data safety form. It is free, needs no signup, and is a starting template — not legal advice.

App details
Basic information about your app and developer.
Data practices
What data does your app collect or access? Check all that apply.
Third-party services
Which third-party SDKs or services does your app use? Check all that apply — check your Gradle dependencies rather than relying on memory.

Your Privacy Policy

Next: host this policy at a public URL Options: add a /privacy page to your website, create a GitHub Gist (gist.github.com), or publish via Notion with a public share link. Then paste the URL in Google Play Console → Policy → App content → Privacy policy.

How to generate and publish your privacy policy

Six steps, roughly ten minutes. The slow part is not the writing — it is working out what your app genuinely sends off the device, which is step three.

  1. Enter your app and developer detailsUse the app name exactly as it appears on your Play listing, the developer or company name that acts as the data controller, and a contact email a real person reads. Google Play's User Data policy expects your policy to include developer contact information and a mechanism for privacy inquiries, so a dead mailbox is a real problem, not a cosmetic one.
  2. Tick the data your app collectsPersonal info, location, camera or microphone, contacts, files and storage, app usage. Work from the permissions your app actually requests in its manifest, not from what you meant to build. A permission you requested but never used is still worth removing rather than disclosing.
  3. Tick every SDK your app shipsOpen your build.gradle and read the dependency list. Google Play defines collection as transmitting data from your app off a user's device, and that definition explicitly covers third-party libraries and SDKs — so an SDK you added once and forgot about is still your disclosure to make.
  4. Generate the policy and read every lineThe generator turns your answers into a draft. It cannot know your app, so read it end to end and delete or rewrite anything that does not describe what you actually do. Google Play is blunt about where responsibility sits: you alone are responsible for making complete and accurate declarations about your app.
  5. Host the policy at a public URLCopy the text or download the .txt file and publish it somewhere anyone can open without logging in. A /privacy page on your own site is best; GitHub Pages, a public GitHub Gist, or a publicly shared Notion page all work. Open the finished URL in a private browsing window to confirm it loads for a stranger.
  6. Add the URL in Play Console, then complete the Data safety formGo to Policy → App content → Privacy policy and paste the URL. Google Play also asks for a privacy policy link or text within the app itself, so add one to a settings or about screen. Then fill in the Data safety form — you need a privacy policy on file to complete it — and make sure the two agree with each other.

Sources: Google Play User Data policy and Google Play Data safety, checked 26 Aug 2026.

Where to host it, and what usually goes wrong

The hosting requirement is simple but trips people up in predictable ways. The page has to be publicly reachable, so a Google Doc set to "anyone with the link can comment" or a Notion page you forgot to publish will both fail review. A URL that redirects to your app's login screen fails for the same reason. If you use a Gist, link the rendered Gist page rather than the raw file, and remember that deleting the Gist later silently breaks your listing.

Prefer a page on a domain you control. If you ever change hosts, a policy living on someone else's free tier is the thing you will forget to migrate, and a dead privacy policy URL is grounds for enforcement long after your app was approved.

Why you need one

Google Play requires a privacy policy — here's why it matters

Every app needs one, including apps that collect nothing

Google Play's User Data policy states that apps which do not access any personal and sensitive user data must still submit a privacy policy — in the Play Console field and within the app itself.

GDPR can reach you wherever you are incorporated

Article 3(2) extends the GDPR to controllers outside the EU who offer goods or services to people in the Union — payment or not — or who monitor their behaviour there.

An SDK's data collection is your disclosure

Google Play defines collection as transmitting data off a user's device, and says that includes data collected by third-party libraries and SDKs — even when it goes to a third party's servers, not yours.

A WebView app inherits the site's data practices

If your underlying website collects analytics, uses cookies, or shows ads, those practices belong in your app's privacy policy — even though they happen in the browser layer.

Sources: Google Play Data safety, Google Play User Data policy and GDPR Article 3, checked 26 Aug 2026.

What each Firebase and Google SDK collects — and what to disclose

Adding Firebase to an Android app is three lines of Gradle, which is exactly why it is the most commonly under-disclosed thing on Google Play. Nothing below requires you to write code to trigger it; most of it starts the moment the SDK initialises. Each card lists what Google documents the service collecting, and the Play Data safety data types that usually correspond.

One framing that helps: the Data safety form asks about data types, not SDKs. So your job is to take the union of everything every SDK sends off the device, map it onto Play's categories, and declare that union. Two SDKs collecting the same identifier is still one declaration.

Google Analytics for Firebase

The default that catches people out. With no configuration at all, Analytics reports on the number of users and sessions, session duration, operating systems, device models, geography, first launches, app opens, app updates and in-app purchases. It uses an app-instance identifier to identify a unique installation of the app, and on Android it collects the Advertising ID automatically.

Typically declare: Device or other IDs (app-instance identifier, Advertising ID) · App activity → App interactions · App info and performance. If you log purchase events, Financial info → Purchase history may apply too.

Source: Google Analytics for Firebase data collection, checked 26 Aug 2026.

Firebase Crashlytics

Crashlytics automatically sends crash stack traces and minidump data, the application state at the time of the crash, and device metadata — model, OS version, RAM, disk space, CPU architecture, background state and screen rotation — alongside a Crashlytics installation UUID. Google states it keeps crash stack traces for 90 days before starting the process of removing them from live and backup systems.

The part worth pausing on: custom keys, custom logs and free-text user IDs are collected only because you added them. Developers routinely stuff an email address or an internal account ID into setUserId(), which quietly turns a diagnostics-only declaration into a personal-information one. If you do that, declare what you actually put in there.

Typically declare: App info and performance → Crash logs and Diagnostics · Device or other IDs. Plus Personal info if your custom keys, logs or user IDs contain any.

Sources: Privacy and Security in Firebase and Firebase: prepare for Google Play's data disclosure requirements, checked 26 Aug 2026.

Firebase Cloud Messaging (push notifications)

FCM is the lightest of the set, and people over-disclose it as often as they under-disclose it. Google documents that it uses Firebase installation IDs to determine which devices to deliver messages to, and collects the application version associated with subscriptions. It does not, by itself, collect your users' names or contact details. Retention runs until the customer requests deletion through the API, after which data is removed within 180 days.

Two things extend that footprint: enabling BigQuery export adds message delivery metrics, and having Analytics in the app means message interaction events are shared with Analytics. Both are choices you make.

Typically declare: Device or other IDs (installation ID). Add App activity if Analytics is present and receiving notification interaction events.

Sources: Privacy and Security in Firebase and Firebase: prepare for Google Play's data disclosure requirements, checked 26 Aug 2026.

Firebase Performance Monitoring

Heavier than most developers expect. Google documents it collecting Firebase installation IDs and session IDs, device specifications, OS, orientation, RAM and disk size, CPU usage, carrier information, country based on IP address, network request URLs, response codes, payload sizes and response times, plus app version and package name. Retention is split: IP-associated events are kept for 30 days, installation-associated data for 60 days.

The network URLs matter. If your app calls endpoints with identifiers in the path — /users/12345/orders — those URLs are what Performance Monitoring reports on. That is a good reason to keep identifiers in headers or request bodies rather than in paths.

Typically declare: App info and performance → Diagnostics · Device or other IDs · Approximate location, if you treat IP-derived country as location data.

Source: Privacy and Security in Firebase, checked 26 Aug 2026.

Firebase Remote Config

Remote Config uses Firebase installation IDs to select which configuration values to return to a device, and collects country, language and timezone codes, platform and OS version, the Firebase Android App ID, package name and SDK version so it can target parameters. Data is retained until a deletion API call, then removed within 180 days.

Typically declare: Device or other IDs · App info and performance. Country and timezone are usually declared as part of device information rather than as location.

Sources: Privacy and Security in Firebase and Firebase: prepare for Google Play's data disclosure requirements, checked 26 Aug 2026.

Firebase Authentication

The one place in the Firebase stack where you are unambiguously handling personal data. Authentication processes passwords, email addresses and phone numbers, and logs user agents and IP addresses to add security and prevent abuse. Google keeps logged IP addresses for a few weeks; other authentication information persists until you initiate deletion of the associated user, after which it is removed from live and backup systems within 180 days.

Because this one holds identifiable data indefinitely until you delete it, it is also the service that determines whether you can honour a GDPR erasure request. Know how to delete a user before you need to.

Typically declare: Personal info → Email address, Phone number, User IDs · Device or other IDs. Declare it as collected, and note in your policy how a user requests deletion.

Source: Privacy and Security in Firebase, checked 26 Aug 2026.

Cloud Firestore and Realtime Database

These are storage, so what they hold is whatever your app writes — the form is impossible for anyone but you to fill in. Google documents the Realtime Database processing IP addresses and user agents to enable its profiler tool, kept for a few days unless a customer chooses to save it for longer.

The disclosure risk here is not the SDK, it is your schema. Go and read your collections. If a document contains a display name, a photo URL, a message body or a location, all of those are declarable data types, and none of them appear in any Google document about Firestore.

Typically declare: whatever your own data model stores — commonly Personal info, Photos and videos, Messages, or Files and docs.

Source: Privacy and Security in Firebase, checked 26 Aug 2026.

Google AdMob (Google Mobile Ads SDK)

Usually the widest disclosure in an otherwise simple app. Google's own data disclosure notes for the Mobile Ads SDK list four things it collects: the device's IP address, which "may be used to estimate the general location of a device"; user product interactions such as app launches, taps and video views; diagnostic information including app launch time, hang rate and energy usage; and device and account identifiers including the Android advertising ID, app set ID and signed-in account identifiers. All four are collected for advertising, analytics and fraud prevention, and Google states the data is encrypted in transit using TLS.

Two policy obligations ride along with it. Google Play's advertising ID policy requires apps to use the advertising ID in place of other device identifiers for advertising purposes, and apps targeting Android 13 or above must declare com.google.android.gms.permission.AD_ID in the manifest — a normal permission, but a missing one will get you a policy notice rather than a build error.

Typically declare: Device or other IDs (Advertising ID, app set ID) · App activity → App interactions · App info and performance → Diagnostics · Approximate location, for IP-derived location. Mark these as shared with a third party, not merely collected.

Sources: Google Mobile Ads SDK: Google Play data disclosure and Google Play advertising ID policy, checked 26 Aug 2026.

If your app's audience includes children

This is the sharpest rule in the set, because it is a prohibition rather than a disclosure. Google Play's Families policy states that apps which solely target children "must not transmit Android advertising identifier (AAID), SIM Serial, Build Serial, BSSID, MAC, SSID, IMEI, and/or IMSI." Apps targeting both children and older audiences must not transmit those identifiers from children or from users of unknown age — which in practice means a neutral age screen, since "unknown" counts as protected.

Ads shown to those users must come only from Google Play Families Self-Certified Ads SDKs, and child-only apps should not request the AD_ID permission when targeting API 33 or higher. Note the interaction with the section above: leaving Firebase Analytics on its Android defaults means the Advertising ID is collected automatically, which is precisely the thing this policy forbids. You have to turn it off deliberately.

Also required: disclose the collection of any personal and sensitive information from children in your app, and make sure your privacy policy reflects it accurately.

Source: Google Play Families policy requirements, checked 26 Aug 2026.

Filling in the Play Console Data safety form

The privacy policy and the Data safety form are two separate obligations that have to tell the same story. The policy is prose on a page you host; the form is a structured declaration inside Play Console that becomes the "Data safety" card on your store listing. Google requires a privacy policy on file before you can complete the form.

The two definitions everything hinges on

Collection means "transmitting data from your app off a user's device" — and Google is explicit that this includes data gathered by third-party libraries and SDKs, whether it lands on your servers or theirs. Sharing means "transferring user data collected from your app to a third party", which covers server-to-server transfers, on-device transfers to other apps, and data sent via SDKs or WebViews.

That second definition is the one most indie developers get wrong. If you run AdMob, data is not merely collected — it is shared, because it goes to Google as an advertising partner. Ticking "collected" and leaving "shared" blank is one of the more common inconsistencies.

The categories you will be asked about

  • Location — approximate and precise
  • Personal info — name, email, user IDs, address, phone number, race and ethnicity, beliefs, sexual orientation, other
  • Financial info — payment info, purchase history, credit score, other
  • Health and fitness
  • Messages — emails, SMS/MMS, in-app messages
  • Photos, videos and audio files
  • Files and docs, Calendar, Contacts
  • App activity and web browsing
  • App info and performance
  • Device or other IDs

Where responsibility sits

Google's wording leaves no ambiguity: "You alone are responsible for making complete and accurate declarations in your app's store listing on Google Play." Enforcement follows from discrepancies between what your app does and what you declared — which is why the safest habit is to declare from your dependency list and your database schema, not from memory.

A practical sequence that avoids most rework: list every SDK in build.gradle; look up each one's documented collection; write down the union of data types; check your own database for anything the SDKs do not cover; declare that union in the form; then generate the policy from the same list so the two cannot drift apart.

Source: Provide information for Google Play's Data safety section, checked 26 Aug 2026.

Six things developers get wrong

"My app doesn't collect anything, so I don't need a policy."

Google Play's User Data policy says otherwise: apps that do not access any personal and sensitive user data must still submit a privacy policy. The link is required in the designated Play Console field and as a link or text within the app itself. There is no exemption for small, free or hobby apps.

"Firebase Analytics is anonymous."

It is pseudonymous, not anonymous, and on Android it collects the Advertising ID by default — an identifier explicitly designed to be usable for advertising across apps. Treat it as a declarable identifier, and if you genuinely want it anonymous, disable Advertising ID collection deliberately rather than assuming.

"The SDK collects it, so it's Google's disclosure, not mine."

Play's definition of collection covers data collected by third-party libraries and SDKs, including data transmitted to third-party servers. The SDK vendor publishes what it collects; declaring it is still your job.

"The policy and the Data safety form are the same thing."

They are separate submissions and they are checked against each other. A policy listing five data types against a form declaring two is a visible discrepancy on your own store listing. Update both together, every time you add an SDK.

"I'm not a US or EU company, so GDPR doesn't apply."

GDPR Article 3(2) extends the regulation to controllers not established in the Union where processing relates to "the offering of goods or services, irrespective of whether a payment of the data subject is required, to such data subjects in the Union" or "the monitoring of their behaviour as far as their behaviour takes place within the Union". A free app listed globally and running analytics can meet both limbs regardless of where you are incorporated.

"CCPA applies to everyone, so I'd better claim compliance."

The California Attorney General sets thresholds: gross annual revenue over $25 million; buying, selling or sharing the personal information of 100,000 or more California residents or households; or deriving 50% or more of annual revenue from selling California residents' personal information. Most indie apps meet none of them. Do not claim to be doing things you are not — but note that GDPR has no equivalent revenue threshold, so falling outside CCPA says nothing about GDPR.

Sources: Google Play User Data policy, Google Analytics for Firebase data collection, GDPR Article 3 and California Attorney General, CCPA, checked 26 Aug 2026.

A note on what this tool is, and is not

This generator produces a starting template from the answers you give it. It is not legal advice, it cannot review your code, and it cannot confirm that your app complies with Google Play policy or with any privacy law. Its output is only as accurate as your answers — which is the same standard Google applies to you. Read the draft, correct it, and if your app handles payments, health data, children's data or anything sensitive at scale, have a qualified lawyer review it before you publish.

This page and the other tools here are free to use with no catch — no signup, no credit card, no export fee. Free App Maker itself is free to build and preview with; downloading a signed APK is a one-time unlock, priced by country and always shown before checkout.

FAQ

Privacy policy questions

Does my Android app need a privacy policy?
Yes. Google Play's User Data policy states that apps which do not access any personal and sensitive user data must still submit a privacy policy, and that the link belongs both in the designated Play Console field and within the app itself. There is no size or category exemption, so a simple WebView app needs one too — and if the site inside it runs analytics or ads, those practices belong in the policy.
Does adding Firebase mean my app collects data?
In Google Play's terms, usually yes. Play defines collection as transmitting data from your app off a user's device, and that definition explicitly covers data collected by third-party libraries and SDKs, even when it is sent to a third party's servers rather than yours. Google Analytics for Firebase, for example, collects an app-instance identifier, device models, operating system, geography, session counts and — on Android — the Advertising ID by default, with no code from you.
What do I declare in the Data safety form for Firebase Analytics and Crashlytics?
Map what each SDK sends to the Data safety data types. Google Analytics for Firebase typically maps to Device or other IDs (app-instance identifier and Advertising ID), App activity, and App info and performance. Crashlytics automatically sends stack traces, application state and device metadata plus a Crashlytics installation UUID, which maps to Crash logs and Diagnostics under App info and performance. If you add custom keys, logs or free-text user IDs to Crashlytics yourself, declare whatever those actually contain.
Does AdMob require anything extra in my privacy policy?
AdMob is usually the widest disclosure in a small app. Google documents that the Google Mobile Ads SDK collects the device IP address, which may be used to estimate the general location of a device, user product interactions such as app launches, taps and video views, diagnostic information, and device and account identifiers including the Android advertising ID and app set ID — for advertising, analytics and fraud prevention. Apps targeting Android 13 or above must also declare the com.google.android.gms.permission.AD_ID permission in the manifest.
Where do I put the privacy policy URL in Google Play?
In Google Play Console, go to Policy → App content → Privacy policy and paste the URL of the page hosting your policy. The page must be publicly accessible, not behind a login. Google Play also asks for a privacy policy link or text within the app itself, so add it to a settings or about screen as well.
Is a generated privacy policy legally valid?
Treat it as a starting template, not a finished legal document and not legal advice. A generator can only reflect the answers you give it, so its accuracy depends entirely on whether you ticked the right boxes. Google Play is explicit that you alone are responsible for making complete and accurate declarations about your app. If your app handles payments, health data, children's data or anything sensitive at scale, have a qualified lawyer review it.
What is GDPR and does it apply to my app?
The GDPR is an EU regulation. Article 3(2) extends it to controllers not established in the Union where processing relates to the offering of goods or services to data subjects in the Union — irrespective of whether payment is required — or to the monitoring of their behaviour within the Union. A free app listed globally on Google Play and running analytics can meet both limbs, so where you are based does not settle the question.
Does the CCPA apply to my small indie app?
Often not, but check rather than assume. The California Attorney General states the CCPA applies to for-profit businesses doing business in California that meet at least one threshold: gross annual revenue over 25 million dollars; buying, selling or sharing the personal information of 100,000 or more California residents or households; or deriving 50 percent or more of annual revenue from selling California residents' personal information. Note that GDPR has no equivalent revenue threshold, so a small app can fall outside CCPA and still be inside GDPR.
How do I host the policy so Google Play can link to it?
You need a public URL. Options: add a /privacy page to your website, publish via GitHub Pages, create a public GitHub Gist, or share a Notion page publicly. Paste your generated policy into any of these, open the URL in a private browser window to confirm it loads without a login, then submit it in Google Play Console.

Policy ready? Build your app.

Convert your website to a signed Android APK in about 60 seconds — no code required.

Build My App — Free →