A "Blocked by Play Protect" red warning means Google Play Protect judged the app potentially harmful during install, often because it was sideloaded, signed with an unfamiliar key, requests dangerous permissions, or bundles an SDK flagged as unwanted software. For your own app during testing, the reliable fix is to distribute through Play's internal or closed testing tracks with Play App Signing instead of a raw APK. If your published app was wrongly flagged, you can appeal through the Play Console. Auditing the permissions and third-party SDKs your app includes is usually where the real cause is found.
Short answer
"Blocked by Play Protect" is a security warning, not a review status: Google Play Protect scans apps at install and blocks or warns on ones it considers potentially harmful. Per Google's Play Protect documentation, it flags apps that behave like malware or request sensitive access without justification, and it is more cautious with rarely-installed, sideloaded apps. The common developer causes are a raw sideloaded APK, a new signing certificate, dangerous permissions, or a suspicious bundled SDK. Fix it by distributing through Play testing tracks with Play App Signing, minimizing dangerous permissions, and auditing your SDKs. If you believe the warning is wrong, submit an appeal through the Play Console.
What "Blocked by Play Protect" means
Play Protect is Google's built-in malware protection on Android, and it scans apps as they install, whether they come from the Play Store or are sideloaded. The red "Blocked by Play Protect" screen means it judged the app potentially harmful and stopped the install, while a softer warning lets the user proceed at their own risk. Either way, it is a security signal, not a Play Store review decision.
The distinction matters for developers. A Play Protect warning during your own testing is about how the app looks to an on-device scanner, not about your Console submission status. That means the fixes are different: you change how the app is distributed, signed, and built, rather than waiting on a review queue to clear. It also means the warning can appear even for an app that passed Play review, because the two systems check different things at different moments.
Why your own app triggers it
The most common reason a legitimate app in development trips Play Protect is that it is a raw APK from an unknown source with almost no install base. Play Protect is deliberately cautious about apps it has rarely seen, signed with a certificate it does not recognize, especially when they are sideloaded rather than delivered through Play. A debug build or a freshly generated signing key makes this more likely.
Beyond that, the app's own behavior can trigger it. Requesting dangerous permissions the app cannot obviously justify, bundling a third-party SDK that Google classifies as unwanted software, or using patterns associated with malware such as heavy obfuscation or dynamic code loading all raise the app's risk profile. The warning is the scanner reacting to one or more of these signals, not a random error. Identifying which signal applies to your build is the difference between a quick fix and a long guessing game.
Suspicious SDKs and permissions
A frequent hidden cause is a third-party SDK. Some advertising, analytics, or monetization libraries are classified as potentially harmful or as mobile unwanted software because of how they collect data or behave in the background, and bundling one can get your whole app flagged. Audit every SDK you include, check it against Google's unwanted-software criteria, update to a clean version, or remove it if it is the trigger.
Permissions are the other half. Sensitive permissions such as SMS access, accessibility services, device administration, or the ability to install packages draw scrutiny, and requesting them without a clear, policy-compliant reason looks like harmful behavior to Play Protect. Remove any dangerous permission you do not truly need, and make sure the ones you keep have an obvious, legitimate purpose in the app. A permission that is present only because a template or an unused SDK requested it is worth removing entirely, since it adds risk without adding value.
How to submit an appeal
If Play Protect flags your published app and you believe it is wrong, you appeal through Google rather than editing the warning away. Google notifies you of a harmful-app or policy classification in the Play Console, and the Policy Center and the associated notice provide the path to request a review or dispute the finding. Submit the appeal there, explaining what the app does and why the flagged behavior is legitimate.
Make the appeal concrete. Identify the specific behavior or SDK that was flagged, describe its purpose, and note any change you have made, such as removing a library or a permission. An appeal that simply asserts the app is safe is weaker than one that names the trigger and shows it is either justified or already fixed. While the appeal is open, keep a clean, updated build ready so you can ship the moment it is resolved.
The common triggers
Most Play Protect blocks trace to a short list of triggers. The table below maps each to why the scanner reacts and the direction of the fix.
| Trigger | Why Play Protect reacts | Fix direction |
|---|---|---|
| Sideloaded unknown APK | Low install base, unverified source | Distribute via Play testing tracks |
| New or changed signing key | Certificate it does not recognize | Use consistent Play App Signing |
| Dangerous permissions | Sensitive access without justification | Remove or justify, and minimize |
| Suspicious SDK | Library flagged as unwanted software | Audit, update, or remove the SDK |
| Obfuscation or dynamic code | Behavior associated with malware | Remove hidden or dynamic loading |
Match your case to a row before acting. A sideloaded test build usually needs a distribution and signing change, while a published app flagged as harmful usually needs an SDK or permission fix plus an appeal, not a change to how you distribute.
How to fix it
Work through the likely causes in order rather than guessing. The checklist below moves from distribution and signing to the app's own contents and, last, an appeal.
| Check | Action | Done? |
|---|---|---|
| Distribution | Ship via Play internal or closed testing, not a raw APK | [ ] |
| Signing | Use Play App Signing with a consistent key | [ ] |
| Permissions | Remove dangerous permissions you cannot justify | [ ] |
| SDK audit | Identify and replace or remove a flagged SDK | [ ] |
| Appeal | Submit through the Play Console if wrongly flagged | [ ] |
For a testing build, the single most effective step is to stop sideloading a raw APK and instead distribute through Play's internal or closed testing with Play App Signing, which gives testers a recognized, Play-delivered install. For a published app, the effective step is finding and removing the flagged SDK or permission, then appealing with that fix described.
Prevent it before release
The best time to catch a Play Protect trigger is before you ship, since a flag after release costs you installs and an appeal. The two most common triggers, dangerous permissions and suspicious SDKs, are exactly the kind of issue a security review surfaces, and they are easy to miss when an SDK is pulled in as a transitive dependency.
A scanner like PTKD.com analyzes your app build and reports findings ordered by severity and mapped to OWASP MASVS, including over-broad permissions and risky third-party code, so you can address them before Play Protect does. To be clear about the boundary: PTKD does not submit your appeal or change a Play Protect verdict. It helps you find and fix the permission and SDK issues that most often cause the warning in the first place.
What to take away
- "Blocked by Play Protect" is an on-device security warning, not a Play Store review status.
- Your own app usually triggers it as a rarely-seen sideloaded APK with an unrecognized signing key, so distribute via Play testing with Play App Signing.
- Dangerous permissions and SDKs classified as unwanted software are the most common behavioral causes; audit and minimize both.
- If a published app is wrongly flagged, appeal through the Play Console and name the specific trigger and any fix you made.
- Catch permission and SDK issues before release by scanning your build with PTKD.com.
