Google Play Deceptive Behavior Policy: Find What Was Flagged, Fix It and Get Back on Play

What the Deceptive Behavior policy actually covers

Deceptive Behavior sits in the "Privacy, Deception and Device Abuse" area of the Google Play Policy Center. The core rule: Google doesn't allow apps "that attempt to deceive users or enable dishonest behavior", including apps "determined to be functionally impossible". Apps also must not "mimic functionality or warnings from the operating system or other apps". It covers your store listing and the app itself, including third-party SDKs, ads and services.

As of October 2026, the policy has five parts:

Two points catch developers out. First, labels don't help: Google states that calling an app a "prank" or "for entertainment purposes" doesn't exempt it. Second, the policy has close neighbors. Copying another company's logo or app, or using a national emblem to imply government ties, is an example in the separate Impersonation policy. Concealing who owns the app or faking its country of origin falls under Misrepresentation. Ads that simulate system notifications or warnings also break the Ads policy.

Common reasons apps get flagged for deceptive behavior

• Functionality that doesn't match the listing. Screenshots of features that aren't built yet, a racing-game listing for a puzzle game, or an "antivirus" that only contains text tips. The last two are Google's own examples.
• Impossible claims. Google names insect repellent and phone breathalyzer apps. Typical variants seen in practice: "Boost RAM by 80%", "repair battery cells", "cool down your CPU", a fingerprint lie detector, an "X-ray camera".
• Fake system UI. Dialogs, notifications or ads styled as Android or Play Protect warnings ("Your phone is infected – tap to clean"), sometimes served by an ad creative rather than your code.
• Unclear government affiliation. A ministry's name, a coat of arms or words like "official" on a private app, or offering government services without authorization. Emblems and copied logos can trigger the Impersonation policy at the same time.
• Personal data of other people. "Number tracker" or caller-lookup apps that show real phone numbers, addresses or other personal data of people who haven't consented.
• Unconsented device changes. Adding home-screen shortcuts, changing the wallpaper, default browser or search settings, or urging users to uninstall "harmful" competitor apps.
• Review-dependent or hidden behavior. Remote-config flags that unlock features after approval, undisclosed country-only features, cloaking that detects the review environment, or features designed to activate later.
• Wrong category or content rating, such as questionnaire answers that understate violence.

Rejected or stuck? Talk to an App Specialist – for free.

Book a free consultation call: we look at your rejection or setup, explain the fastest way forward and tell you honestly whether you need us. Prefer to hand it off? Book our AI-powered + human-powered service and we take care of it.

Free consultation call Book our service →

How to find which element triggered the rejection

Deceptive Behavior is broad, so don't guess.

1. Open Policy status. In Play Console, select the app and choose Policy status in the left menu. According to Google's help page, it shows any active enforcement – rejection, removal or suspension – plus any additional information available. Also check your Play Console inbox and email.
2. Read the issue area. The email and issue details often say "We found an issue in the following area(s)" and name it: title, short or full description (often with a locale such as en-US), icon, screenshots, promo video or the in-app experience. Exact labels vary. Save any attached screenshot; it can show the exact screen or ad.
3. Map the area to the policy part. A listing area usually points to Misleading Claims, an in-app screenshot of a dialog or ad to mimicked system UI, a note about country-dependent features to Enabling Dishonest Behavior, and hidden features or review evasion to Behavior Transparency.
4. Check every listing variant: all translations, custom store listings and store listing experiments. A machine-translated description can still contain a claim you deleted from the English original long ago.
5. Reproduce the in-app path like a reviewer. Fresh install, the test login from Sign-in details on the App content page, live ads switched on, and, if you geo-target, a test from another country.

How to fix a Deceptive Behavior rejection step by step

