Google Play Policy Compliance: Data Safety & Permissions

When you ship an update to Google Play and get a "Rejected" email, the clock usually starts running backward: which policy, which screen, which form field. This guide walks through filling out the Data Safety form field by field, sensitive-permission declarations, the account/data deletion requirement, and subscription transparency rules — using the exact wording from Google's own Play Console Help pages — so you don't repeat the same violation on your next submission.

💡 Pro Tip: Update the Data Safety form not before every release, but whenever a change alters your data-collection behavior (a new SDK, a new permission, a new analytics plugin) — a mismatch between the form and actual behavior is, on its own, grounds for rejection.

Table of Contents

• The Play Policy Ecosystem: Where to Start
• The Data Safety Form: Filling It Out Field by Field
• Sensitive Permissions and the Restricted Permissions Declaration
• The Account and Data Deletion Requirement
• Subscription and Billing Policies
• Common Violation Examples and Fixes
• Resubmitting a Rejected App
• Pre-Launch Compliance Checklist
• FAQ
• How do you correctly fill out the Data Safety form?
• Why was my app rejected on Google Play?
• How do you declare a sensitive permission (SMS, location, accessibility)?
• Who does the account deletion requirement cover?
• Update (September 2026)
• Conclusion
• Sources

The Play Policy Ecosystem: Where to Start

Google Play's policies aren't a single document; they're several interlocking layers: the Developer Program Policies (the general framework), Data Safety requirements, the Permissions policy, the User Data policy, and category-specific rules (finance, health, kids). An app is typically subject to several layers at once — for example, an app requesting a sensitive permission must comply with the Permissions policy, the User Data policy, and the Data Safety form all at the same time.

The practical takeaway: a violation is usually not one rule but an inconsistency between two layers. If the feature you declare on your store listing doesn't match the permission your app actually requests, or an SDK sends a data type you told the form you "don't collect," you get rejected.

The cheapest way to catch this before submission is extracting your dependency list from the command line rather than reviewing it by hand. The command below lists every transitive dependency in your project; match each line against that SDK's own privacy documentation and carry it into the form.

1# Extract all release dependencies (including transitive) into one file
2./gradlew app:dependencies --configuration releaseRuntimeClasspath > deps-release.txt
3 
4# Filter for SDKs likely to collect data — ads/analytics/crash-reporting
5grep -Ei 'ads|analytics|crashlytics|firebase|facebook|adjust|appsflyer' deps-release.txt

Producing this list before filling out the form significantly reduces the odds you'll need to correct it a second time — you work from a concrete checklist instead of trying to remember every SDK's behavior.

The Data Safety Form: Filling It Out Field by Field

The Data Safety form is required for every release track except apps that are active only on the internal testing track. In Google's own words: "Apps that are active on internal testing tracks are exempt from inclusion in the data safety section." In other words, every release that goes out on closed testing, open testing, or production must complete the form.

Even an app that collects no data at all is not exempt from this obligation. Google states explicitly: "Even developers with apps that do not collect any user data must complete this form and provide a link to their privacy policy." Leaving the form blank or skipping it isn't an option — you still have to check "I don't collect data" and still add a privacy policy link.

The point most often missed when filling out the form is third-party SDKs. Google's policy is unambiguous: "This includes data collected and handled through any third-party libraries or SDKs used in their apps." An ad SDK, a crash-reporting tool, an analytics library — all of it falls under your declaration. "I don't collect that data, the SDK does" is not a valid defense.

Knowing what does _not_ count as "collection" matters just as much as knowing what does. There are three exceptions:

• On-device processing only: "User data accessed by your app that is only processed locally on the user's device and not sent off device does not need to be disclosed."
• End-to-end encryption: "User data that is sent off device, but that is unreadable by you or anyone other than the sender and recipient as a result of end-to-end encryption does not need to be disclosed."
• Service provider transfer: Transferring data to a "service provider" that processes it on your behalf does not count as sharing.

The one requirement for marking a data type as "optional" is that every user — regardless of device or region — must be able to either supply the information optionally, or opt out, or opt in. If you only offer an opt-out to users in a specific country, you cannot mark that field "optional" on the form.

Field-by-field classification on the Data Safety form can be summarized in this table:

Apps can also earn an independent security-review badge (MASA — Mobile Application Security Assessment); this is optional and paid for by the developer: "This is an optional review undertaken and paid for by developers. Through MASA (Mobile Application Security Assessment) developers can work directly with a Google Authorized Lab." It isn't mandatory, but it serves as a trust signal for finance/health apps handling sensitive data.

Sensitive Permissions and the Restricted Permissions Declaration

Google Play bans linking persistent device identifiers (IMEI, IMSI, SIM serial number) to personal/sensitive user data or to resettable identifiers: "Google Play prohibits linking persistent device identifiers (such as IMEI, IMSI, or SIM Serial #) to personal and sensitive user data or resettable device identifiers." Legacy integration patterns that depend on a persistent identifier run into this rule.

