Integritätsergebnisse

Auf dieser Seite wird beschrieben, wie Sie das zurückgegebene Integritätsurteil interpretieren und verwenden. Unabhängig davon, ob Sie eine Standard- oder klassische API-Anfrage stellen, wird das Integritätsurteil im selben Format mit ähnlichen Inhalten zurückgegeben. Das Integritätsurteil 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 Urteil verwenden, um zu ermitteln, wie bei einer bestimmten Aktion oder Anfrage in Ihrer App am besten vorgegangen werden soll.

Format des zurückgegebenen Integritätsurteils

Die Nutzlast ist ein JSON-Text und enthält neben von Entwicklern bereitgestellten Informationen auch Integritätssignale.

Die allgemeine Nutzlaststruktur sieht so aus:

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

Sie müssen zuerst prüfen, ob die Werte im Feld requestDetails mit denen der ursprünglichen Anfrage übereinstimmen, bevor Sie jedes Integritätsurteil prüfen. In den folgenden Abschnitten werden die einzelnen Felder genauer beschrieben.

Feld „Anfragedetails“

Das Feld requestDetails enthält Informationen zur Anfrage, einschließlich von Entwicklern bereitgestellter Informationen im requestHash für Standardanfragen und im 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 Teil requestDetails der JSON-Nutzlast. Achten Sie darauf, dass requestPackageName und requestHash mit den Werten übereinstimmen, die in der ursprünglichen Anfrage gesendet wurden, wie im folgenden Code-Snippet gezeigt:

Kotlin

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

Java

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üfe daher den Teil requestDetails der JSON-Nutzlast. Achte darauf, dass requestPackageName und nonce mit den Werten übereinstimmen, die in der ursprünglichen Anfrage gesendet wurden, wie im folgenden Code-Snippet gezeigt:

Kotlin

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

Java

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 „App-Integritä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 App-Integrität wurde nicht bewertet. Eine erforderliche Voraussetzung wurde nicht erfüllt, z. B. dass das Gerät vertrauenswürdig genug sein muss.

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

Kotlin

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

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

Java

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

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

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

Feld „Geräteintegrität“

