Play Integrity API: App access risk early access program (EAP)

The Play Integrity API can be used as part of an anti-abuse strategy to protect your app and your users. App access risk is a signal in the Play Integrity API to help you assess whether other apps on a device could be viewing and capturing the screen when your app is running, accessing your app using accessibility permissions, or displaying overlays on your app. Verified accessibility apps are automatically excluded from these verdicts. Your app's backend server can decide what to do next, such as warning the user, to help you reduce the risk of attacks and abuse. 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.

What is app access risk?

The Play Integrity API offers a collection of integrity signals to help app and game developers detect potentially risky and fraudulent interactions and server requests. Developers in this early access program can add app access risk to their API response, which already contains the device integrity, application integrity, and account license verdicts. When the other verdicts have no issues, app access risk can help you detect whether another app on the device could be used to access or control your app. The app access risk verdict contains one or more responses representing different categories of apps installed or running on the device.

When will app access risk be available?

App access risk for Play Integrity API classic requests is available as an early access program to select Play partners. During the early access program, additional features and improvements to strengthen the protection offered by app access risk may be added. App access risk is expected to be made more widely available during 2024.

App access risk considerations

App access risk has the following considerations:

• App access risk requires Android 6 (API level 23) or higher.
• App access risk requires recent versions of both Google Play Store and Google Play services to be installed on the device.
• At launch, app access risk will only be evaluated in classic requests and will initially return an unevaluated verdict in all standard requests. We plan to bring app access risk to standard requests in the future.
• App access risk will initially only be evaluated on phone, tablet, and foldable form factors.
• App access risk automatically excludes verified accessibility services that have been through an enhanced Google Play accessibility review (regardless of their install source on the device). "Excluded" means that verified accessibility services running on the device won't return a capturing, controlling, or overlays response in the app access risk verdict.
• Games only: App access risk requires the user account to be Play licensed, otherwise the verdict will be unevaluated.

Recommended practices for using app access risk

Use app access risk as part of an anti-abuse strategy

App access risk works best when used alongside other signals as part of your overall anti-abuse strategy and not as your sole anti-abuse mechanism. Use this and other Play Integrity API signals in conjunction with other appropriate security best practices for your app.

Gather telemetry and understand your audience before taking action

Before you change functionality based on app access risk or other Play Integrity API verdicts, you can understand the current situation with your existing audience by implementing the API without enforcement. Once you know what verdicts your current install base is returning, you can estimate the impact of any enforcement you're planning and adjust your anti-abuse strategy accordingly.

Challenge risky traffic when accessing high value or sensitive features

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.

Request an integrity verdict at an appropriate moment

You should request an app access risk verdict as close as possible to the time of the action or server request that you want to defend against being accessed, to prevent scammers from working around the integrity check performed by your app.

Have a tiered enforcement strategy

App access risk is available on Android 6 (API level 23) or higher but is more reliable on recent devices, in particular from Android 10 (API level 29) onwards. Consider treating more recent Android devices as more trustworthy than older devices as part of a tiered enforcement strategy.

Plan for user support

When possible, provide useful error messages to the user, and let them know what they can do to fix it, such as retrying, enabling their Internet connection, or checking that the Google Play store app is up to date.

Accommodate legitimate accessibility needs in your app

Ensure that your app is as accessible as it can be. Users have legitimate reasons to use accessibility features on devices and this is why app access risk automatically excludes verified accessibility services that are known to Google Play.

Follow the existing recommendations for the Play Integrity API

In addition to the preceding practices, read the security considerations for the Play Integrity API.

Get early access to app access risk

Follow these steps to start using app access risk.

Step 1: Review these important considerations

• By using app access risk you agree to the terms in the Google Play Developer Distribution Agreement and the Play Integrity API Terms of Service.
• To help you complete Google Play's data safety section requirements, you can use the information provided on how the Play Integrity API handles data.
• Developers participating in the early access program are expected to evaluate app access risk and provide feedback and information about the outcome of their evaluation to Google Play.
• During the early access program, app access risk is subject to change.

Step 2: Request to join the app access risk EAP

If your account has been selected for early access to app access risk, you will see a new option on the Integrity API page in the Play Console to include app access risk in your Play Integrity API response, as described in step 3.

If you do not yet have access to app access risk and would like to express interest in joining the early access program, you can do so by completing this form. Developers who are accepted to the early access program will be granted access to enable app access risk in the Google Play Console.

Step 3: Turn on app access risk in the Integrity API response from the Google Play Console

Once you've been accepted into the early access program, you will see a new option on the Integrity API page in the Play Console to include app access risk in your Play Integrity API response. When you are ready, turn on app access risk in the Play Console:

1. Sign in to the Play Console.
2. Select the app that will use app access risk.
3. In the Release section of the left menu, go to App integrity.
4. Next to Play Integrity API, click Settings.
5. In the Responses section of the page, click Change responses.
6. Turn App access risk on.
7. Click Save changes.

When you turn on or turn off app access risk, any Play Integrity API test responses that you've set up in the Play Console will be deleted and you will need to create them again.

Step 4: Integrate Integrity API classic requests in your app and your app's backend server

If you haven't already done so, follow the documentation to setup and integrate Play Integrity API classic requests into your app and your app's backend server. App access risk will initially only be evaluated in classic requests. App access risk will be unevaluated in all standard requests until support is added.

