Device and Network Abuse

We don’t allow apps that interfere with, disrupt, damage, or access in an unauthorized manner the user’s device, other devices or computers, servers, networks, application programming interfaces (APIs), or services, including but not limited to other apps on the device, any Google service, or an authorized carrier’s network.

Apps on Google Play must comply with the default Android system optimization requirements documented in the Core App Quality guidelines for Google Play.

An app distributed via Google Play may not modify, replace, or update itself using any method other than Google Play's update mechanism. Likewise, an app may not download executable code (such as dex, JAR, .so files) from a source other than Google Play. This restriction does not apply to code that runs in a virtual machine or an interpreter where either provides indirect access to Android APIs (such as JavaScript in a webview or browser).

Apps or third-party code, like SDKs, with interpreted languages (JavaScript, Python, Lua, etc.) loaded at run time (for example, not packaged with the app) must not allow potential violations of Google Play policies.

We don’t allow code that introduces or exploits security vulnerabilities. Check out the App Security Improvement Program to find out about the most recent security issues flagged to developers.

Examples of common Device and Network Abuse violations:

Apps that block or interfere with another app displaying ads.
Game cheating apps that affect the gameplay of other apps.
Apps that facilitate or provide instructions on how to hack services, software or hardware, or circumvent security protections.
Apps that access or use a service or API in a manner that violates its terms of service.
Apps that are not eligible for allowlisting and attempt to bypass system power management.
Apps that facilitate proxy services to third parties may only do so in apps where that is the primary, user-facing core purpose of the app.
Apps or third party code (for example, SDKs) that download executable code, such as dex files or native code, from a source other than Google Play.
Apps that install other apps on a device without the user's prior consent.
Apps that link to or facilitate the distribution or installation of malicious software.
Apps or third party code (for example, SDKs) containing a webview with added JavaScript Interface that loads untrusted web content (for example, http:// URL) or unverified URLs obtained from untrusted sources (for example, URLs obtained with untrusted Intents).
Apps that use the full-screen intent permission to force user interaction with disruptive ads or notifications.

Permissions for Foreground Services (FGS)

The Foreground Service permission ensures the appropriate use of user-facing foreground services. For apps targeting Android 14 and above, you must specify a valid foreground service type for each foreground service used in your app, and declare the foreground service permission that is appropriate for that type. For example, if your app’s use case requires map geolocation, you must declare the FOREGROUND_SERVICE_LOCATION permission in your app’s manifest.

Apps are only allowed to declare a foreground service permission if the use:

provides a feature that is beneficial to the user and relevant to the core functionality of the app
is initiated by the user or is user perceptible (for example, audio from playing a song, cast media to another device, accurate and clear user notification, user request to upload a photo to the cloud)
can be terminated or stopped by the user
can’t be interrupted or deferred by the system without causing a negative user experience or causing the user anticipated feature to not work as intended (for example, a phone call needs to start immediately and can’t be deferred by the system)
runs only for as long as necessary to complete the task

The following foreground service use cases are exempt from the above criteria:

foreground service types systemExempted or shortService;
foreground service type dataSync only when using Play Asset Delivery features

The use of foreground service is further explained here.

User-Initiated Data Transfer Jobs

Apps are only allowed to use the user-initiated data transfer jobs API if the use is:

initiated by the user
for network data transfer tasks
runs only for as long as necessary to complete the data transfer

The usage of the user-initiated data transfer jobs API is further explained here.

Flag Secure Requirements

FLAG_SECURE is a display flag declared in an app’s code to indicate that its UI contains sensitive data intended to be limited to a secure surface while using the app. This flag is designed to prevent the data from appearing in screenshots or from being viewed on non-secure displays. Developers declare this flag when the app’s content should not be broadcast, viewed, or otherwise transmitted outside of the app or users’ device.

For security and privacy purposes, all apps distributed on Google Play are required to respect the FLAG_SECURE declaration of other apps. Meaning, apps must not facilitate or create workarounds to bypass the FLAG_SECURE settings in other apps.

Apps that qualify as an Accessibility Tool are exempt from this requirement, as long as they do not transmit, save, or cache FLAG_SECURE protected content for access outside of the user's device.

Apps that Run On-device Android Containers

On-device Android container apps provide environments that simulate whole or portions of an underlying Android OS. The experience within these environments may not reflect the full suite of Android security features, which is why developers can choose to add a secure environment manifest flag to communicate to on-device Android containers that they must not operate in their simulated Android environment.

Secure Environment Manifest Flag

REQUIRE_SECURE_ENV is a flag that can be declared in an app’s manifest to indicate that this app must not run in on-device Android container apps. For security and privacy purposes, apps that provide on-device Android containers must respect all apps that declare this flag and:

Review the manifests of apps they intend to load in their on-device Android container for this flag.
Not load the apps that declared this flag into their on-device Android container.
Not function as a proxy by intercepting or calling APIs on the device so that they appear to be installed in the container.
Not facilitate, or create workarounds to bypass the flag (such as, loading an older version of an app to bypass the current app’s REQUIRE_SECURE_ENV flag).

Learn more about this policy in our Help Center.

Was this helpful?

How can we improve it?