Das Feld deviceIntegrity kann einen einzelnen Wert, deviceRecognitionVerdict, mit einem oder mehreren Labels enthalten, 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, ist das Feld deviceIntegrity leer.

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 Android-Gerät mit Google Play-Diensten ausgeführt. Das Gerät besteht die Systemintegritätsprüfungen und erfüllt die Android-Kompatibilitätsanforderungen.
Leeres Feld (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üfe, ob das Token von einem vertrauenswürdigen Gerät stammt, indem du prüfst, ob deviceRecognitionVerdict wie erwartet ist, wie im folgenden Code-Snippet gezeigt:

Kotlin

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

Java

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 nicht erfüllt, prüfen Sie, ob das ROM des Herstellers installiert ist (z. B. durch Zurücksetzen des Geräts) und ob 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 Spiele für PC veröffentlicht wird, kann die deviceRecognitionVerdict auch das folgende Label enthalten:

MEETS_VIRTUAL_INTEGRITY
Die App wird in 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

Wenn Sie zustimmen, dass Ihnen im Integritätsurteil zusätzliche Labels gesendet werden, 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. Das Gerät erfüllt möglicherweise nicht die Kompatibilitätsanforderungen von Android und ist eventuell nicht für die Ausführung von Google Play-Diensten zugelassen. Es kann beispielsweise sein, dass auf dem Gerät eine unbekannte Version von Android ausgeführt wird, ein entsperrter Bootloader installiert ist, oder dass es nicht vom Hersteller zertifiziert wurde.
MEETS_STRONG_INTEGRITY
Die App wird auf einem Android-Gerät mit Google Play-Diensten ausgeführt und die Systemintegrität ist bestmöglich gewahrt, z. B. durch einen hardwaregestützten Nachweis der Bootintegrität. Das Gerät besteht die Systemintegritätsprüfungen und erfüllt die Android-Kompatibilitätsanforderungen.

Für ein einzelnes Gerät werden im Urteil zur Geräteintegrität mehrere Gerätelabels zurückgegeben, wenn jedes der Labelkriterien erfüllt ist.

Letzte Geräteaktivitäten

Sie können auch die Funktion „Letzte Geräteaktivitäten“ aktivieren. Damit sehen Sie, wie oft Ihre App in der letzten Stunde ein Integritäts-Token von einem bestimmten Gerät angefordert hat. Sie können die letzten Geräteaktivitäten verwenden, um Ihre App vor unerwarteten, hyperaktiven Geräten zu schützen, die ein Anzeichen für einen aktiven Angriff sein könnten. Sie können festlegen, wie viel Vertrauen Sie den einzelnen Stufen der letzten Geräteaktivitäten entgegenbringen möchten, je nachdem, wie oft Sie erwarten, dass Ihre App, die auf einem typischen Gerät installiert ist, jede Stunde ein Integritäts-Token anfordert.

Wenn Sie recentDeviceActivity aktivieren, hat 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:

Aktuelles Aktivitätslevel des Geräts Anfragen für Standard-API-Integritäts-Tokens auf diesem Gerät in der letzten Stunde pro App Anfragen für klassische API-Integritäts-Tokens auf diesem Gerät in der letzten Stunde pro App
LEVEL_1 (niedrigste) 10 oder weniger 5 oder weniger
LEVEL_2 Zwischen 11 und 25 Zwischen 6 und 10
LEVEL_3 Zwischen 26 und 50 Zwischen 11 und 15
LEVEL_4 (höchste) Mehr als 50 Mehr als 15
UNEVALUATED Die letzten Geräteaktivitäten wurden nicht ausgewertet. Das kann folgende Gründe haben:
  • Das Gerät ist nicht vertrauenswürdig genug.
  • Die Version der aktuell auf dem Gerät installierten App ist Google Play nicht bekannt.
  • Technische Probleme auf dem Gerät

Geräteattribute

Sie können auch Geräteattribute aktivieren, die die Android SDK-Version des auf dem Gerät ausgeführten Android-Betriebssystems angeben. In Zukunft werden möglicherweise weitere Geräteattribute hinzugefügt.

Der Wert für die SDK-Version ist die Android SDK-Version, 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. Mögliche Gründe:

  • Das Gerät ist nicht vertrauenswürdig genug.
  • Die Version der aktuell auf dem Gerät installierten App ist Google Play nicht bekannt.
  • Es gab technische Probleme mit dem Gerät.

Wenn Sie deviceAttributes aktivieren, wird das Feld deviceIntegrity um das folgende zusätzliche Feld erweitert:

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

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. Er 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 den Nutzern das Dialogfeld GET_LICENSED anzeigen, um das 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üfe, ob der Nutzer eine App-Berechtigung für deine App hat. Dazu musst du prüfen, ob appLicensingVerdict wie erwartet ist, wie im folgenden Code-Snippet gezeigt:

Kotlin

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

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

Java

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

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

Feld „Umgebungsdetails“

Sie können auch zusätzliche Signale zur Umgebung aktivieren. Mit „Risiko von App-Zugriffen“ kann Ihre App prüfen, ob andere ausgeführte Apps den Bildschirm und Overlays aufzeichnen oder das Gerät steuern können. Das Play Protect-Ergebnis gibt an, ob Google Play Protect auf dem Gerät aktiviert ist und ob bekannte Malware gefunden wurde.

Wenn Sie in der Google Play Console das Risikobewertungsergebnis für den App-Zugriff oder das Play Protect-Ergebnis 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

Nach der Aktivierung enthält das Feld environmentDetails in der Play Integrity API-Nutzlast das neue Ergebnis für das 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 des App-Zugriffs 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 beiden Gruppen:

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

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

Es können folgende Antworten 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, mit denen der Bildschirminhalt während der Ausführung Ihrer App eingesehen werden kann. Ausgenommen sind alle bestätigten Bedienungshilfen, die Google Play auf dem Gerät kennt.
KNOWN_CONTROLLING, UNKNOWN_CONTROLLING
Es werden Apps ausgeführt, für die Berechtigungen aktiviert sind, mit denen das Gerät und die Eingaben in Ihre App direkt gesteuert und die Eingaben und Ausgaben Ihrer App erfasst werden können. Dies schließt alle bestätigten Bedienungshilfen aus, die Google Play auf dem Gerät kennt.
KNOWN_OVERLAYS, UNKNOWN_OVERLAYS
Es werden Apps ausgeführt, für die Berechtigungen aktiviert sind, mit denen Overlays in Ihrer App eingeblendet werden können. Dies schließt alle bestätigten Bedienungshilfen aus, die Google Play auf dem Gerät kennt.
Leeres Feld (leerer Wert)

Das Risiko des App-Zugriffs wird nicht bewertet, wenn eine erforderliche Anforderung 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.
  • Das Gerät ist kein Smartphone, Tablet oder faltbares Gerät.
  • Auf dem Gerät wird nicht Android 6 (API-Level 23) oder höher ausgeführt.
  • 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.
  • Nur Spiele: Das Nutzerkonto hat keine Play-Lizenz für das Spiel.
  • 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 für den App-Zugriff schließt automatisch geprüfte Dienste zur Barrierefreiheit aus, die einer erweiterten Google Play-Prüfung zur Barrierefreiheit unterzogen wurden (von einem beliebigen App-Shop auf dem Gerät installiert). „Ausgeschlossen“ bedeutet, dass geprüfte Dienste zur Barrierefreiheit, die auf dem Gerät ausgeführt werden, im Urteil zum Risiko des App-Zugriffs keine Antwort zum Erfassen, Steuern oder Überlagern zurückgeben. Wenn Sie eine erweiterte Google Play-Überprüfung der Barrierefreiheit für Ihre App beantragen möchten, veröffentlichen Sie sie bei Google Play und achten Sie darauf, dass das Flag isAccessibilityTool in der Manifestdatei Ihrer App auf „wahr“ gesetzt ist. Sie können auch eine Überprüfung beantragen.

In der folgenden Tabelle finden Sie einige Beispiele für Entscheidungen und ihre Bedeutung. Diese Tabelle enthält nicht alle möglichen Ergebnisse:

Beispiel für eine Antwort zum Ergebnis des Risikos des App-Zugriffs Interpretation
appsDetected:
["KNOWN_INSTALLED"] 		Es sind nur Apps installiert, die von Google Play erkannt oder vom Gerätehersteller auf der Systempartition vorinstalliert wurden.
Es werden keine Apps ausgeführt, die zu den Befunden „Aufzeichnung“, „Steuerung“ oder „Overlays“ führen würden.
appsDetected:
["KNOWN_INSTALLED",
"UNKNOWN_INSTALLED",
"UNKNOWN_CAPTURING"] 		Es gibt Apps, die von Google Play installiert oder vom Gerätehersteller auf der Systempartition vorinstalliert wurden.
Es werden andere Apps ausgeführt und es sind Berechtigungen aktiviert, mit denen der Bildschirm angezeigt oder andere Eingaben und Ausgaben erfasst werden können.
appsDetected:
["KNOWN_INSTALLED",
"KNOWN_CAPTURING",
"UNKNOWN_INSTALLED",
"UNKNOWN_CONTROLLING"] 		Es werden Google Play- oder Systemprozesse ausgeführt, für die Berechtigungen aktiviert sind, mit denen der Bildschirm angezeigt oder andere Eingaben und Ausgaben erfasst werden können.
Es werden auch andere Apps ausgeführt, für die Berechtigungen aktiviert sind, mit denen das Gerät und die Eingaben in Ihre App direkt gesteuert werden können.
appAccessRiskVerdict: {} Das Risiko für den App-Zugriff wird nicht bewertet, da eine erforderliche Voraussetzung nicht erfüllt wurde. Beispielsweise war das Gerät nicht vertrauenswürdig genug.

Je nach Risikolevel können Sie entscheiden, welche Kombination von Entscheidungen für Sie akzeptabel ist und bei welchen Entscheidungen Sie Maßnahmen ergreifen möchten. Im folgenden Code-Snippet wird beispielsweise geprüft, ob keine Apps ausgeführt werden, die den Bildschirm aufnehmen oder Ihre App steuern könnten:

Kotlin

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

Java

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!
    }
}
Ergebnisse zum Risiko des App-Zugriffs beheben