Step 5: Use new app access risk verdict

Once enabled, the environmentDetails field in the Play Integrity API payload will contain the new app access risk verdict.

{
  requestDetails: { ... }
  appIntegrity: { ... }
  deviceIntegrity: { ... }
  accountDetails: { ... }
  environmentDetails: {
      appAccessRiskVerdict: {
          // This field contains one or more responses, for example the following.
          appsDetected: ["KNOWN_INSTALLED", "UNKNOWN_INSTALLED", "UNKNOWN_CAPTURING"]
      }
 }
}

If app access risk was evaluated, appAccessRiskVerdict contains the field appsDetected with one or more responses. These responses fall into one of the following two groups depending on the install source of the detected apps:

• Play or system apps: Apps that are installed by Google Play or preloaded by the device manufacturer on the device's system partition (identified with FLAG_SYSTEM). Responses for such apps are prefixed by KNOWN_.

• Other apps: Apps that are not installed by Google Play. This excludes apps preloaded on the system partition by the device manufacturer. Responses for such apps are prefixed by UNKNOWN_.

The following responses can be returned:

KNOWN_INSTALLED, UNKNOWN_INSTALLED

There are apps installed that match the corresponding install source.

KNOWN_CAPTURING, UNKNOWN_CAPTURING

There are apps running that have permissions enabled that could be used to view the screen while your app is running. This excludes any verified accessibility services known to Google Play running on the device.

KNOWN_CONTROLLING, UNKNOWN_CONTROLLING

There are apps running that have permissions enabled that could be used to control the device and directly control inputs into your app and could be used to capture inputs and outputs of your app. This excludes any verified accessibility services known to Google Play running on the device.

KNOWN_OVERLAYS, UNKNOWN_OVERLAYS

There are apps running that have permissions enabled that could be used to display overlays on your app. This excludes any verified accessibility services known to Google Play running on the device.

EMPTY (a blank value)

App access risk is not evaluated if a necessary requirement was missed. In this case the appAccessRiskVerdict field is empty. This could happen for several reasons, including the following:

• The device is not trustworthy enough.
• The version of your app installed on the device is unknown to Google Play.
• The version of the Google Play Store on the device is outdated.
• Games only: The user account does not have a Play license for the game.

The following table gives some examples of verdicts and what they mean (this table does not list every possible result):

Depending on your risk level, you can decide what combination of verdicts are acceptable to proceed and what verdicts you want to take action on. The following code snippet illustrates an example of verifying that there are no apps running that could capture the screen or control your app:

val environmentDetails =
    JSONObject(payload).getJSONObject("environmentDetails")
val appAccessRiskVerdict =
    environmentDetails.getJSONObject("appAccessRiskVerdict")

if (appAccessRiskVerdict.has("appsDetected")) {
    val appsDetected = appAccessRiskVerdict.getJSONArray("appsDetected").toString()
    if (!appsDetected.contains("CAPTURING") && !appsDetected.contains("CONTROLLING")) {
        // Looks good!
    }
}

JSONObject environmentDetails =
    new JSONObject(payload).getJSONObject("environmentDetails");
JSONObject appAccessRiskVerdict =
    environmentDetails.getJSONObject("appAccessRiskVerdict");

if (appAccessRiskVerdict.has("appsDetected")) {
    String appsDetected = appAccessRiskVerdict.getJSONArray("appsDetected").toString()
    if (!appsDetected.contains("CAPTURING") && !appsDetected.contains("CONTROLLING")) {
        // Looks good!
    }
}

Step 6: Provide early access feedback to Google Play

Participants in the early access program should report issues and provide feedback. To report technical issues with app access risk or integrity verdicts, create an issue providing all of the information requested. You can also provide feedback on app access risk by emailing integrity-api-eap@google.com.

Migrate from old app access risk verdict format

Apps that joined the app access risk EAP before the end of April 2024 will temporarily receive three fields in the app access risk verdict, the field appsDetected as described in Step 5 and the two deprecated fields playOrSystemApps and otherApps:

appAccessRiskVerdict: {
    // This field can be INSTALLED, CAPTURING, CONTROLLING or UNEVALUATED.
    playOrSystemApps: "INSTALLED"
    // This field can be NOT_INSTALLED, INSTALLED, CAPTURING, CONTROLLING or UNEVALUATED.
    otherApps: "CAPTURING"
    // This field contains one or more of the eight possible responses.
    appsDetected: ["KNOWN_INSTALLED", "UNKNOWN_INSTALLED", "UNKNOWN_CAPTURING"]
}

When app access risk is unevaluated, these apps will receive the verdict:

appAccessRiskVerdict: {
    playOrSystemApps: "UNEVALUATED"
    otherApps: "UNEVALUATED"
}

To help you migrate from using the fields playOrSystemApps and otherApps to the new field appsDetected, the following table outlines the relation between these fields.

Note that running apps that may display overlays were previously not detected by the app access risk signal. Overlays are therefore only flagged in the new appsDetected responses and not in the playOrSystemApps and otherApps fields.

We will contact developers of the affected apps before removing the fields playOrSystemApps and otherApps.

Related content

Learn more about Play integrity and signing services that help you to ensure that users experience your apps and games in the way you intend.