A Google Play rejection for malicious behavior means Google's review flagged your app under its malware and unwanted-software policy, and for most legitimate developers the cause is a bundled third-party SDK that Google classifies as harmful, not the app's own code. The fix is usually to identify and remove or replace the flagged SDK, update to a clean version, and remove any behavior that resembles malware, such as dynamic code loading. If you are confident the flag is a genuine mistake, you can appeal through the Play Console with specifics, but when a flagged SDK or behavior is the real cause, fixing it and resubmitting is faster than appealing.
Short answer
A malicious behavior rejection flags your app under Google's malware policy, and the usual culprit is a third-party SDK Google treats as harmful. Per Google's Developer Program Policies, apps must not contain malware or mobile unwanted software, and per Google's PHA categories, certain SDK behaviors qualify. Read the notice to identify the cited SDK or behavior, remove or update it, and remove patterns like dynamic code loading. Then resubmit. If you believe the flag is a false positive, appeal through the Play Console Policy Center with concrete evidence, but for a genuinely flagged SDK, removing it is the faster path than an appeal.
What "malicious behavior" means
A malicious behavior rejection is Google applying its malware and unwanted-software policy, which prohibits apps that behave like malware, spyware, or unwanted software. This covers a range of behaviors, from hidden data collection and click fraud to code that resembles a trojan or backdoor. The rejection means Google's review, which combines automated analysis and human review, judged your app or something in it to fall under that policy.
For a legitimate app, this is usually not about your own code being malicious. It is far more often that something bundled in the app, most commonly a third-party SDK, exhibits behavior Google classifies as harmful, so the whole app inherits the flag. Understanding that framing points you at the right place to look: not necessarily a flaw you wrote, but a component you included that carries the problematic behavior.
SDK issues: the most common cause
A flagged third-party SDK is the most common reason a legitimate app is rejected for malicious behavior. Advertising, analytics, and monetization SDKs are the usual sources, because some collect data or behave in the background in ways Google classifies as unwanted software or a potentially harmful application. When you bundle such an SDK, its behavior becomes your app's behavior in Google's eyes, and the app is rejected even though your own code is fine.
The fix is to audit your SDKs and address the flagged one. Identify which SDK is the cause, checking the rejection notice, which sometimes names the offending component or behavior, and your dependency tree, including transitive dependencies you may not have added directly. Then remove the SDK, replace it with a clean alternative, or update it to a version that no longer exhibits the flagged behavior. Removing the problematic SDK is what actually clears the rejection in most cases.
Other triggers
Beyond a flagged SDK, a few of your app's own behaviors can trigger the policy. Dynamic code loading, where the app downloads and executes code at runtime, resembles how malware evades review and is a common cause. Requesting dangerous permissions the app cannot justify, combined with background behavior, can look harmful. Heavy obfuscation, hidden or deceptive functionality, and collecting or transmitting data without disclosure also fall under the policy.
Address these by removing the malware-like patterns. Do not load and execute code at runtime, remove permissions you cannot justify, disclose and minimize any data collection, and avoid hiding functionality from the reviewer or the user. Even when an SDK is not the cause, these behaviors are what the policy targets, so bringing your own code in line with it is part of resolving and preventing the rejection.
How to fix it
Fixing the rejection follows a clear sequence. Read the enforcement notice in your Play Console to identify the specific policy and, where given, the cited SDK or behavior, since that tells you what to change. Then audit your app: check your SDKs, including transitive dependencies, and your code for the behaviors the policy targets, and remove or replace whatever is causing the flag.
Once you have removed the flagged SDK or behavior, resubmit the corrected build. Address the specific cause rather than making broad changes, and if the notice named a component, make sure that component is genuinely gone from the build you resubmit. In most cases, removing the problematic SDK or malware-like behavior and resubmitting is the direct route back, and it is faster than an appeal when the flag reflects a real issue.
How to appeal
If you are confident the rejection is a false positive, meaning your app does not contain the flagged behavior, you can appeal rather than change the app. Google provides an appeal path through the Play Console, linked from the enforcement notification and the Policy Center, where you explain why the flag was applied in error. Submit a single, specific appeal that names the cited policy and gives concrete evidence that your app complies.
Choose appealing carefully. If a flagged SDK or a real behavior is the cause, an appeal on a genuinely problematic app rarely succeeds, and fixing the issue is faster. Reserve the appeal for cases where you can demonstrate the app is clean, for example that the flagged behavior comes from a component you have already removed or that the detection is mistaken. Make the case factual and evidence-based rather than a general assertion that the app is safe.
Causes and fixes
Matching the cause to a fix keeps you from appealing when you should be removing. The table below pairs the common causes with their fixes.
| Cause | What triggers it | Fix |
|---|---|---|
| Flagged third-party SDK | An SDK classified as harmful or unwanted software | Remove, replace, or update the SDK |
| Dynamic code loading | Downloading and executing code at runtime | Remove runtime code loading |
| Unjustified dangerous permissions | Harmful-looking background behavior | Remove or justify the permissions |
| Hidden or deceptive behavior | Undisclosed collection or functionality | Disclose, minimize, and remove hidden behavior |
| False positive | The app is wrongly flagged | Appeal with specific evidence |
Read the table against the cited policy in your notice. Most legitimate-app rejections are a flagged SDK to remove, and only a genuinely clean app that was misjudged calls for an appeal.
Fix checklist
Working through the rejection methodically resolves it. The checklist below covers the steps.
| Check | Action | Done? |
|---|---|---|
| Read the notice | Identify the cited policy, SDK, or behavior | [ ] |
| Audit SDKs | Find and remove or update the flagged SDK | [ ] |
| Remove dynamic loading | Stop downloading and running code at runtime | [ ] |
| Resubmit | Submit the corrected build | [ ] |
| Appeal if wrong | Appeal with evidence only for a genuine false positive | [ ] |
The two that resolve most cases are auditing the SDKs to find the flagged one and removing malware-like behaviors like dynamic code loading. Fix the specific cause and resubmit, and reserve the appeal for a genuinely mistaken flag.
Prevent it with a scan
Because a flagged SDK or a malware-like behavior is usually the cause, catching it before submission avoids the rejection entirely. This is hard to do by eye, especially when an SDK is pulled in as a transitive dependency you did not add directly, or when a behavior is buried in a bundled component.
A scanner like PTKD.com analyzes your app build and reports findings ordered by severity and mapped to OWASP MASVS, including risky third-party code, over-broad permissions, and other issues that draw a malicious-behavior flag, so you can see what your app actually contains before you submit. To be clear about the boundary: PTKD does not file your appeal or clear a Google rejection. It helps you find and remove the SDK or behavior that would trigger the flag in the first place.
What to take away
- A malicious behavior rejection applies Google's malware policy, and for legitimate apps the cause is usually a flagged third-party SDK, not your own code.
- Audit your SDKs, including transitive dependencies, and remove, replace, or update the one Google classifies as harmful.
- Remove malware-like behaviors such as dynamic code loading, unjustified dangerous permissions, and hidden or deceptive functionality.
- Fix the cited cause and resubmit; appeal only for a genuine false positive, with concrete evidence that the app is clean.
- Catch a flagged SDK or behavior before submission by scanning your build with PTKD.com.
