Integritätsergebnisse

Auf dieser Seite wird beschrieben, wie Sie das zurückgegebene Integritätsurteil interpretieren und damit arbeiten. Unabhängig davon, ob Sie eine Standard- oder eine klassische API-Anfrage stellen, wird das Integritätsurteil im selben Format mit ähnlichen Inhalten zurückgegeben. Das Integritätsergebnis enthält Informationen zur Gültigkeit von Geräten, Apps und Konten. Der Server Ihrer App kann die resultierende Nutzlast in einem entschlüsselten, bestätigten Ergebnis verwenden, um zu bestimmen, wie am besten mit einer bestimmten Aktion oder Anfrage in Ihrer App vorgegangen werden soll.

Zurückgegebenes Format des Integritätsergebnisses

Die Nutzlast ist JSON im Nur-Text-Format und enthält neben den vom Entwickler bereitgestellten Informationen auch Integritätssignale.

Die allgemeine Nutzlaststruktur sieht so aus:

{
  "requestDetails": { ... },
  "accountDetails": { ... },
  "appIntegrity": { ... },
  "deviceIntegrity": { ... },
  "environmentDetails": { ... }
}

Die Reihenfolge der Felder in der JSON-Nutzlast wird nicht garantiert. Bevor Sie die einzelnen Integritätsergebnisse prüfen, müssen Sie zuerst prüfen, ob die Werte im Feld requestDetails mit denen der ursprünglichen Anfrage übereinstimmen. In den folgenden Abschnitten werden die einzelnen Felder genauer beschrieben.

Feld „Anfragedetails“

Das Feld requestDetails enthält Informationen zur Anfrage, einschließlich der vom Entwickler bereitgestellten Informationen in requestHash für Standardanfragen und in nonce für klassische Anfragen.

Für Standard-API-Anfragen:

"requestDetails": {
  // Application package name this attestation was requested for.
  // Note that this field might be spoofed in the middle of the request.
  "requestPackageName": "com.package.name",
  // Request hash provided by the developer.
  "requestHash": "aGVsbG8gd29scmQgdGhlcmU",
  // The timestamp in milliseconds when the integrity token
  // was requested.
  "timestampMillis": "1675655009345"
}

Diese Werte sollten mit denen der ursprünglichen Anfrage übereinstimmen. Prüfen Sie daher den requestDetails-Teil der JSON-Nutzlast, indem Sie sicherstellen, dass requestPackageName und requestHash mit den Werten übereinstimmen, die in der ursprünglichen Anfrage gesendet wurden, wie im folgenden Code-Snippet gezeigt:

val requestDetails = JSONObject(payload).getJSONObject("requestDetails")
val requestPackageName = requestDetails.getString("requestPackageName")
val requestHash = requestDetails.getString("requestHash")
val timestampMillis = requestDetails.getLong("timestampMillis")
val currentTimestampMillis = ...

// Ensure the token is from your app.
if (!requestPackageName.equals(expectedPackageName)
        // Ensure the token is for this specific request
    || !requestHash.equals(expectedRequestHash)
        // Ensure the freshness of the token.
    || currentTimestampMillis - timestampMillis > ALLOWED_WINDOW_MILLIS) {
        // The token is invalid! See below for further checks.
        ...
}

RequestDetails requestDetails =
    decodeIntegrityTokenResponse
    .getTokenPayloadExternal()
    .getRequestDetails();
String requestPackageName = requestDetails.getRequestPackageName();
String requestHash = requestDetails.getRequestHash();
long timestampMillis = requestDetails.getTimestampMillis();
long currentTimestampMillis = ...;

// Ensure the token is from your app.
if (!requestPackageName.equals(expectedPackageName)
        // Ensure the token is for this specific request.
    || !requestHash.equals(expectedRequestHash)
        // Ensure the freshness of the token.
    || currentTimestampMillis - timestampMillis > ALLOWED_WINDOW_MILLIS) {
        // The token is invalid! See below for further checks.
        ...
}

Für klassische API-Anfragen:

"requestDetails": {
  // Application package name this attestation was requested for.
  // Note that this field might be spoofed in the middle of the
  // request.
  "requestPackageName": "com.package.name",
  // base64-encoded URL-safe no-wrap nonce provided by the developer.
  "nonce": "aGVsbG8gd29scmQgdGhlcmU",
  // The timestamp in milliseconds when the request was made
  // (computed on the server).
  "timestampMillis": "1617893780"
}

