If Google Play Protect flags your legitimate app as malware, and you have confirmed it complies with Google's Unwanted Software and malware policies, you can appeal the classification through the File an appeal option in your Play Console. The appeal goes to Google's security team, which re-evaluates the app, so the most effective thing you can do first is find and remove whatever tripped the automated detection, most often a third-party SDK that resembles a potentially harmful application. Scan your app and its SDKs, remove or replace the flagged component, and then appeal with a clean build.
Short answer
A Play Protect false positive means the automated classifier flagged a compliant app as harmful, and you appeal it rather than change how you distribute. Per Google's developer guidance for Play Protect warnings, if you conclude your app is not a potentially harmful application and complies with the Unwanted Software and Software policies, you can request an appeal using the File an appeal button, and Google reinstates apps when an error was made. Before appealing, identify what triggered the flag, usually a third-party SDK or a malware-like pattern such as obfuscation or dynamic code loading, and remove it. Then file one appeal, in English, with a clean build.
What a Play Protect false positive is
A Play Protect false positive is when Google's on-device and cloud classifier warns about or blocks a legitimate app that does not actually contain malware. Play Protect uses automated analysis, including machine learning, to detect potentially harmful applications, and like any classifier it can be wrong, flagging behavior that resembles a threat even when the app is safe. For a legitimate business app, that is a false positive rather than a real detection.
Recognizing it as a classification error shapes your response. You are not trying to hide anything or change your distribution; you are asking Google to correct a mistaken judgment about a compliant app. That means two things go together: confirming and demonstrating that your app really does comply with Google's policies, and identifying what about the build made the classifier think otherwise. Both matter, because an appeal is strongest when the app is clearly compliant and the triggering pattern has been removed.
How to contact humans and file the appeal
To reach Google's reviewers, use the appeal path Google provides rather than trying to find a back channel. Per Google's guidance, if you believe the app verifier incorrectly blocks your app or warns users, you appeal the classification by clicking the File an appeal button, which is available through your Play Console account. The appeal is reviewed by Google's security team, which re-evaluates the app, so this is how a human ends up looking at your case.
A few conditions apply. Appeals for Play Protect classifications are responded to in English at this time, so write in English. You may submit one appeal per enforcement action, so prepare before you file. If you do not have direct access to the Play Console account, request help from the Help page or ask your account admin for an invite. Make the appeal specific: state that the app complies with the Unwanted Software and Software policies, and describe what you have verified or changed, so the reviewer has concrete grounds to correct the classification.
Why legitimate apps get flagged
Legitimate apps get flagged when something in the build resembles the behavior of a potentially harmful application. The most common trigger is a third-party SDK, such as an advertising, monetization, or analytics library, that behaves in ways the classifier associates with unwanted software or a PHA, so your safe app inherits the suspicious behavior of a component you bundled. This is why a false positive often has nothing to do with your own code.
Other triggers come from patterns that also appear in real malware. Heavy obfuscation or packing can resemble how malware hides itself, dynamic code loading resembles how malware evades review, and requesting sensitive permissions alongside background behavior can look harmful. Prompts that push sideloading or self-updating outside the store can resemble unwanted software. None of these are malicious on their own, but together with an automated classifier they raise the odds of a false positive, which is why identifying and reducing them is the practical core of resolving one.
Third-party SDK scans
Because a bundled SDK is the most common trigger, scanning your third-party SDKs is the highest-value step, and it is often the difference between a guessed appeal and a confident one. You need to know which component the classifier reacted to, including transitive dependencies you did not add directly, since those are easy to miss when you review only your own manifest and code. A scan surfaces the risky third-party code so you can act on it rather than speculate.
Once you identify a flagged SDK, remove it, replace it with a cleaner alternative, or update it to a version that no longer exhibits the behavior. Doing this before you appeal serves two purposes: it removes the trigger so the classifier is less likely to flag the rebuilt app, and it gives you something concrete to state in the appeal, namely that you found and removed the component that resembled a PHA. An appeal backed by a real fix is stronger than one that only asserts the app is safe.
Strengthen the appeal with evidence
The most persuasive appeal pairs a compliant app with evidence of what you did. Rather than only asserting that your app is safe, describe the specific steps you took: the SDK or pattern you identified, how you removed or changed it, and the confirmation that the app meets the Unwanted Software and Software policies. Reviewers can act on specifics they can verify far more readily than on a general claim of innocence.
Keep the appeal factual and concise. Reference the app and the warning, state your compliance clearly, and summarize your remediation without emotional language or demands. Because you get one appeal per action, gather this evidence before you file rather than sending a thin version and hoping. If the flag genuinely came from a coincidental pattern rather than any component you can change, say so factually and point to the app's compliance, but in most cases there is a concrete trigger to identify and cite.
Root causes and fixes
Matching the trigger to a fix keeps your appeal grounded in a real change. The table below pairs common causes with their fixes.
| Cause | Why Play Protect flags it | Fix |
|---|---|---|
| Flagged third-party SDK | The SDK resembles a PHA or unwanted software | Scan, then remove or replace the SDK |
| Heavy obfuscation or packing | It resembles malware hiding itself | Reduce obfuscation and avoid packers |
| Dynamic code loading | It resembles malware evading review | Remove runtime code loading |
| Sensitive permissions with background behavior | It looks harmful | Remove or justify the permissions |
| Sideload or self-update prompts | It resembles unwanted software | Follow the Unwanted Software Policy |
Read the table against your build. Most false positives trace to the top rows, especially a third-party SDK, which is why a scan comes before the appeal.
Appeal checklist
Working through the steps in order gives you a clean build and a strong appeal. The checklist below covers them.
| Step | Action | Done? |
|---|---|---|
| Confirm compliance | App meets the Unwanted Software and Software policies | [ ] |
| Scan SDKs | Find and remove the flagged component | [ ] |
| Rebuild clean | Produce a build without the trigger | [ ] |
| Gather evidence | Note the trigger and your remediation | [ ] |
| File the appeal | Use the File an appeal button, in English | [ ] |
| One submission | Submit a single appeal per action | [ ] |
The step that most improves your odds is the scan: knowing and removing the exact trigger turns an assertion of innocence into a demonstrated fix.
Scan before you appeal
Because the trigger is usually a component you can find, scanning the build before you appeal is the practical foundation of the whole process. Guessing at which SDK the classifier reacted to wastes your single appeal; identifying it lets you remove it and cite the fix.
A scanner like PTKD.com analyzes your build and reports issues such as risky third-party code, embedded secrets, and over-broad permissions by severity, mapped to OWASP MASVS, so you can see which components resemble a potentially harmful application and address them before you file. To be clear about the boundary: PTKD does not control Google's classifier, submit your appeal, or guarantee reinstatement. It helps you find and remove the trigger so your appeal rests on a genuinely clean build.
What to take away
- A Play Protect false positive is a classification error on a compliant app, which you appeal through the File an appeal option in Play Console rather than changing your distribution.
- The appeal is reviewed by Google's security team, is answered in English, and is limited to one submission per action, so prepare before you file.
- Legitimate apps are usually flagged by a bundled third-party SDK or a malware-like pattern such as obfuscation or dynamic code loading, not by your own code.
- Scan your app and its SDKs, including transitive dependencies, to find and remove the trigger, then appeal with a clean build and cite the fix.
- Use a scanner like PTKD.com to identify the component that resembles a PHA so your appeal rests on evidence rather than assertion.
