Our malware policy is simple: the Android ecosystem including the Google Play Store, and user devices should be free from malicious behaviours (i.e. malware). Through this fundamental principle we strive to provide a safe Android ecosystem for our users and their Android devices.

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 can therefore generate malicious behaviour, even if it 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 behaviour, 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.




Code that allows the execution of unwanted, potentially harmful, remote-controlled operations on a device.

These operations may include behaviour 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.



Billing fraud

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 it technically discloses SMS sending behaviour, introduces additional behaviour 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 operator billing, wireless access point (WAP) and mobile airtime transfer. WAP fraud is one of the most prevalent types of toll fraud. WAP fraud can include tricking users into clicking 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.




Code that collects and/or transmits personal or sensitive user data from a device without adequate notice or consent and doesn't display a persistent notification that this is happening.

Stalkerware apps target device users by monitoring personal or sensitive user data, and transmitting or making this data accessible to third parties. 

Apps exclusively designed and marketed for parents to track their children or enterprise management, provided that they fully comply with the requirements described below are the only acceptable surveillance 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.

Non-stalkerware apps distributed on the Play Store which monitor or track a user's behaviour on a device must minimally comply with these requirements:

  • Apps must not present themselves as a spying or secret surveillance solution.
  • Apps must not hide or cloak tracking behaviour 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 and app listings on Google Play must not provide any means to activate or access functionality that violates these terms, such as linking to a non-compliant APK hosted outside Google Play.
  • You are solely responsible for determining the legality of your app in its targeted locale. Apps determined to be unlawful in locations where they are published will be removed.


Denial of service (DoS)

Code that, without the knowledge of the user, executes a denial-of-service (DoS) attack or is 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.


Hostile downloaders

Code that isn't in itself potentially harmful, but downloads other PHAs.

Code may be a hostile downloader if:

  • There is reason to believe that 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.


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.



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 intercepts 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.


Elevated privilege abuse

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.



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 subsidised device management may be excluded from the ransomware category provided that they successfully meet requirements for secure lock and management, as well as adequate user disclosure and consent requirements.



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.



Code that sends unsolicited messages to the user's contacts or uses the device as an email spam relay.



Code that transmits personal data off the device without adequate notice or consent.

For example, transmitting any of the following information without disclosures or in a manner that is unexpected to the user is sufficient to be considered spyware:

  • Contact list
  • Photos or other files from the SD card or that aren’t owned by the app
  • Content from user email
  • Call log
  • SMS log
  • Web history or browser bookmarks of the default browser
  • Information from the /data/ directories of other apps.

Behaviours that can be considered as spying on the user can also be flagged as spyware. For example, recording audio or recording calls made to the phone, or stealing app data.



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.


A note on uncommon apps

New and rare apps can be classified as uncommon if Google Play Protect doesn't have enough information to clear them as safe. This doesn't mean that the app is necessarily harmful, but without further review it can't be cleared as safe either.


A note on the backdoor category

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 behaviour 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, the app will be treated as having a vulnerability, rather than being backdoor malware, and the developer will be asked to patch it.


Was this helpful?
How can we improve it?

Need more help?

Sign in for additional support options to quickly solve your issue

Clear search
Close search
Google apps
Main menu
Search Help Centre