Secure the environment

Google offers a set of APIs and services to help you detect if your app is running in a safe and trusted environment. The centerpiece is the Play Integrity API, which helps check that interactions are genuine by detecting potentially risky and fraudulent interactions. In addition to app and device integrity, Play Integrity API now offers information about access and accessibility risks, Google Play Protect, and recent device activity. To further harden your anti-fraud strategy the Android platform offers APIs for specific scenarios that might be relevant to your app.

Play Integrity API

Play Integrity API features

The Play Integrity API lets you learn about the security state of the device their app is running on. This helps you be confident that the right user is accessing sensitive information.

It helps you check that interactions and server requests are coming from your genuine app binary in a trustworthy environment:

  • Genuine app binary: Determine whether you're interacting with your unmodified binary that Google Play recognizes.
  • Genuine Play install: Determine whether the current user account is licensed, which means that the user installed or paid for your app or game on Google Play.
  • Genuine Android device: Determine whether your app is running on a genuine Android-powered device powered by Google Play services.
  • Free of known malware: Determine whether Google Play Protect is turned on and whether it has found risky or dangerous apps installed on the device.
  • Low risk of access by other apps: Determine whether other apps are running that could capture the screen or control the device and inputs into your app.

How this helps mitigate fraud

When a user performs an important action in your app, you can call the Play Integrity API. If it didn't, then your app's backend server can decide what to do to defend against attacks and fraud. For example, you could require additional user verification or deny access to sensitive functionality.

The Play Integrity API decision flow

App Access Risk

The App Access Risk signal was introduced to help you assess whether other apps on a device could be viewing and capturing the screen when your app is running or accessing your app using accessibility permissions. Verified accessibility apps are automatically excluded from these verdicts. App access risk helps developers protect their apps while preserving user privacy because the requesting app does not obtain the identity of installed apps and the verdict is not linked to user or device identifiers.

Screenshot of phone requiring the user to close certain apps.

Thanks to this collaborative effort, we are able to get the signals needed to give us deeper insights to protect our customers more effectively.
—Nubank, early access partner

App Access Risk has different risk levels:

  • A capturing response means other apps are running that can capture the screen.
  • A controlling response means other apps are running that can control the device, and hence they could both capture the screen and control the inputs into your app.

App Access Risk enforcement

Identify high value or sensitive actions in your app or game to protect with the Play Integrity API instead of denying access outright. When possible, challenge risky traffic before allowing high-value actions to proceed. For example, when the app access risk indicates that an app is running that could capture the screen, ask the user to disable or uninstall apps that can capture the screen before allowing them to proceed to functionality that you want to protect.

This table contains some example verdicts:

Example app access risk verdict response Interpretation
appsDetected:
["KNOWN_INSTALLED"]
There are only apps installed that are recognized by Google Play or preloaded on the system partition by the device manufacturer. There are no apps running that would result in the capturing, controlling, or overlays verdicts.
appsDetected:
["KNOWN_INSTALLED",
"UNKNOWN_INSTALLED",
"UNKNOWN_CAPTURING"]
There are apps installed by Google Play or preloaded on the system partition by the device manufacturer. There are other apps running and have permissions enabled that could be used to view the screen or capture other inputs and outputs.
appsDetected:
["KNOWN_INSTALLED",
"KNOWN_CAPTURING",
"UNKNOWN_INSTALLED",
"UNKNOWN_CONTROLLING"]
There are Play or system running that have permissions enabled that could be used to view the screen or capture other inputs and outputs. There are also other apps running that have permissions enabled that could be used to control the device and directly control inputs into your app.
appAccessRiskVerdict: {} App access risk is not evaluated because a necessary requirement was missed. For example, the device was not trustworthy enough.

Play Protect Signal

The Play Protect Signal tells your app whether Play Protect is turned on and whether it has found known harmful apps installed on the device.

environmentDetails:{
  playProtectVerdict: "NO_ISSUES"
}

If malware is a particular concern for your app or your users' data, you can check this verdict and ask your users to turn on Play Protect or remove harmful apps before proceeding.

Turn on Play Protect dialog

playProtectVerdict can have one of the following values:

Verdict Explanation Recommended Action

NO_ISSUES