Diese Werte sollten mit denen der ursprünglichen Anfrage übereinstimmen. Prüfen Sie daher den requestDetails-Teil der JSON-Nutzlast und achten Sie darauf, dass requestPackageName und nonce mit den Werten in der ursprünglichen Anfrage übereinstimmen, wie im folgenden Code-Snippet gezeigt:

val requestDetails = JSONObject(payload).getJSONObject("requestDetails")
val requestPackageName = requestDetails.getString("requestPackageName")
val nonce = requestDetails.getString("nonce")
val timestampMillis = requestDetails.getLong("timestampMillis")
val currentTimestampMillis = ...

// Ensure the token is from your app.
if (!requestPackageName.equals(expectedPackageName)
        // Ensure the token is for this specific request. See 'Generate a nonce'
        // section of the doc on how to store/compute the expected nonce.
    || !nonce.equals(expectedNonce)
        // Ensure the freshness of the token.
    || currentTimestampMillis - timestampMillis > ALLOWED_WINDOW_MILLIS) {
        // The token is invalid! See below for further checks.
        ...
}

JSONObject requestDetails =
    new JSONObject(payload).getJSONObject("requestDetails");
String requestPackageName = requestDetails.getString("requestPackageName");
String nonce = requestDetails.getString("nonce");
long timestampMillis = requestDetails.getLong("timestampMillis");
long currentTimestampMillis = ...;

// Ensure the token is from your app.
if (!requestPackageName.equals(expectedPackageName)
        // Ensure the token is for this specific request. See 'Generate a nonce'
        // section of the doc on how to store/compute the expected nonce.
    || !nonce.equals(expectedNonce)
        // Ensure the freshness of the token.
    || currentTimestampMillis - timestampMillis > ALLOWED_WINDOW_MILLIS) {
        // The token is invalid! See below for further checks.
        ...
}

Feld „Kontodetails“

Das Feld accountDetails enthält einen einzelnen Wert, appLicensingVerdict, der den Google Play-Lizenzierungsstatus der App für das Nutzerkonto darstellt, das auf dem Gerät angemeldet ist. Wenn das Nutzerkonto die Play-Lizenz für die App hat, bedeutet das, dass der Nutzer sie bei Google Play heruntergeladen oder gekauft hat.

"accountDetails": {
  // This field can be LICENSED, UNLICENSED, or UNEVALUATED.
  "appLicensingVerdict": "LICENSED"
}

appLicensingVerdict kann einen der folgenden Werte haben:

LICENSED

Der Nutzer hat eine App-Berechtigung. Der Nutzer hat Ihre App also bei Google Play auf seinem Gerät installiert oder aktualisiert.

UNLICENSED

Der Nutzer hat keine App-Berechtigung. Dies ist beispielsweise der Fall, wenn der Nutzer die App per Sideload oder nicht bei Google Play heruntergeladen hat. Sie können Nutzern das Dialogfeld GET_LICENSED anzeigen, um dieses Problem zu beheben.

UNEVALUATED

Lizenzierungsdetails wurden nicht geprüft, da eine erforderliche Voraussetzung nicht erfüllt wurde.

Dafür kann es verschiedene Gründe geben:

• Das Gerät ist nicht vertrauenswürdig genug.
• Die Version der aktuell auf dem Gerät installierten App ist Google Play nicht bekannt.
• Der Nutzer ist nicht bei Google Play angemeldet.

Prüfen Sie, ob der Nutzer eine App-Berechtigung für Ihre App hat, indem Sie prüfen, ob appLicensingVerdict wie erwartet ist. Das folgende Code-Snippet zeigt, wie das geht:

val accountDetails = JSONObject(payload).getJSONObject("accountDetails")
val appLicensingVerdict = accountDetails.getString("appLicensingVerdict")

if (appLicensingVerdict == "LICENSED") {
    // Looks good!
}

JSONObject accountDetails =
    new JSONObject(payload).getJSONObject("accountDetails");
String appLicensingVerdict = accountDetails.getString("appLicensingVerdict");

if (appLicensingVerdict.equals("LICENSED")) {
    // Looks good!
}

