1. The policy in Google's own words. Google Play's Malware policy opens with one principle: "Our Malware policy is simple, the Android ecosystem including the Google Play store, and user devices should be free from malicious behaviors (for example, malware)." The definition is deliberately broad - "Malware is any code that could put a user, a user's data, or a device at risk. Malware includes, but is not limited to, Potentially Harmful Applications (PHAs), binaries, or framework modifications, consisting of categories such as trojans, phishing, and spyware apps, and we are continuously updating and adding new categories." The line that decides most enforcement cases is the scope sentence right after it: "The requirements of this policy also apply to any third party code (for example, an SDK) that you include in your app" (https://support.google.com/googleplay/android-developer/answer/9888380).
2. The six objectives Google tests against. Code is malicious if it does any one of the following: compromise the integrity of the user's device; gain control over a user's device; "enable remote-controlled operations for an attacker to access, use, or otherwise exploit an infected device"; "transmit personal data or credentials off the device without adequate disclosure and consent"; "disseminate spam or commands from the infected device to affect other devices or networks"; or defraud the user. One hit is enough - the list is a union, not a checklist.
3. "We didn't mean it" is not a defence. The policy states it outright: "An app, binary, or framework modification can be potentially harmful, and therefore can generate malicious behavior, even if it wasn't intended to be harmful... what is harmful to one Android device might not pose a risk at all to another Android device. For example, a device running the latest version of Android is not affected by harmful apps which use deprecated APIs to perform malicious behavior but a device that is still running a very early version of Android might be at risk." The practical consequence: intent is irrelevant, and an old minSdk/targetSdk widens exactly the surface that can be flagged.
4. The categories Play Protect actually screens for. Google Play Protect's Malware page enumerates its classifications: backdoors, billing fraud (SMS, call, toll), stalkerware, denial of service, hostile downloaders, non-Android threats, phishing, elevated privilege abuse, ransomware, rooting, spam, spyware, trojans, uncommon apps and riskware (https://developers.google.com/android/play-protect/phacategories). The backdoor rule is the one that pulls apps with no malicious intent at all: "A necessary condition for any code to be classified as a backdoor is that it enables behavior that would place the code into one of the other malware categories if executed automatically. For example, if an app allows dynamic code loading and the dynamically loaded code is extracting text messages, it will be classified as a backdoor malware. However, if an app allows arbitrary code execution and we don't have any reason to believe that this code execution was added to perform a malicious behaviour then the app will be treated as having a vulnerability, rather than being backdoor malware, and the developer will be asked to patch it." Read that as a rule: dynamic code loading survives review only when the fetched payload is provably benign; DCL combined with reading sensitive data is a backdoor.
5. Third-party SDK liability sits with you, not the SDK vendor. The Malware page's Do/Don't list names the four ways an SDK destroys an app: "Ensure third-party SDKs don't collect and/or exfiltrate user data without policy-compliant functionality and/or adequate notice or consent (Spyware)"; "Use third-party SDKs that perform Denial of Service attacks or act as a Hostile Downloader"; "Use third-party SDKs that collect and transmit personal data for monitoring without proper user disclosure and consent (i.e. stalkerware)"; and "Integrate code that abuses elevated privileges to compromise system integrity, roots devices without explicit user consent and awareness, or employs maskware techniques to evade detection of malicious behavior." The same page reminds developers that "All apps must also comply with all Google Play Developer Program Policies, including user and device data policies such as Mobile Unwanted Software, User Data, Permissions and APIs that Access Sensitive Information, and SDK Requirements."
6. The 2024 clause that catches otherwise-clean apps. Google's Mobile Unwanted Software policy now reads: "Do not request or deceive users into turning off device security protections such as Google Play Protect. For example, you must not offer additional app features or rewards to users in exchange for turning off Google Play Protect" (https://support.google.com/googleplay/android-developer/answer/9970222), introduced by the policy announcement of April 3, 2024 (https://support.google.com/googleplay/android-developer/answer/14594990). Any onboarding screen, help article or SDK consent flow that tells a user to disable Play Protect so the app works is a direct violation - and malware is one of the policy sets where repeat or serious violations put the developer account itself at risk, not just the listing.
7. What enforcement actually looks like. Google's Developer Policy Center states: "Because Malware is potentially harmful to users, apps containing Malware are strictly prohibited from Google Play" (https://play.google/developer-content-policy/). Removal is then propagated to users' devices: "If your app has been removed or suspended from Google Play, its users may receive a push notification from Google Play Protect informing them of this change and giving them the option to remove the app from their device" (https://support.google.com/googleplay/android-developer/answer/2477981). Two mechanics matter. First, a warning is not the end of it - "Warnings don't impact the standing of your Google Play Developer account. However, your app will be removed after the number of days found in the initial warning email" and "If your app has been suspended after receiving a warning, an appeal is required." Second, resubmission fails unless every track is cleaned: you must "upload the modified, policy-compliant app bundle across all tracks, and deactivate the non-compliant app bundle(s)", because "if you fail to deactivate the non-compliant app bundle(s), your attempt to resubmit your app will fail, and live versions of your app bundle(s) may be removed from Google Play." Appeals are rationed - "You may submit one appeal per app removal, suspension, or other enforcement action" - so the first one has to be complete.
8. Play Protect warnings: five that can be appealed, one that cannot. Google's developer guidance covers each warning a user sees. "App blocked to protect your device" fires when an APK from an internet-sideloading source declares RECEIVE_SMS, READ_SMS, NOTIFICATION_LISTENER or ACCESSIBILITY, "because these permissions are frequently abused for financial fraud" - appealable. "Harmful App Blocked" means Play Protect identified the app as a PHA or unwanted software - appealable. "Deceptive Accessibility Tool Warning" "will show only if you declare isAccessibilityTool=\"true\" when your app isn't used to assist users with disabilities" - appealable. "Android App Compatibility Too Low Warning" shows "only if the app's targetSdkVersion is more than 2 versions lower than the current Android API level" - fixed by shipping a current target, not by appealing. The exception is the unknown-app scan prompt ("Play Protect hasn't seen this app before" / "This app is unknown to Play Protect. To protect yourself and others, send it to Google for a security check."): "For users, sending (one time or always) this application to Google Play Protect to scan for potential malware will make this notification go away. Appeals are not relevant and won't remove this message." The remedy there is distribution and visibility - check your device certification status and make Play Protect aware of the app - not an appeal (https://developers.google.com/android/play-protect/warning-dev-guidance).
9. Where a legitimate app actually gets flagged. In practice it is one of five: (a) dynamic or delayed code loading whose payload touches messages, contacts or device identifiers; (b) an accessibility service declared with isAccessibilityTool=\"true\" in an app that is not an assistive tool; (c) a sideloading distribution channel combined with the SMS / notification-listener / accessibility permission set; (d) a monetisation or analytics SDK that exfiltrates identifiers, injects obfuscated code, or behaves as a hostile downloader; (e) a targetSdk more than two API levels behind the platform.
10. Pre-release checklist. Vet every third-party SDK's endpoints and network behaviour, not just its name; request only the minimum permissions and replace READ_SMS verification with the SMS Retriever or User Consent APIs; never ship hidden remote-control features and never obfuscate remote-execution endpoints; patch flagged vulnerabilities immediately; keep targetSdk current; never ask a user to disable Play Protect; and keep the declared use consistent with actual behaviour across Play Console declarations, the APK and the store listing, because Play Protect compares the declared use case against what the build does. Related reading in this FAQ: "SMS and Call Log Permissions Declaration" (https://kapps.store/faq/sms-and-call-log-permissions-declaration-handler-eligibility-permitted-and-excep.html) and "Restricted Permissions Declaration on Google Play - Completing the High-Risk Permissions Form" (https://kapps.store/faq/restricted-permissions-declaration-on-google-play-completing-the-high-risk-permi.html).