On this page (8 sections)
How serious is a suspension?
| Rejected | Removed | Suspended | |
|---|---|---|---|
| Live app | Stays live | Taken down | Taken down |
| Can resubmit a fixed build | Yes | Yes | Not as a normal update — appeal first |
| Counts against the account | No | Not usually | Can count as a strike |
| Typical causes | Single policy issue | Policy issue in a published app | Egregious or repeated violations, deception, malware, impersonation, association |
Google’s Enforcement Process describes suspensions as reserved for serious or repeated violations. Read the notice for the specific policy cited and for any mention of prior warnings or associated accounts.
Why apps get suspended
- Repeated violations of the same policy after warnings or removals.
- Egregious violations: malware or unwanted software, deceptive behaviour, impersonation, intellectual property abuse, prohibited content, fraudulent or manipulated ratings and installs.
- Association with a previously suspended app or a terminated account — shared code, assets, payment details, devices or identities.
- Circumvention: republishing a removed app under a new package name or a new account.
Immediate actions
- Save everything. The notice, the Policy status page, screenshots, the exact build that was reviewed.
- Do not republish. Not under a new package name, not in another account, not as a “lite” version. That is treated as circumvention and is the fastest route to account termination.
- Identify the policy and the concrete trigger. Which SDK, permission, content, listing element or behaviour does the cited policy point to?
- Check your history. Previous warnings, removals or rejections for the same policy change the picture; so does any link to other accounts.
- Decide fix-and-appeal vs appeal-only. If the finding is correct, fix the app before appealing and say so. If it is wrong, prepare evidence.
Appealing a suspension
Suspension appeals go through the official appeal form linked from the notice or Play Console Help. A credible appeal:
- Names the cited policy and shows you understand what it prohibits
- States plainly whether the app violated it, and if so, exactly what has been changed (with build numbers)
- Attaches evidence: screenshots, screen recordings, licences, ownership or authorisation documents, SDK removal diffs
- Addresses associated-account concerns directly if the notice raises them
- Is short, factual and free of generic “our app is fully compliant” claims
Evidence must be real
Fabricated documents, doctored screenshots or invented testing data in a suspension appeal convert an app-level problem into an account-level one. If you cannot prove a point, do not claim it.
Account-level risk
Suspensions accumulate. Google can terminate a developer account after multiple suspensions, or after a single suspension for a sufficiently serious violation. If you publish other apps from the same account, review them against the same policy now — a second suspension for the same issue is far more damaging than the first.
What not to do
- Do not create a replacement app or account to get back online.
- Do not ask a friend or contractor to publish the same app from their account.
- Do not resubmit the same binary with a new version code.
- Do not hide the flagged behaviour behind a remote flag; that is deception, and it is detectable.
- Do not send multiple appeals with different stories.
Technical review before you appeal
If the suspension cites malware, unwanted software, deceptive behaviour or SDK conduct, a code-level review is the only way to know what actually happened. We inspect the flagged build, the SDKs and their network behaviour, identify the offending component and implement the fix, so the appeal can describe a concrete, verifiable change rather than a promise.
What to send us
- The suspension notice and Policy status text, exactly as written.
- Your enforcement history for the app and account.
- The build that was reviewed (or its source) and the list of SDKs.
- Any prior appeal text and Google’s responses.
Do not include passwords, signing keys, keystores, API secrets, recovery codes, payment credentials or personal data belonging to your users. We do not need any of these to review a rejection and we will ask you to remove them if they are included.