Feld für die Anwendungsintegrität

Das Feld appIntegrity enthält paketbezogene Informationen.

"appIntegrity": {
  // PLAY_RECOGNIZED, UNRECOGNIZED_VERSION, or UNEVALUATED.
  "appRecognitionVerdict": "PLAY_RECOGNIZED",
  // The package name of the app.
  // This field is populated iff appRecognitionVerdict != UNEVALUATED.
  "packageName": "com.package.name",
  // The sha256 digest of app certificates (base64-encoded URL-safe).
  // This field is populated iff appRecognitionVerdict != UNEVALUATED.
  "certificateSha256Digest": ["6a6a1474b5cbbb2b1aa57e0bc3"],
  // The version of the app.
  // This field is populated iff appRecognitionVerdict != UNEVALUATED.
  "versionCode": "42"
}

appRecognitionVerdict kann die folgenden Werte haben:

PLAY_RECOGNIZED

Die App und das Zertifikat entsprechen den bei Google Play verfügbaren Versionen.

UNRECOGNIZED_VERSION

Das Zertifikat oder der Paketname stimmt nicht mit den Google Play-Datensätzen überein.

UNEVALUATED

Die Anwendungsintegrität wurde nicht bewertet. Eine erforderliche Voraussetzung wurde nicht erfüllt, z. B. dass das Gerät vertrauenswürdig genug sein muss.

Um sicherzustellen, dass das Token von einer von Ihnen erstellten App generiert wurde, prüfen Sie die Anwendungsintegrität wie im folgenden Code-Snippet gezeigt:

val appIntegrity = JSONObject(payload).getJSONObject("appIntegrity")
val appRecognitionVerdict = appIntegrity.getString("appRecognitionVerdict")

if (appRecognitionVerdict == "PLAY_RECOGNIZED") {
    // Looks good!
}

JSONObject appIntegrity =
    new JSONObject(payload).getJSONObject("appIntegrity");
String appRecognitionVerdict =
    appIntegrity.getString("appRecognitionVerdict");

if (appRecognitionVerdict.equals("PLAY_RECOGNIZED")) {
    // Looks good!
}

Sie können den App-Paketnamen, die App-Version und die App-Zertifikate auch manuell prüfen.

Feld „Geräteintegrität“

Das Feld deviceIntegrity kann einen einzelnen Wert, deviceRecognitionVerdict, enthalten, der ein oder mehrere Labels hat, die angeben, wie gut ein Gerät die App-Integrität erzwingen kann. Wenn ein Gerät die Kriterien für keine Labels erfüllt, wird deviceRecognitionVerdict im Feld deviceIntegrity ausgelassen.

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

Standardmäßig kann deviceRecognitionVerdict Folgendes enthalten:

MEETS_DEVICE_INTEGRITY

Die App wird auf einem echten und zertifizierten Android-Gerät ausgeführt. Unter Android 13 und höher gibt es einen hardwarebasierten Nachweis dafür, dass der Geräte-Bootloader gesperrt ist und das geladene Android-Betriebssystem ein zertifiziertes Image des Geräteherstellers ist.

Leer (leerer Wert)

Die App wird auf einem Gerät ausgeführt, das Anzeichen für Angriffe (z. B. API-Hooks) oder Systemmanipulationen (z. B. durch Rooting) aufweist oder die App wird nicht auf einem physischen Gerät ausgeführt (z. B. einem Emulator, der die Google Play-Integritätsprüfungen nicht besteht).

Prüfen Sie, ob deviceRecognitionVerdict wie erwartet ist (siehe Code-Snippet unten), um sicherzugehen, dass das Token von einem vertrauenswürdigen Gerät stammt:

val deviceIntegrity =
    JSONObject(payload).getJSONObject("deviceIntegrity")
val deviceRecognitionVerdict =
    if (deviceIntegrity.has("deviceRecognitionVerdict")) {
        deviceIntegrity.getJSONArray("deviceRecognitionVerdict").toString()
    } else {
        ""
    }

if (deviceRecognitionVerdict.contains("MEETS_DEVICE_INTEGRITY")) {
    // Looks good!
}

JSONObject deviceIntegrity =
    new JSONObject(payload).getJSONObject("deviceIntegrity");