The scope of sensitive user data is broad, and per Google's definition includes: "personally identifiable information, financial and payment information, authentication information, phonebook, contacts, device location, SMS and call-related data, health data…" Any permission that accesses one of these categories falls under the Restricted Permissions policy.

There are two core rules for Restricted Permissions. First, the permission's use must be tied to an existing feature promoted on your Google Play store listing and must be "in-context": "You may only request permissions and APIs that access sensitive information that are necessary to implement current features or services in your app that are promoted in your Google Play listing." Second, a user's refusal cannot be circumvented through manipulation: "Respect users' decisions if they decline a request for a Restricted Permission, and users may not be manipulated or forced into consenting to any non-critical permission."

In practice, you set up an in-context permission request like this: the permission dialog does not appear until the user taps the relevant feature.

1// Request permission when the user taps "Share Location" — NOT at app launch
2button.setOnClickListener {
3    when {
4        ContextCompat.checkSelfPermission(
5            context, Manifest.permission.ACCESS_FINE_LOCATION
6        ) == PackageManager.PERMISSION_GRANTED -> {
7            shareCurrentLocation()
8        }
9        else -> {
10            requestPermissionLauncher.launch(Manifest.permission.ACCESS_FINE_LOCATION)
11        }
12    }
13}

This pattern solves two problems at once: it satisfies "in-context," and it makes the "purpose of location collection" field on the Data Safety form (e.g. "App functionality") concrete and defensible, since the request and the feature's actual use overlap in time.

The Account and Data Deletion Requirement

For every app that offers in-app account creation, Google defines two separate paths: "If your app enables account creation, you must: provide users with an in-app path to delete their app accounts and associated data; and provide a web link resource where users can request app account deletion and associated data deletion." A single web form is not enough — there must also be a deletion path inside the app itself.

Per Google's published timeline, the deadline for completing data-deletion questions was December 7, 2023; developers who requested an extension had until May 31, 2024. As of this article's original publish date (2025-02-10), the requirement is in full effect for every account-creating app. In practice you need two separate flows: a web page linked from your Play Store listing (accessible without the app installed), and an in-app menu item such as "Delete My Account" inside app settings.

Subscription and Billing Policies

Google Play requires transparency in every subscription offer: "You must be transparent about your offer. This includes clearly and explicitly disclosing your offer terms, the cost of your subscription, the frequency of your billing cycle, the automatic renewal terms, whether a subscription is required to use the app, and any other material information about the subscription." The items this policy lists must sit somewhere in the purchase flow that the user can see without taking any extra action.

The same policy also defines what a subscription model must deliver: "Subscriptions must provide sustained or recurring value to users throughout the life of the subscription, and may not be used to offer what are effectively one-time benefits to users (for example, SKUs that provide lump sum in-app credits/currency, or single-use game boosters)." Packaging a one-time digital product (say, a single PDF report) as a subscription violates this clause.

If you offer a trial or introductory price, failing to clearly disclose that it auto-converts to a paid subscription at the end of the period counts as a violation example: "Offers that do not clearly explain that the user will be automatically enrolled in a paid subscription at the end of the offer period." That disclosure needs to already be clearly written on the purchase screen before the user's trial ends and they return to it — a footnote or fine print isn't enough.

You can model the minimum transparency set your purchase screen needs to show like this:

1{
2  "offerTitle": "Monthly Plan",
3  "price": "$14.99 / month",
4  "billingCycle": "Renews automatically every month",
5  "trialPeriod": "7 days free, then converts to a paid subscription automatically",
6  "cancelInfo": "Cancel anytime from Play Store > Subscriptions"
7}

Common Violation Examples and Fixes

Google's policy pages don't publish a single numbered "most common rejection reasons" list; each policy defines its own violation examples on its own page. The table below collects the concrete examples that appear across Data Safety, User Data, and Subscriptions, with the matching fix — taken directly from the policy text, not statistics.

Misrepresenting the presence of ads carries a serious consequence: "If you misrepresent the presence of ads in your app(s), it's considered a violation of the Google Play policies and may result in your app(s) being suspended." This clause specifically spells out the suspension risk for apps that deliberately skip the "Contains ads" label.

Resubmitting a Rejected App

If an update gets rejected or your app gets removed, there's no need to panic — in Google's own words, the process can be completed without ever contacting support: "If your update is rejected or your app is removed, please follow the instructions below to resubmit your app for review. You can complete these steps without contacting or waiting for a reply from the policy support team." In other words, you don't have to open a support ticket and wait for a reply — you can fix the violation and resubmit directly.

In practice: the rejection email or the Policy Center panel tells you which policy was violated; you make the relevant change (updating the Data Safety form, removing a permission, adding a privacy policy link, etc.) and submit it as a new release. Google doesn't publish a committed turnaround time for re-review; you track status from the Policy Center panel.

A single violation often touches more than one policy at once, so fixing only the item named in the rejection email may not be enough — an incorrect permission declaration can violate Restricted Permissions and Data Safety simultaneously. Reviewing all relevant pages (Permissions, Data Safety, User Data) before resubmitting prevents a second rejection round.