Je nach Risikostufe können Sie festlegen, bei welchen Risikobewertungen für den App-Zugriff Sie Maßnahmen ergreifen möchten, bevor der Nutzer eine Anfrage oder Aktion ausführen kann. Es gibt optionale Google Play-Aufforderungen, die Sie dem Nutzer anzeigen können, nachdem Sie das Risikourteil für den App-Zugriff geprüft haben. Sie können CLOSE_UNKNOWN_ACCESS_RISK anzeigen, um den Nutzer aufzufordern, unbekannte Apps zu schließen, die das Risiko für den App-Zugriff verursachen. Sie können auch CLOSE_ALL_ACCESS_RISK anzeigen, um den Nutzer aufzufordern, alle Apps (bekannte und unbekannte) zu schließen, die das Risiko für den App-Zugriff verursachen.

Play Protect-Urteil

Nach der Aktivierung enthält das Feld environmentDetails in der Play Integrity API-Nutzlast das Play Protect-Urteil:

environmentDetails: {
  playProtectVerdict: "NO_ISSUES"
}

playProtectVerdict kann einen der folgenden Werte haben:

NO_ISSUES
Play Protect ist aktiviert und es wurden keine App-Probleme auf dem Gerät gefunden.
NO_DATA
Play Protect ist aktiviert, aber es wurde noch keine Suche durchgeführt. Möglicherweise wurden das Gerät oder die Play Store App 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-Urteil wurde nicht bewertet.

Dafür kann es verschiedene Gründe geben:

  • Das Gerät ist nicht vertrauenswürdig genug.
  • Nur Spiele: Das Nutzerkonto hat keine Play-Lizenz für das Spiel.

Informationen zur Verwendung des Play Protect-Urteils

Der Backend-Server Ihrer App kann auf Grundlage des Ergebnisses und Ihrer Risikotoleranz entscheiden, wie er vorgehen soll. Hier sind einige Vorschläge und mögliche Nutzeraktionen:

NO_ISSUES
Play Protect ist aktiviert und es wurden keine Probleme gefunden. Sie müssen nichts weiter unternehmen.
POSSIBLE_RISK und NO_DATA
Wenn du eine dieser Meldungen erhältst, bitte 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 Risikotoleranz können Sie den Nutzer bitten, Play Protect zu starten und Maßnahmen bezüglich der Play Protect-Warnungen zu ergreifen. Wenn der Nutzer diese Anforderungen nicht erfüllt, kannst du ihn für die Serveraktion blockieren.
Zurück
Klassische Anfrage stellen
Weiter
Fehlercodes verarbeiten