Play Protect is turned on and did not find any app issues on the device.

Play Protect is on and hasn't found any issues so no user action is required.

NO_DATA

Play Protect is turned on but no scan has been performed yet. The device or the Play Store app may have been recently reset.

Play Protect is on and hasn't found any issues so no user action is required.

POSSIBLE_RISK

Play Protect is turned off.

Play Protect is on and hasn't found any issues so no user action is required.

MEDIUM_RISK

Play Protect is turned on and has found potentially harmful apps installed on the device.

Depending on your risk tolerance, you can ask the user to launch Play Protect and take action on the Play Protect warnings. If the user can't fulfill these requirements you may block them from the server action.

HIGH_RISK

Play Protect is turned on and has found dangerous apps installed on the device.

Depending on your risk tolerance, you can ask the user to launch Play Protect and take action on the Play Protect warnings. If the user can't fulfill these requirements you may block them from the server action.

UNEVALUATED

The Play Protect verdict was not evaluated.

This could happen for several reasons, including the following:

  • The device is not trustworthy enough.
  • Games only: The user account is not LICENSED.

Recent device activity

You can also opt-in to recent device activity, which tells you how many times your app requested an integrity token on a specific device in the last hour. You can use recent device activity to protect your app against unexpected, hyperactive devices that could be an indication of an active attack. You can decide how much to trust each recent device activity level based on how many times you expect your app installed on a typical device to request an integrity token each hour.

If you opt-in to receive recentDeviceActivity the deviceIntegrity field will have two values:

deviceIntegrity: {
  deviceRecognitionVerdict: ["MEETS_DEVICE_INTEGRITY"]
  recentDeviceActivity: {
    // "LEVEL_2" is one of several possible values.
    deviceActivityLevel: "LEVEL_2"
  }
}

First, you should check the data to see what the typical device activity levels for your app are across all your devices. Then, you can decide how your app should respond when a device is making too many requests. If the activity is a little high, you might want to ask the user to try again later. If the activity is very high, you might want to take stronger enforcement action.

Standard versus classic requests

As part of your implementation of Play Integrity, it is important to consider the two types of requests. You should use standard requests in most cases, to provide the fastest response - and classic requests should be used where a newly generated request against the device attestation record is needed.

Classic request

Standard request

Requests take longer and should be made less frequently.

For example as an occasional one-off to check if a highly valuable or sensitive action is genuine.

Use infrequently.

Requests are low latency and can be used on demand.

A standard request consists of two parts:

  • Prepare the integrity token provider (one off)
  • Request an integrity token (on demand)

Use on demand.

Read the Play Integrity documentation for more information on standard and classic requests.

Implementation

To get started with the Play Integrity API:

By default, Play Integrity API allows up to 10K requests per app per day. To express interest in increasing your daily maximum requests, follow these instructions. To be eligible for an increase in your daily maximum number of requests, your app must implement Play Integrity API correctly and be available on Google Play in addition to any other distribution channels.

Things to keep in mind for the Play Integrity API

Automatic integrity protection (API >= 23)

Automatic integrity protection is an anti-tamper code protection service that protects your app against integrity abuse in the form of unauthorized modification and redistribution. It works without a data connection and requires no developer work before testing and no backend server integration.

How this helps mitigate fraud

When you turn on automatic integrity protection, Google Play adds checks to your app's code and makes them hard to remove with advanced obfuscation and anti-reverse engineering techniques. At runtime, the protection checks if your app has been tampered or redistributed:

  • If the installer check fails, users will be prompted to get on your app on Google Play
  • If the modification check fails, the app won't run

This helps keep users safe from modified versions of your app.

Implementation

Automatic integrity protection is only available to select Play Partners at this time. Contact Google Play developer support if the feature is not available in your Google Play Console and you would like to express interest in getting access.

You can either turn on protection when creating a release or on the App integrity page (Release > App integrity). Automatic integrity protection requires your app to use Play App Signing.

Be sure to test your protected app before promoting the release to production.

Things to keep in mind

  • Don't release unprotected app versions
  • Take care when mixing anti-tamper protection solutions
  • Test your protected app before releasing it to production
  • Monitor stats as normal for any increase in crashes
  • You can report cracked versions of your app to Google Play