The privacy policy requirement kicks in under two separate scenarios. For apps that request sensitive permissions or data: "For apps that request access to sensitive permissions or data... You must link to a privacy policy on your app's store listing page and within your app." For apps targeting children, the requirement applies just the same even without sensitive-data access: "For apps that target children: You must link to a privacy policy... regardless of your app's access to sensitive permissions or data."

Pre-Launch Compliance Checklist

The reward list above, unlocked with PLAYPOLICY7, was the detailed version; here's the same checklist in short form, for a quick pass before submission:

1. Is the Data Safety form current (after any SDK/permission change)
2. Is the privacy policy link on both the store listing and in-app
3. Are sensitive permissions requested only for a promoted feature
4. Is the account/data deletion path available both in-app and on the web
5. Does the subscription screen show price + renewal + cancellation info
6. Is the ad declaration ("Contains ads") correct

FAQ

How do you correctly fill out the Data Safety form?

One rule covers filling out the form: disclose every data type your app — and every third-party SDK inside it — sends off-device. In Google's own words, "This includes data collected and handled through any third-party libraries or SDKs used in their apps" — meaning ad, analytics, and crash-reporting libraries are part of your declaration too. Only data that stays on-device or is end-to-end encrypted is exempt from disclosure.

Why was my app rejected on Google Play?

The rejection email or the Policy Center panel names which policy was violated; examples listed in the policy text include a Data Safety form that doesn't match actual SDK behavior, a sensitive permission requested for a feature that isn't promoted, and subscription-transparency gaps. Google doesn't publish a numbered "most common rejection reasons" list; the fix starts with resolving the violation and resubmitting, in Google's own words, "without contacting or waiting for a reply from the policy support team."

How do you declare a sensitive permission (SMS, location, accessibility)?

Request the sensitive permission only for an existing feature promoted on your store listing, opening the permission dialog in-context — when the user taps that feature. If the user declines, don't try to override that decision through manipulation — Google explicitly bans this. The data type the permission accesses must also be declared on the Data Safety form.

Who does the account deletion requirement cover?

It covers every app that offers in-app account creation. These apps must provide both an in-app deletion path and a web link accessible without the app installed; both must be complete — a web link alone isn't enough.

Update (September 2026)

The body of this article reflects the policy state as of 2025-02-10. Between that date and today (2026-09-24), Google announced the following changes directly relevant to Data Safety and permission declarations:

• Announced 2025-03-05: Rules for sensitive health data accessed via Health Connect were tightened (support.google.com/googleplay/android-developer/answer/15931464).
• Announced 2025-10-30: A new Age-Restricted Content and Functionality policy was announced for age-restricted content (dating/gambling/matchmaking categories); developers were given 30 days from the announcement to comply (support.google.com/googleplay/android-developer/answer/16550159).
• Effective 2026-01-01 (announced Nov 19, 2025): Data-use restrictions for the Age Signals API take effect (support.google.com/googleplay/android-developer/answer/16706838).
• Compliance deadline 2026-01-28 (announced Dec 9, 2025): Compliance requirements were updated for alternative billing and external content links in the US (support.google.com/googleplay/android-developer/answer/16671517).
• Effective 2026-09-30: Under Android developer verification, registering Play apps in Play Console becomes mandatory; unregistered apps can be removed from Google Play (support.google.com/googleplay/android-developer/answer/10788890).

None of these changes altered the core logic of the Data Safety form, Restricted Permissions, or account-deletion rules described in the body of this article — the existing process still applies. Items like developer verification and Health Connect restrictions were added on top as separate, category-specific requirements.

Conclusion

Google Play policy compliance isn't a one-time check — it's a discipline you repeat with every SDK update and every new permission you add. Keep the Data Safety form in sync with actual behavior, request sensitive permissions only for a promoted feature and only in-context, provide both an in-app and a web deletion path for account-creating apps, and never bury the price and renewal terms on your subscription screen.

If you want to go deeper on related topics: for validating subscription infrastructure server-side, see the server-side receipt validation guide; for the Play Billing v7 migration, see the Google Play Billing v7 subscription guide; for Android 15's privacy changes, see the Android 15 privacy and Privacy Sandbox guide; for Health Connect integration, see the Health Connect Android integration guide; and for production Android architecture, see the Jetpack Compose 1.7 performance guide.

Sources

• Provide information for Google Play's Data safety section - Play Console Help — Data Safety form field definitions, exemptions, and the scope of the requirement.
• User Data - Play Console Help — Scope of sensitive user data and the device-identifier linking ban.
• Permissions and APIs that Access Sensitive Information - Play Console Help — Restricted Permissions and in-context permission-request rules.
• Account and data deletion - Play Console Help — Deletion-path requirement for apps with in-app account creation.
• Subscriptions policy - Play Console Help — Subscription transparency and sustained-value requirements.
• Prepare your app for review - Play Console Help — The resubmission process, privacy-policy link requirement, and ad declaration.
• Request runtime permissions - Android Developers — Method for requesting sensitive permissions in-context (when the user taps the feature).