Disclaimer: Policy summaries and Key Considerations are overviews only; always refer to the full policy for compliance. The full policy takes precedence in case of conflict.
To maintain a safe Android ecosystem, Google Play prohibits any malicious code, including third-party SDKs integrated into apps, that could put users, their data, or their devices at risk. Please review the full policy to ensure compliance.
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.
Though varied in type and capabilities, malware usually has one of the following objectives:
- 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.
- Defraud the user.
An app, binary, or framework modification can be potentially harmful, and therefore can generate malicious behavior, even if wasn't intended to be harmful. This is because apps, binaries, or framework modifications can function differently depending on a variety of variables. Therefore, 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. Apps, binaries, or framework modifications are flagged as malware or PHA if they clearly pose a risk to some or all Android devices and users.
The malware categories, below, reflect our foundational belief that users should understand how their device is being leveraged and promote a secure ecosystem that enables robust innovation and a trusted user experience.
Visit Google Play Protect for more information.
| Do | Don't |
| Thoroughly vet all code in your app, including third-party SDKs, to ensure they do not exhibit malware-like behaviors such as spyware, trojans, or phishing, even unintentionally. | 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. |
| Consider using tools to check for security vulnerabilities or backdoors that enable unwanted remote operations. | Use third-party SDKs that collect and transmit personal data for monitoring without proper user disclosure and consent (i.e. stalkerware). Incorporate code that will cause deceptive billing practices involving SMS, calls, or toll fraud. |
| 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. |
| Ensure your app does not include third-party SDKs that violate the Android permissions model by gaining elevated privileges through the access of device data for an undisclosed purpose. |
Backdoors
To protect your users, you must remove any code that acts as a backdoor, which is defined as code facilitating unwanted or harmful remote-controlled operations. Please review the full policy to ensure compliance.
Code that allows the execution of unwanted, potentially harmful, remote-controlled operations on a device.
These operations may include behavior that would place the app, binary, or framework modification into one of the other malware categories if executed automatically. In general, backdoor is a description of how a potentially harmful operation can occur on a device and is therefore not completely aligned with categories like billing fraud or commercial spyware. As a result, a subset of backdoors, under some circumstances, are treated by Google Play Protect as a vulnerability.
| Do | Don't |
| Thoroughly test your app's code and all third-party libraries for hidden remote control capabilities. | Don't include hidden features or capabilities that could be exploited to harm users. |
| Secure all remote execution endpoints against unauthorized access. | Don't obfuscate code to hide remote access functionality. |
| Patch known security vulnerabilities in your app immediately. | Don’t ignore warnings about potential vulnerabilities in your dependencies. |
Billing Fraud
To avoid billing fraud, you must remove any code that deceptively charges users without their explicit consent. This includes SMS fraud, Call fraud, and Toll fraud, which trick users into unwanted payments or subscriptions. Please review the full policy to ensure compliance.
Code that automatically charges the user in an intentionally deceptive way.
Mobile billing fraud is divided into SMS fraud, Call fraud, and Toll fraud.
SMS Fraud
Code that charges users to send premium SMS without consent, or tries to disguise its SMS activities by hiding disclosure agreements or SMS messages from the mobile operator notifying the user of charges or confirming subscriptions.
Some code, even though they technically disclose SMS sending behavior, introduce additional behavior that accommodates SMS fraud. Examples include hiding parts of a disclosure agreement from the user, making them unreadable, and conditionally suppressing SMS messages from the mobile operator informing the user of charges or confirming a subscription.
Call Fraud
Code that charges users by making calls to premium numbers without user consent.
Toll Fraud
Code that tricks users into subscribing to or purchasing content via their mobile phone bill.
Toll Fraud includes any type of billing except premium SMS and premium calls. Examples of this include direct carrier billing, wireless application protocol (WAP), and mobile airtime transfer. WAP fraud is one of the most prevalent types of Toll fraud. WAP fraud can include tricking users to click a button on a silently loaded, transparent WebView. Upon performing the action, a recurring subscription is initiated, and the confirmation SMS or email is often hijacked to prevent users from noticing the financial transaction.
| Do | Don't |
| Obtain explicit and unambiguous consent from users before initiating any financial transactions. | Don't hide or disguise any information related to charges or subscriptions. |
| Ensure all billing disclosures are clear, transparent, and prominently visible to the user. | Don't use hidden web views, or automatically send premium SMS messages or make calls without consent. |
| Send all carrier billing notifications through to the user | Don't use methods like direct carrier billing to trick users into subscriptions. |
Stalkerware
Google Play prohibits apps from monitoring another individual by collecting and transmitting personal and sensitive user data, unless the app is exclusively designed and marketed for parents to monitor their children or enterprise management for the monitoring of individual employees, provided they fully comply with strict requirements. Please review the full policy to ensure compliance.
Code that collects personal or sensitive user data from a device and transmits the data to a third party (enterprise or another individual) for monitoring purposes.
Apps must provide adequate prominent disclosure and obtain consent as required by the User Data policy.
Guidelines for Monitoring Applications
Apps exclusively designed and marketed for monitoring another individual, for example parents to monitor their children or enterprise management for the monitoring of individual employees, provided they fully comply with the requirements described below are the only acceptable monitoring apps. These apps cannot be used to track anyone else (a spouse, for example) even with their knowledge and permission, regardless if persistent notification is displayed. These apps must use the IsMonitoringTool metadata flag in their manifest file to appropriately designate themselves as monitoring apps.
Monitoring apps must comply with these requirements:
- Apps must not present themselves as a spying or secret surveillance solution.
- Apps must not hide or cloak tracking behavior or attempt to mislead users about such functionality.
- Apps must present users with a persistent notification at all times when the app is running and a unique icon that clearly identifies the app.
- Apps must disclose monitoring or tracking functionality in the Google Play store description.
- Apps and app listings on Google Play must not provide any means to activate or access functionality that violate these terms, such as linking to a non-compliant APK hosted outside Google Play.
- Apps must comply with any applicable laws. You are solely responsible for determining the legality of your app in its targeted locale.
| Do | Don't |
| Market your app exclusively for parental or enterprise management use. | Market the app as a spying or surveillance solution. |
Include the IsMonitoringTool flag in your manifest. |
Track other adults, including spouses, even with their permission. |
| Display a persistent notification and unique icon when running. | Hide, cloak or mislead users about tracking behavior. |
| Disclose all monitoring functionality in your store description. | Link to non-compliant APKs hosted outside Google Play. |
| Provide adequate prominent disclosure and obtain consent. | Provide means to activate functionality that violates these terms. |
Denial of Service (DoS)
To protect your app and other systems, you must remove any code that, without user knowledge, attacks other systems or generates excessive network load without user knowledge. Please review the full policy to ensure compliance.
Code that, without the knowledge of the user, executes a denial-of-service (DoS) attack or is a part of a distributed DoS attack against other systems and resources.
For example, this can happen by sending a high volume of HTTP requests to produce excessive load on remote servers.
| Do | Don't |
| Thoroughly test your code and third-party SDKs for network abuse. | Don’t hide or embed code that generates a high volume of traffic or network requests. |
| Ensure all network requests from your app are legitimate and necessary for its functionality. | Don’t include functionality that can be remotely activated to attack external systems. |
Hostile Downloaders
Google Play prohibits "hostile downloaders"—apps that download other Mobile Unwanted Software (MUwS). An app is flagged as a hostile downloader if it's believed to be designed to spread MUwS or if at least 5% of its downloads are determined to be MUwS. This policy does not apply to major browsers or file-sharing apps, as long as they only download software with the user's explicit consent and initiation. Please review the full policy to ensure compliance.
Code that isn't in itself potentially harmful, but downloads other PHAs.
Code may be a hostile downloader if:
- There is reason to believe it was created to spread PHAs and it has downloaded PHAs or contains code that could download and install apps; or
- At least 5% of apps downloaded by it are PHAs with a minimum threshold of 500 observed app downloads (25 observed PHA downloads).
Major browsers and file-sharing apps aren't considered hostile downloaders as long as:
- They don't drive downloads without user interaction; and
- All PHA downloads are initiated by consenting users.
| Do | Don't |
| Ensure your app doesn’t include any code that spreads MUwS. | Don’t include any code in your app that spreads MUwS. |
| Monitor downloads to stay well below the 5% MUwS threshold. | Don’t Exceed the 5% MUwS threshold (25 MUwS per 500 downloads). |
| Ensure all app downloads are initiated by a consenting user, if your app's purpose is to download other files (like a browser or file-sharing). | Don’t include functionality that drives app downloads without explicit user interaction, if your app's purpose is to download other files (like a browser or file-sharing). |
Non-Android Threat
Code that contains non-Android threats.
These apps can't cause harm to the Android user or device, but contain components that are potentially harmful to other platforms.
Phishing
You must remove any code that engages in phishing by deceptively requesting a user's credentials or billing information and sending it to a third party. Please review the full policy to ensure compliance.
Code that pretends to come from a trustworthy source, requests a user's authentication credentials or billing information, and sends the data to a third-party. This category also applies to code that intercept the transmission of user credentials in transit.
Common targets of phishing include banking credentials, credit card numbers, and online account credentials for social networks and games.