String deviceRecognitionVerdict =
    deviceIntegrity.has("deviceRecognitionVerdict")
    ? deviceIntegrity.getJSONArray("deviceRecognitionVerdict").toString()
    : "";

if (deviceRecognitionVerdict.contains("MEETS_DEVICE_INTEGRITY")) {
    // Looks good!
}

Wenn Sie Probleme damit haben, dass Ihr Testgerät die Geräteintegrität erfüllt, achten Sie darauf, dass das werkseitige ROM installiert ist (z. B. durch Zurücksetzen des Geräts) und dass der Bootloader gesperrt ist. Sie können auch Play Integrity API-Tests in der Play Console erstellen.

Bedingte Gerätelabels

Wenn Ihre App für Google Play Games für PC veröffentlicht wird, kann die deviceRecognitionVerdict auch das folgende Label enthalten:

MEETS_VIRTUAL_INTEGRITY

Die App wird auf einem Android-Emulator mit Google Play-Diensten ausgeführt. Der Emulator hat die Systemintegritätsprüfungen bestanden und erfüllt die grundlegenden Android-Kompatibilitätsanforderungen.

Optionale Geräteinformationen und Gerätewiedererkennung

Sie können optionale Gerätelabels im Rahmen einer mehrstufigen Durchsetzungsstrategie erhalten. Wenn Sie zusätzliche Labels im Integritätsergebnis aktivieren, kann deviceRecognitionVerdict die folgenden zusätzlichen Labels enthalten:

MEETS_BASIC_INTEGRITY

Die App wird auf einem Gerät ausgeführt, das die grundlegenden Prüfungen zur Systemintegrität bestanden hat. Der Bootloader des Geräts kann gesperrt oder entsperrt sein und der Status des Bootmodus kann verifiziert oder nicht verifiziert sein. Das Gerät ist möglicherweise nicht zertifiziert. In diesem Fall kann Google keine Zusicherungen in Bezug auf Sicherheit, Datenschutz oder App-Kompatibilität geben. Unter Android 13 und höher erfordert das MEETS_BASIC_INTEGRITY-Ergebnis nur, dass der Vertrauensanker der Gerätebestätigung von Google bereitgestellt wird.

MEETS_STRONG_INTEGRITY

Die App wird auf einem echten und zertifizierten Android-Gerät mit einem aktuellen Sicherheitsupdate ausgeführt.

• Unter Android 13 und höher ist für das MEETS_STRONG_INTEGRITY-Urteil MEETS_DEVICE_INTEGRITY und Sicherheitsupdates im letzten Jahr für alle Partitionen des Geräts erforderlich, einschließlich eines Android-Betriebssystempartitions-Patches und eines Anbieterpartitions-Patches.
• Bei Android 12 und niedriger ist für das MEETS_STRONG_INTEGRITY-Ergebnis nur ein hardwaregestützter Nachweis der Boot-Integrität erforderlich. Das Gerät muss nicht über ein aktuelles Sicherheitsupdate verfügen. Wenn Sie das MEETS_STRONG_INTEGRITY verwenden, sollten Sie daher auch die Android SDK-Version im Feld deviceAttributes berücksichtigen.

Für ein einzelnes Gerät werden mehrere Geräte-Labels im Geräteintegritätsurteil zurückgegeben, wenn die Kriterien für jedes Label erfüllt sind.

Geräteattribute

Sie können auch Geräteattribute aktivieren, die die Android SDK-Version des auf dem Gerät ausgeführten Android-Betriebssystems angeben. Die Android SDK-Version ist nützlich, um zwischen Geräten mit Android 13 und höher und Geräten mit niedrigeren Android SDK-Versionen im Rahmen einer mehrstufigen Durchsetzungsstrategie zu unterscheiden. In Zukunft wird sie möglicherweise um weitere Geräteattribute erweitert.

Der Wert für die SDK-Version ist die Android SDK-Versionsnummer, die in Build.VERSION_CODES definiert ist. Die SDK-Version wird nicht geprüft, wenn eine erforderliche Voraussetzung nicht erfüllt wurde. In diesem Fall ist das Feld sdkVersion nicht festgelegt. Das Feld deviceAttributes ist also leer. Das kann folgende Gründe haben:

• Das Gerät ist nicht vertrauenswürdig genug.
• Auf dem Gerät sind technische Probleme aufgetreten.