1. Describe what the app really does in one sentence. Audit the title, descriptions, icon, feature graphic, screenshots and video against it. Remove every feature that isn't in the current build and every claim you can't demonstrate.
2. Rewrite claims as observable actions. "Deletes cache and duplicate files you select" instead of "speeds up your phone". "Shows battery health and opens Battery Saver settings" instead of "extends battery life by 50%".
3. Remove system look-alikes. Dialogs, notifications and overlays should clearly come from your app (its name and icon), avoid Android or Play Protect branding and never raise alarms your app can't actually detect.
4. Audit your ads. Block creatives that mimic system alerts in your ad network's controls, such as the AdMob Ad review center.
5. Add consent and an undo to every device change (see the technical fixes below).
6. Disclose variable behavior. If features differ by country or device, say so prominently in the listing. Remove remote flags that switch on features the reviewer never saw.
7. Correct category and content rating: the category in Grow users > Store presence > Store settings, the rating via the content rating questionnaire on the App content page (Policy and programs > App content).
8. Ship a clean build if the in-app experience was flagged: a new release with a higher versionCode on every track that carries the old bundle (production, open, closed and internal testing), with the non-compliant bundle in the "Not included" section. Google's resubmission steps warn that the resubmission fails if a non-compliant bundle stays active.
9. Update "What's new". Apps that change significantly between versions without telling users are a listed violation.
10. Send for review from Publishing overview. A listing-only fix usually needs no new bundle: save every affected listing and send the changes for review.

High-risk app types and compliant alternatives

These app types are especially exposed, because their usual marketing claims are exactly what the policy targets:

Government-affiliated apps are a special case. Google's requirements for apps that communicate government information say that if your app is authorized to facilitate a government process, such as voting or ID validation, Google may ask for proof of that permission before approval, and this documentation must be submitted by the government entity itself. Every app also needs a completed Government apps declaration on the App content page (Policy and programs > App content).

Device settings, fake system UI and hidden features: technical fixes

Device settings changes

• Prefer system-mediated APIs that show their own confirmation: RoleManager.createRequestRoleIntent() for default browser, home, dialer or SMS roles, ShortcutManager.requestPinShortcut() for home-screen shortcuts, and the Settings.ACTION_MANAGE_WRITE_SETTINGS screen before writing system settings.
• Explain the change first, then ask – never silently on first launch – and offer an undo in your settings screen.
• Never change settings, bookmarks or shortcuts as a service for an advertiser or partner. The policy lists this as a separate prohibition, so user consent doesn't make it acceptable.

Notifications and dialogs

• Name notification channels after what they do, use your own small icon and app name, and never imitate "Android System", Play Protect or low-battery warnings.
• Avoid SYSTEM_ALERT_WINDOW overlays that look like OS dialogs.

Hidden features and review evasion

• Don't branch on review-environment signals – Google IP ranges, emulator checks, the firebase.test.lab system setting used on Test Lab devices, or the review account – to change features or content. Google's policy asks that your app behave identically for a regular user and a reviewer.
• Use remote config for tuning, not for unlocking unreviewed features. Downloading executable code (dex, JAR, .so) from outside Google Play also violates the Device and Network Abuse policy.
• Don't build undocumented features that are switched on remotely or after a set time, and don't hide your launcher icon after installation.
• Install-time asset packs (Play Asset Delivery) arrive with the app. The policy requires a prompt with the download size before downloading additional resources, and names CDN downloads without one as a violation. The safe reading: for anything your app fetches later, from on-demand packs or your own CDN, prompt the user and show the size first.

Responding: fix and resubmit, or appeal?

Google's guidance on policy outcomes says not to republish a rejected or removed app until the violation is fixed. After a rejected update, your last published version stays live; after a removal, the app is unavailable until a compliant update is submitted. Repeated rejections or removals can lead to a suspension, which counts as a strike against your developer account.

Fix and resubmit when the flagged element is yours to change: a claim, a screenshot, an ad, a dialog.

Appeal via the Policy status page or the link in the email when you believe the decision is wrong and can prove it:

