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.
Full Policy
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.
Key Considerations
| 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.
Full Policy
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.
Key Considerations
| 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.
Full Policy
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.
Key Considerations
| 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
Policy Summary
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.
Full Policy
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.
Key Considerations
| 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.
Full Policy
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.
Key Considerations
| 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.
Key Considerations
| 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.
Full Policy
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.
Key Considerations
| Do | Don't |
| Use official APIs and secure methods to handle user credentials and payment information. | Don’t impersonate a trusted source to trick users into providing personal or financial data. |
| Ensure all user data is transmitted securely and is not readable by third parties. | Don’t intercept or collect user credentials or sensitive information without consent. |
| Be transparent with users about what data you are requesting and why. | Don’t send sensitive user information to a third party without proper user disclosure and explicit consent. |
Elevated Privilege Abuse
To avoid elevated privilege abuse violations, your app must not contain code that gains elevated privileges or breaks the Android security sandbox. This includes code that steals credentials from other apps, circumvents the Android permissions model, or disables core security features. Your app must also respect the user's control over their device. Please review the full policy to ensure compliance.
Full Policy
Code that compromises the integrity of the system by breaking the app sandbox, gaining elevated privileges, or changing or disabling access to core security-related functions.
Examples include:
- An app that violates the Android permissions model, or steals credentials (such as OAuth tokens) from other apps.
- Apps that abuse features to prevent them from being uninstalled or stopped.
- An app that disables SELinux.
Privilege escalation apps that root devices without user permission are classified as rooting apps.
Key Considerations
| Do | Don't |
| Develop code that respects the Android permissions model. | Don't create apps that compromise the system by breaking the app sandbox. |
| Design your app to function with standard user privileges. | Don't write code that prevents a user's app from being uninstalled. |
Ransomware
Policy Summary
Ransomware is malicious software that takes a user's device or data hostage, demanding payment or an action to restore control. You must not lock users out, encrypt data, or prevent uninstallation. This policy protects users from extortion. Please review the full policy to ensure compliance.
Full Policy
Code that takes partial or extensive control of a device or data on a device and demands that the user make a payment or perform an action to release control.
Some ransomware encrypts data on the device and demands payment to decrypt the data and/or leverage the device admin features so that it can't be removed by a typical user. Examples include:
- Locking a user out of their device and demanding money to restore user control.
- Encrypting data on the device and demanding payment, ostensibly to decrypt the data.
- Leveraging device policy manager features and blocking removal by the user.
Code distributed with the device whose primary purpose is for subsidized device management may be excluded from the ransomware category provided they successfully meet requirements for secure lock and management, and adequate user disclosure and consent requirements.
Key Considerations
| Do | Don't |
| Ensure your app's code is free from any malicious ransomware functionality. | Don't encrypt user data or lock them out of their device. |
| Obtain explicit user consent for any device management features. | Don't use device admin features to block uninstallation. |
| Provide a clear and easy way for users to remove your app. | Don't demand payment or action to restore device control. |
Rooting
Policy Summary
Google Play allows non-malicious rooting but prohibits malicious rooting code. You must inform users in advance about rooting and ensure your app does not perform any other harmful actions. The goal is to ensure users consent to this powerful device change and are not exposed to additional malicious behavior. Please review the full policy to ensure compliance.
Full Policy
Code that roots the device.
There's a difference between non-malicious and malicious rooting code. For example, non-malicious rooting apps let the user know in advance that they're going to root the device and they don't execute other potentially harmful actions that apply to other PHA categories.
Malicious rooting apps don't inform the user that they're going to root the device, or they inform the user about the rooting in advance but also execute other actions that apply to other PHA categories.
Key Considerations
| Do | Don't |
| Inform users in advance that your app will root the device. | Don't root a device without informing the user. |
| Obtain explicit consent from the user before rooting. | Don't perform other harmful actions in a rooting app. |
| Confirm your app's code is free from any other malicious behaviors. | Don't use rooting code to hide other malicious functionality. |
Spam
Spyware
Google Play prohibits the malicious collection or sharing of user or device data. Regardless of user consent or disclosure, data collection and sharing must be related to policy-compliant functionality. Please review the full policy to ensure compliance.
Full Policy
Spyware is a malicious application, code, or behavior that collects, exfiltrates, or shares user or device data that is not related to policy compliant functionality.
Malicious code or behavior that can be considered as spying on the user or exfiltrates data without adequate notice or consent is also regarded as spyware.
For example, spyware violations include, but are not limited to:
- Recording audio or recording calls made to the phone
- Stealing app data
- An app with malicious third party code (for example, an SDK) that transmits data off device in a manner that is unexpected to the user and/or without adequate user notice or consent.
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.
Key Considerations
| Do | Don't |
| Provide clear notice and obtain explicit user consent before any data collection or transmission. | Allow third-party SDKs in your app to record audio, calls, or obtain app data without explicit user consent and policy-compliant functionality. |
| Implement robust logging and auditing for all third-party SDKs data access and transmission to detect and address unauthorized data exfiltration. | Engage in hidden data collection, or collect more data than the app needs for its stated function. |
| Ensure SDKs integrated in your app only collect the minimum necessary data and that its purpose or behavior doesn’t cause your app to violate Google Play policies. | Include third-party SDKs in your app that transmit data in unexpected ways or without proper consent. |
| Assume third-party SDKs in your app data collection practices are compliant without your thorough review. |
Trojan
Policy Summary
A Trojan is code that contains a hidden, malicious component. This policy prohibits apps that perform undesirable actions against the user without their knowledge. As a developer, you must ensure your app's code is transparent and free of any hidden, harmful functionality. Please review the full policy to ensure compliance.
Full Policy
Code that appears to be benign, such as a game that claims only to be a game, but that performs undesirable actions against the user.
This classification is usually used in combination with other PHA categories. A trojan has an innocuous component and a hidden harmful component. For example, a game that sends premium SMS messages from the user's device in the background and without the user’s knowledge.
Key Considerations
| Do | Don't |
| Ensure your app's code is transparent and serves its stated purpose. | Don't hide malicious functionality within a seemingly harmless app. |
| Confirm all app functionality is disclosed to the user. | Don't perform background actions without the user's explicit knowledge and consent. |
| Be certain any included third-party SDKs are safe and do not contain hidden behaviors. | Don't misrepresent your app's purpose to trick users. |
A Note on Uncommon Apps
Policy Summary
If Google Play Protect lacks sufficient information to verify your new app's safety, it may be classified as "uncommon." This status doesn't mean your app is harmful, but that it needs further review. Please review the full policy to ensure compliance.
Full Policy
Key Considerations
| Do | Don't |
| Provide complete and accurate information in your app listing. | Don't hide functionality or use obfuscated code. |
| Ensure your app's code is clean and well-documented for review. | Don't use unverified third-party libraries. |
A Note on the Backdoor Category
Policy Summary
A backdoor is code that enables malicious behavior. If dynamic code loading is used to perform harmful actions, your app will be in violation. You must ensure your app’s code does not enable any hidden, malicious functionality. If a vulnerability is found without malicious intent, you will be asked to patch it. Please review the full policy to ensure compliance.
Full Policy
The backdoor malware category classification relies on how the code acts. 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.
Key Considerations
| Do | Don't |
| Rigorously test any code that enables dynamic execution. | Don't use dynamic code loading to perform hidden, malicious actions. |
| Ensure your app's code is free from vulnerabilities that could be exploited. | Don't allow arbitrary code execution without careful security checks. |
| Promptly patch any security vulnerabilities found in your app. | Don't use unverified third-party libraries that could enable a backdoor. |
Riskware
Policy Summary
Riskware is an app that uses evasion techniques to hide malicious functionality. It masks itself as a legitimate app, using methods like obfuscation or dynamic code loading to reveal harmful content later. You must ensure your app is transparent and does not use such techniques to deceive reviewers or users. Please review the full policy to ensure compliance.
Full Policy
An application that utilizes a variety of evasion techniques in order to serve the user different, or fake, application functionality. These apps mask themselves as legitimate applications or games to appear innocuous to app stores and users and use techniques such as obfuscation, dynamic code loading, or cloaking to reveal potentially harmful content.
Riskware is similar to other PHA categories, specifically Trojan, with the main difference being the techniques used to obfuscate the malicious activity.
Key Considerations
| Do | Don't |
| Ensure your app's code is clear and easy to review. | Don't use obfuscation or cloaking to hide functionality. |
| Be transparent about all of your app's functions. | Don't use dynamic code loading to serve malicious content. |
| Disclose all functionality in the app description. | Don't make your app's behavior different for reviewers versus regular users. |
Help us improve this policy article by taking a 2-minute survey.