Wenn Sie deviceAttributes aktivieren, enthält das Feld deviceIntegrity das folgende zusätzliche Feld:

"deviceIntegrity": {
  "deviceRecognitionVerdict": ["MEETS_DEVICE_INTEGRITY"],
  "deviceAttributes": {
    // 33 is one possible value, which represents Android 13 (Tiramisu).
    "sdkVersion": 33
  }
}

Wenn die SDK-Version nicht ausgewertet wird, wird das Feld deviceAttributes so festgelegt:

"deviceIntegrity": {
  "deviceRecognitionVerdict": ["MEETS_DEVICE_INTEGRITY"],
  "deviceAttributes": {}  // sdkVersion field is not set.
}

Letzte Geräteaktivitäten

Sie können auch die Funktion „Letzte Geräteaktivitäten“ aktivieren, um zu sehen, wie häufig Ihre App in der vergangenen Stunde ein Integritäts-Token auf einem bestimmten Gerät angefordert hat. Mithilfe der Geräteaktivität kannst du deine App vor unerwarteten, hyperaktiven Geräten schützen, was auf einen aktiven Angriff hindeuten könnte. Sie können selbst entscheiden, wie viel Vertrauen Sie in die einzelnen Stufen der letzten Geräteaktivitäten setzen, je nachdem, wie oft Ihre App auf einem typischen Gerät pro Stunde ein Integritäts-Token anfordern sollte.

Wenn Sie sich für den Empfang von recentDeviceActivity entscheiden, enthält das Feld deviceIntegrity zwei Werte:

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

Die Definitionen für deviceActivityLevel unterscheiden sich je nach Modus und können einen der folgenden Werte haben:

Gerätewiedererkennung (Beta)

Sie können auch die Gerätewiedererkennung aktivieren. Damit können Sie benutzerdefinierte, gerätespezifische Daten für bestimmte Geräte speichern, die Sie zuverlässig abrufen können, wenn Ihre App später auf demselben Gerät installiert wird. Nachdem Sie ein Integritäts-Token angefordert haben, führen Sie einen separaten Server-zu-Server-Aufruf aus, um die Werte für die Gerätewiedererkennung für ein bestimmtes Gerät zu ändern.

Wenn Sie deviceRecall aktivieren, enthält das Feld deviceIntegrity die Gerätewiedererkennungsinformationen, die Sie für das jeweilige Gerät festgelegt haben:

"deviceIntegrity": {
  "deviceRecognitionVerdict": ["MEETS_DEVICE_INTEGRITY"],
  "deviceRecall": {
    "values": {
      "bitFirst": true,
      "bitSecond": false,
      "bitThird": true
    },
    "writeDates": {
      // Write time in YYYYMM format in UTC.
      "yyyymmFirst": 202401,
      // Note that yyyymmSecond is not set because bitSecond is false.
      "yyyymmThird": 202310
    }
  }
}

Die deviceRecall ist in zwei Felder unterteilt:

• values: Ruft die Bitwerte ab, die Sie zuvor für dieses Gerät festgelegt haben.
• writeDates: Rufe die Bit-Schreibdaten in UTC auf, die auf das Jahr und den Monat genau sind. Das Schreibdatum eines Recall-Bits wird jedes Mal aktualisiert, wenn das Bit auf true gesetzt wird, und entfernt, wenn das Bit auf false gesetzt wird.

Wenn keine Informationen zum Rückruf des Geräts verfügbar sind, ist der Wert für den Rückruf des Geräts leer:

"deviceIntegrity": {
  "deviceRecognitionVerdict": ["MEETS_DEVICE_INTEGRITY"],
  "deviceRecall": {
    "values": {},
    "writeDates": {}
  }
}

Feld „Umgebungsdetails“

Sie können auch zusätzliche Signale zur Umgebung aktivieren. Das Signal „Risiko von App-Zugriffen“ informiert Ihre App darüber, ob andere Apps ausgeführt werden, die möglicherweise den Bildschirm aufnehmen, Overlays einblenden oder das Gerät steuern können. Im Play Protect-Ergebnis erfährst du, ob Google Play Protect auf dem Gerät aktiviert ist und ob bekannte Malware gefunden wurde.