• You are authorized to use an organization's name or the word "official" – attach the license or authorization letter.
• Your app is government-affiliated – make sure the government entity has submitted proof of permission and your declaration is complete.
• The supposedly impossible feature really works – explain the method and attach a screen recording.

As of October 2026, Google allows one appeal per enforcement action and responds to appeals only in Chinese, English, Japanese and Korean, so make it complete the first time. If the listing was the problem, our store listing metadata guide covers icons, screenshots and keyword rules in more depth.

How to prevent deceptive behavior flags

• Treat listing copy like code. Keep store texts in your repository, for example in fastlane supply metadata folders (full_description.txt, short_description.txt), so every claim change is reviewed in a pull request across all locales.
• Keep a claims sheet that maps every promise in your listing to a screen in the current build. Screenshots generated from the release build in CI can't show features that don't exist.
• Lint for risky words in CI: "official", "boost", "repair", "100%", "virus detected", government and competitor names.
• Document feature flags and remove any that change core functionality by country or after approval.
• Check permission-heavy features such as accessibility, all-files access and package visibility against our sensitive permissions guide. Cleaner and security apps often hit both policies.

AI-assisted checks are good at the repetitive part: comparing listing claims with screenshots and app strings in every language, and flagging system-like wording. A human still decides what is honest and how to phrase it. appsubmitter.io combines both in your CI/CD and Google Play submission workflow – start with a free consultation call or book the Android service.

Template: how to reply to the Google Play review team

Adapt this template to your situation. Keep it factual, short and specific – and only claim what you have actually changed.

Subject: [Appeal / Policy question] – [App name] ([package name]) – Deceptive Behavior policy

Hello Google Play team,

On [date], [App name] ([package name], version code [version code]) was [rejected / removed] under the Deceptive Behavior policy. The issue details named: [area as shown in Policy status, e.g. full description (en-US) or in-app experience].

[Option A – you fixed the issue and want to document the changes, e.g. when Google asks for details]
We reviewed our store listing and app against the policy and made these changes:
- Listing: removed the claim "[old claim]". The description now says "[new wording]".
- App: removed the [dialog / notification / ad format] that resembled a system warning.
- Device settings: the app now asks for consent before [change] and can undo it under [Settings > menu].
The new version code is [new version code]. The non-compliant bundle is deactivated on all tracks, and all [number] localized listings were updated.

[Option B – appeal, if you believe the decision is wrong]
We believe the app complies because [reason]. Evidence:
- [Authorization letter / license from [organization], attached]
- [Screen recording showing how [feature] works: link]

[Only if true:] The app behaves identically for reviewers and users, and no features are unlocked by review detection or remote flags.

We would appreciate a re-review. Please let us know if you need further information.

Kind regards,
[Your name], [Company] – [contact email]

Checklist before you resubmit

• You identified the exact area named in the Policy status details and the email, including the locale.
• Title, short description, full description, icon, screenshots and video show only features present in the submitted build.
• Every translation, custom store listing and running store listing experiment was checked for the same claims.
• No claim promises an impossible or unmeasurable result such as boosting RAM, repairing batteries or detecting lies.
• No dialog, notification, overlay or ad imitates Android, Google Play Protect or another app.
• Every device setting change is explained first, needs explicit user consent and is easy for the user to undo.
• The app behaves the same for reviewers and users, and any country- or device-dependent core functionality is prominently disclosed in the listing.
• If the app edits or generates media, the output carries a clear watermark or disclaimer and store assets do not use public figures or sensitive events to advertise it.
• Organization names, logos and "official" or government wording are backed by written authorization or removed.
• App category and content rating answers match the actual app.
• If the app changed, the new bundle has a higher versionCode, the old bundle is deactivated on all tracks and "What's new" describes the changes.

Frequently asked questions

Official source: Google Play Policy Center – Deceptive Behavior. Store policies change regularly – always check the current version. This guide is independent advice and not affiliated with Apple or Google.