Wenn Sie in der Google Play Console das Ergebnis „Risiko von App-Zugriffen“ oder „Play Protect“ aktiviert haben, enthält Ihre API-Antwort das Feld environmentDetails. Das Feld environmentDetails kann zwei Werte enthalten: appAccessRiskVerdict und playProtectVerdict.

Ergebnis zum Risiko von App-Zugriffen

Sobald das Signal aktiviert ist, enthält das Feld environmentDetails im Payload der Play Integrity API das neue Ergebnis zum Risiko von App-Zugriffen.

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

Wenn das Risiko von App-Zugriffen bewertet wurde, enthält appAccessRiskVerdict das Feld appsDetected mit einer oder mehreren Antworten. Diese Antworten fallen je nach Installationsquelle der erkannten Apps in eine der folgenden zwei Gruppen:

• Play- oder System-Apps: Apps, die über Google Play installiert oder vom Gerätehersteller auf der Systempartition des Geräts vorinstalliert wurden (gekennzeichnet mit FLAG_SYSTEM). Antworten für solche Apps haben das Präfix KNOWN_.

• Andere Apps: Apps, die nicht über Google Play installiert wurden. Ausgenommen sind Apps, die vom Gerätehersteller auf der Systempartition vorinstalliert wurden. Antworten für solche Apps haben das Präfix UNKNOWN_.

Die folgenden Antworten können zurückgegeben werden:

KNOWN_INSTALLED, UNKNOWN_INSTALLED

Es sind Apps installiert, die der entsprechenden Installationsquelle entsprechen.

KNOWN_CAPTURING, UNKNOWN_CAPTURING

Es werden Apps ausgeführt, für die Berechtigungen aktiviert sind, die verwendet werden könnten, um den Bildschirm anzuzeigen, während Ihre App ausgeführt wird. Ausgenommen sind alle bestätigten Bedienungshilfen, die auf dem Gerät ausgeführt werden und Google Play bekannt sind.

KNOWN_CONTROLLING, UNKNOWN_CONTROLLING

Es werden Apps ausgeführt, für die Berechtigungen aktiviert sind, die verwendet werden könnten, um das Gerät und Eingaben in Ihre App direkt zu steuern und um Eingaben und Ausgaben Ihrer App zu erfassen. Ausgenommen sind alle bestätigten Barrierefreiheitsdienste, die auf dem Gerät ausgeführt werden und in Google Play verfügbar sind.

KNOWN_OVERLAYS, UNKNOWN_OVERLAYS

Es werden Apps ausgeführt, für die Berechtigungen aktiviert sind, die zum Einblenden von Overlays in Ihrer App verwendet werden könnten. Dies schließt alle bestätigten Bedienungshilfen aus, die auf dem Gerät ausgeführt werden und Google Play bekannt sind.

Leer (leerer Wert)

Das Risiko von App-Zugriffen wird nicht bewertet, wenn eine erforderliche Voraussetzung nicht erfüllt wurde. In diesem Fall ist das Feld appAccessRiskVerdict leer. Dafür kann es verschiedene Gründe geben:

• Das Gerät ist nicht vertrauenswürdig genug.
• Der Formfaktor des Geräts ist kein Smartphone, Tablet oder Foldable.
• Auf dem Gerät ist nicht Android 6 (API‑Level 23) oder höher installiert.
• Die Version der aktuell auf dem Gerät installierten App ist Google Play nicht bekannt.
• Die Version des Google Play Store auf dem Gerät ist veraltet.
• Das Nutzerkonto hat keine Play-Lizenz.
• Es wurde eine Standardanfrage mit dem Parameter verdictOptOut verwendet.
• Es wurde eine Standardanfrage mit einer Play Integrity API-Bibliotheksversion verwendet, die das Risiko von App-Zugriffen für Standardanfragen noch nicht unterstützt.

Das Risiko von App-Zugriffen schließt automatisch geprüfte Bedienungshilfen aus, die eine erweiterte Google Play-Überprüfung der Barrierefreiheit durchlaufen haben und über einen beliebigen App-Store auf dem Gerät installiert wurden. „Ausgeschlossen“ bedeutet, dass geprüfte Bedienungshilfen, die auf dem Gerät ausgeführt werden, im Ergebnis zum Risiko von App-Zugriffen keine Antwort zur Bildschirmaufzeichnung, Gerätesteuerung oder Einblendung von Overlays zurückgeben. Wenn Sie eine erweiterte Google Play-Barrierefreiheitsprüfung für Ihre Bedienungshilfen-App anfordern möchten, veröffentlichen Sie sie bei Google Play. Achten Sie darauf, dass in der Manifestdatei Ihrer App das Flag isAccessibilityTool auf „true“ gesetzt ist, oder fordern Sie eine Überprüfung an.

Beispiele für Ergebnisse zum Risiko von App-Zugriffen

In der folgenden Tabelle finden Sie einige Beispiele für Risikobewertungen für den App-Zugriff und deren Bedeutung. Sie enthält nicht alle möglichen Ergebnisse:

Je nach Risikostufe können Sie entscheiden, welche Kombination von Ergebnissen akzeptabel ist und bei welchen Ergebnissen Sie Maßnahmen ergreifen möchten. Das folgende Code-Snippet zeigt ein Beispiel dafür, wie Sie prüfen können, ob Apps ausgeführt werden, die möglicherweise den Bildschirm aufnehmen oder Ihre App steuern:

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!
    }
}

Risiko von App-Zugriffen beheben

Je nach Risikostufe können Sie entscheiden, auf welche Risikobewertungen für das Risiko von App-Zugriffen Sie reagieren möchten, bevor der Nutzer eine Anfrage oder Aktion abschließen kann. Es gibt optionale Google Play-Aufforderungen, die Sie dem Nutzer nach der Überprüfung des Risikos von App-Zugriffen anzeigen können. Sie können CLOSE_UNKNOWN_ACCESS_RISK anzeigen, um den Nutzer aufzufordern, unbekannte Apps zu schließen, die das Risiko von App-Zugriffen verursacht haben. Alternativ können Sie CLOSE_ALL_ACCESS_RISK anzeigen, um den Nutzer aufzufordern, alle Apps (bekannte und unbekannte) zu schließen, die das Risiko von App-Zugriffen verursacht haben.

Play Protect-Ergebnis

Sobald das Signal aktiviert ist, enthält das Feld environmentDetails im Payload der Play Integrity API das Play Protect-Ergebnis:

"environmentDetails": {
  "playProtectVerdict": "NO_ISSUES"
}

playProtectVerdict kann einen der folgenden Werte haben:

NO_ISSUES

Play Protect ist aktiviert und hat keine App-Probleme auf dem Gerät gefunden.

NO_DATA

Play Protect ist aktiviert, es wurde aber noch kein Scan durchgeführt. Das Gerät oder die Google Play Store App wurde möglicherweise vor Kurzem zurückgesetzt.

POSSIBLE_RISK

Play Protect ist deaktiviert.

MEDIUM_RISK

Play Protect ist aktiviert und hat potenziell schädliche Apps gefunden, die auf dem Gerät installiert sind.

HIGH_RISK

Play Protect ist aktiviert und hat gefährliche Apps gefunden, die auf dem Gerät installiert sind.

UNEVALUATED

Das Play Protect-Ergebnis wurde nicht ausgewertet.

Dafür kann es verschiedene Gründe geben:

• Das Gerät ist nicht vertrauenswürdig genug.
• Das Nutzerkonto hat keine Play-Lizenz.

Hinweise zur Verwendung des Play Protect-Ergebnisses

Der Backend-Server Ihrer App kann basierend auf Ihrer Risikotoleranz entscheiden, wie er als Nächstes vorgehen soll. Hier einige Vorschläge und mögliche Nutzeraktionen:

NO_ISSUES

Play Protect ist aktiviert und hat keine Probleme gefunden. Sie müssen nichts weiter tun.

POSSIBLE_RISK und NO_DATA

Wenn Sie diese Ergebnisse erhalten, bitten Sie den Nutzer, zu prüfen, ob Play Protect aktiviert ist und ein Scan durchgeführt wurde. NO_DATA sollte nur in seltenen Fällen angezeigt werden.

MEDIUM_RISK und HIGH_RISK

Je nach Risikobereitschaft können Sie den Nutzer auffordern, Play Protect zu starten und auf die Play Protect-Warnungen zu reagieren. Wenn der Nutzer diese Anforderungen nicht erfüllen kann, können Sie ihn für die Serveraktion blockieren.