Integritätsergebnisse

Auf dieser Seite wird beschrieben, wie Sie die zurückgegebene Integrität interpretieren und damit arbeiten können. Unabhängig davon, ob Sie eine standardmäßige oder klassische API-Anfrage stellen, Das Ergebnis wird im selben Format mit ähnlichem Inhalt zurückgegeben. Die Integrität das Ergebnis Informationen über die Gültigkeit von Geräten, Apps und Konten. Der Server Ihrer App kann die resultierende Nutzlast in einem entschlüsselten, ein bestätigtes Ergebnis, um zu bestimmen, wie mit einer bestimmten Aktion oder -Anforderung in Ihrer App.

Format des zurückgegebenen Integritätsergebnisses

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

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 übereinstimmen der ursprünglichen Anfrage, bevor jedes Integritätsergebnis geprüft wird. Die folgenden beschreiben die einzelnen Felder genauer.

Feld „Anfragedetails“

Das Feld requestDetails enthält Informationen zur Anfrage, darunter: vom Entwickler bereitgestellte Informationen in der requestHash für Standardanfragen und nonce für klassische Anfragen.

Für standardmäßige 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. Überprüfen Sie daher die requestDetails der JSON-Nutzlast hinzu. Achte darauf, dass der requestPackageName und requestHash stimmen mit den Angaben überein, die im Original 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. Überprüfen Sie daher die requestDetails der JSON-Nutzlast hinzu. Achte darauf, dass der requestPackageName und nonce stimmen mit den Angaben in der ursprünglichen Anfrage überein: wie im folgenden Code-Snippet dargestellt:

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 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 Versionen, die von Google Play

UNRECOGNIZED_VERSION

Das Zertifikat oder der Paketname stimmt nicht mit Google überein Rekorde bei Google Play.

UNEVALUATED

Die Anwendungsintegrität wurde nicht bewertet. Eine erforderliche Voraussetzung was übersehen wurde, weil das Gerät nicht vertrauenswürdig genug ist.

Prüfen Sie, ob das Token von einer von Ihnen erstellten App generiert wurde. dass die Anwendungsintegrität wie erwartet ist, wie im folgenden Code dargestellt snippet:

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 auch den Paketnamen der App, die App-Version und die App-Zertifikate prüfen. manuell.

Feld „Geräteintegrität“

Das Feld deviceIntegrity kann einen einzelnen Wert enthalten, deviceRecognitionVerdict mit einem oder mehreren Labels, die angeben, wie gut ein App-Integrität erzwingen. Wenn ein Gerät die Kriterien Labels enthält, 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 ausgeführt, Google Play-Dienste. Das Gerät besteht die Systemintegritätsprüfungen und erfüllt Android-Kompatibilitätsanforderungen

Leer (leerer Wert)

Die App wird auf einem Gerät ausgeführt, das Anzeichen von Angriff (z. B. API-Hooks) oder Systemmanipulation (z. B. gerootet) oder die App nicht auf einem physischen Gerät (z. B. einem Emulator, der nicht die Google Play-Integritätsprüfungen bestehen).

Prüfen Sie, ob das Token von einem vertrauenswürdigen Gerät stammt. deviceRecognitionVerdict entspricht den Erwartungen, wie im folgenden Code gezeigt. snippet:

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 Ihr Testgerät die Geräteintegrität erfüllt, Vergewissern Sie sich, dass das Factory ROM installiert ist (z. B. durch Zurücksetzen des Geräts). und dass der Bootloader gesperrt ist. Du kannst auch Play Integrity API-Tests erstellen in der Play Console.

Bedingte Gerätelabels

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

MEETS_VIRTUAL_INTEGRITY

Die App läuft auf einem Android-Emulator mit Google Play-Dienste. Der Emulator hat die Systemintegritätsprüfungen bestanden und erfüllt grundlegende Android-Kompatibilitätsanforderungen.

Optionale Geräteinformationen

Falls Sie sich damit einverstanden erklären, zusätzliche Labels im Integritätsergebnis, deviceRecognitionVerdict kann die folgenden zusätzlichen Labels enthalten:

MEETS_BASIC_INTEGRITY

Die App wird auf einem Gerät ausgeführt, das die grundlegenden Systemintegritätsprüfungen. Das Gerät ist möglicherweise nicht mit Android kompatibel Anforderungen und werden möglicherweise nicht zum Ausführen von Google Play-Diensten genehmigt. Für Es kann beispielsweise sein, dass auf dem Gerät eine nicht erkannte Android-Version ausgeführt wird, einen entsperrten Bootloader haben oder nicht vom Hersteller.

MEETS_STRONG_INTEGRITY

Die App wird auf einem Android-Gerät ausgeführt, Google Play-Dienste bereitgestellt wird und eine starke Garantie für die Systemintegrität bietet, z. B. einen hardwaregestützten Nachweis der Bootintegrität. Das Gerät besteht das System Integritätsprüfungen ausführt und die Android-Kompatibilitätsanforderungen erfüllt.

Für ein einzelnes Gerät werden in der Geräteintegrität mehrere Gerätelabels zurückgegeben ob jedes Kriterium des Labels erfüllt ist.

Letzte Geräteaktivitäten

Sie können auch die letzten Geräteaktivitäten aktivieren, um zu erfahren, Ihre App hat oft ein Integritätstoken auf einem bestimmten Gerät angefordert in der letzten Stunde. Du kannst deine App anhand der letzten Geräteaktivitäten schützen unerwartete hyperaktive Geräte, die ein Hinweis auf einen aktiven Angriff sein könnten. Sie können festlegen, wie vertrauenswürdig die letzten Aktivitätsstufen der einzelnen Geräte sind – je nachdem, wie oft Sie davon ausgehen, dass Ihre App auf einem typischen Gerät eine des Integritätstokens stündlich.

Wenn Sie zustimmen, recentDeviceActivity das Feld deviceIntegrity zu erhalten hat zwei Werte:

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

Die deviceActivityLevel-Definitionen unterscheiden sich je nach Modus und können einer der folgenden Werte:

Feld „Kontodetails“

Das Feld accountDetails enthält den einzelnen Wert appLicensingVerdict, der stellt den Google Play-Lizenzierungsstatus der App für das Nutzerkonto dar, auf dem Gerät angemeldet sind. Wenn das Nutzerkonto die Play-Lizenz für die App hat, das heißt, sie haben es bei Google Play heruntergeladen oder gekauft.

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. Mit anderen Worten, der Nutzer hat oder Ihre App bei Google Play gekauft haben.

UNLICENSED

Der Nutzer hat keine App-Berechtigung. Das passiert, wenn zum Beispiel wenn er die App per Sideload oder nicht bei Google Play heruntergeladen hat. Sie können Nutzern das Dialogfeld GET_LicenseD anzeigen lassen, um dies zu beheben.

UNEVALUATED

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

Dafür kann es verschiedene Gründe geben:

• Das Gerät ist nicht vertrauenswürdig genug.
• Die Version deiner App, die auf dem Gerät installiert ist, ist Google nicht bekannt Spielen.
• Der Nutzer ist nicht in Google Play angemeldet.

Um zu prüfen, ob der Nutzer eine App-Berechtigung für deine App hat, musst du das appLicensingVerdict entspricht den Erwartungen, wie im folgenden Code-Snippet gezeigt:

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 „Umgebungsdetails“

Sie können auch zusätzliche Signale zur Umgebung aktivieren. App-Zugriff Risiko der App erkennen, ob andere Apps ausgeführt werden, die für Bildschirm aufnehmen, Overlays anzeigen oder das Gerät steuern. Play Protect wird Ihnen angezeigt, ob Google Play Protect auf dem Gerät aktiviert ist und und bekannte Malware gefunden.

Wenn Sie dem Ergebnis „App Access Risk“ oder „Play Protect“ zugestimmt haben in der Google Play Console enthält, enthält Ihre API-Antwort den environmentDetails. Das Feld environmentDetails kann zwei appAccessRiskVerdict und playProtectVerdict.

Ergebnis zum Risiko des App-Zugriffs (Beta)

Nach der Aktivierung wird das Feld environmentDetails in der Play Integrity API aktiviert Payload enthält das neue Ergebnis zum Risiko des App-Zugriffs.

{
  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 in eine der folgenden zwei Gruppen, je nach Installationsquelle der erkannten Apps:

• Play- oder System-Apps: Apps, die über Google Play installiert oder vorab geladen werden des Geräteherstellers auf der Systempartition des Geräts (identifiziert mit FLAG_SYSTEM) Antworten für solche Apps haben das Präfix KNOWN_.

• Andere Apps: Apps, die nicht über Google Play installiert wurden Hiervon ausgenommen sind Apps, die vom Gerätehersteller auf der Systempartition vorinstalliert wurden Antworten für solche Apps ist UNKNOWN_ vorangestellt.

Folgende Antworten können zurückgegeben werden:

KNOWN_INSTALLED, UNKNOWN_INSTALLED

Es sind Apps installiert, die mit der entsprechenden Installationsquelle übereinstimmen.

KNOWN_CAPTURING, UNKNOWN_CAPTURING

Es werden Apps mit aktivierten Berechtigungen ausgeführt, die für Folgendes verwendet werden könnten: den Bildschirm sehen, während die App ausgeführt wird. Bestätigte Conversions sind ausgeschlossen. Bedienungshilfen, die Google Play bekannt sind, auf dem Gerät ausführen.

KNOWN_CONTROLLING, UNKNOWN_CONTROLLING

Es werden Apps mit aktivierten Berechtigungen ausgeführt, die für Folgendes verwendet werden könnten: das Gerät und die Eingaben in deiner App direkt zu steuern. zur Erfassung der Ein- und Ausgaben Ihrer App. Bestätigte Conversions sind ausgeschlossen. auf dem Gerät ausgeführte Bedienungshilfen, die Google Play bekannt sind.

KNOWN_OVERLAYS, UNKNOWN_OVERLAYS

Es werden Apps mit aktivierten Berechtigungen ausgeführt, die für Folgendes verwendet werden könnten: Overlays in Ihrer App einblenden. Bestätigte Bedienungshilfen werden ausgeschlossen. die Google Play bekannten Dienste auf dem Gerät ausführen.

EMPTY (leerer Wert)

Das Risiko des App-Zugriffs wird nicht bewertet, wenn eine erforderliche Anforderung nicht erfüllt wurde. In In diesem Fall ist das Feld appAccessRiskVerdict leer. Das kann bei verschiedenen Dafür kann es verschiedene Gründe geben, z. B.:

• Das Gerät ist nicht vertrauenswürdig genug.
• Der Formfaktor des Geräts 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 Google Play-Lizenz für das Spiel.
• Mit dem Parameter verdictOptOut wurde eine Standardanfrage verwendet.
• Eine Standardanfrage wurde mit einer Version der Play Integrity API-Bibliothek verwendet das App-Zugriffsrisiken für Standardanfragen noch nicht unterstützt.

Beim Risiko des App-Zugriffs werden verifizierte Bedienungshilfen, die eine verbesserte Prüfung auf Barrierefreiheit bei Google Play durchgeführt (installiert von einem beliebigen App-Shop auf dem Gerät). „Ausgeschlossen“ dass die bestätigte Zugänglichkeit der auf dem Gerät ausgeführten Dienste keine Erfassungs-, Steuerungs- oder Overlays-Antwort im Ergebnis zum Risiko des App-Zugriffs. Um eine erweiterte Google Prüfung der Barrierefreiheit deiner App abspielen und bei Google veröffentlichen Achte darauf, dass das isAccessibilityTool-Flag in deiner App im folgenden Beispiel auf „true“ gesetzt ist das Manifest Ihrer App an oder fordern Sie eine Überprüfung an.

Die folgende Tabelle enthält einige Beispiele für Ergebnisse und ihre Bedeutung (diese nicht alle möglichen Ergebnisse enthält):

Abhängig von Ihrem Risikoniveau können Sie entscheiden, welche Kombination von Ergebnissen akzeptabel ist, und welche Ergebnisse du ergreifen möchtest. Die Das folgende Code-Snippet zeigt ein Beispiel für die Überprüfung, ausgeführte Apps, die den Bildschirm erfassen oder Ihre App steuern können:

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

Ergebnisse zu App-Zugriffsrisiken korrigieren

Abhängig von Ihrem Risikoniveau können Sie entscheiden, welche Einstufungen Sie zum Risiko des App-Zugriffs treffen möchten bevor der Nutzer eine Anfrage oder Aktion ausführen kann. Es gibt optionale Aufforderungen von Google Play, die du dem Nutzer anschließend anzeigen kannst das Ergebnis zum Risiko des App-Zugriffs prüfen. Sie können CLOSE_UNKNOWN_ACCESS_RISK: Der Nutzer wird aufgefordert, unbekannte Apps zu schließen, die den Fehler verursachen Ergebnis zum Risiko des App-Zugriffs oder Sie können CLOSE_ALL_ACCESS_RISK zeigen, um das Nutzer alle bekannten und unbekannten Apps zu schließen, was zu dem Ergebnis zum Risiko des App-Zugriffs führt.

Play Protect-Ergebnis

Nach der Aktivierung wird das Feld environmentDetails in der Play Integrity API aktiviert Payload enthält das Play Protect-Ergebnis:

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 kein Scan durchgeführt. Das Gerät oder wurde die Play Store App 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 auf dem Gerät.

HIGH_RISK

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

UNEVALUATED

Das Play Protect-Ergebnis 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 Google Play-Lizenz für das Spiel.

Anleitung zur Verwendung des Play Protect-Ergebnisses

Der Backend-Server deiner App kann anhand des Ergebnisses entscheiden, Ihre Risikotoleranz. Hier einige Vorschläge und mögliche Aktionen von Nutzern:

NO_ISSUES

Play Protect ist aktiviert und es wurden keine Probleme festgestellt, sodass keine Nutzeraktion erforderlich ist.

POSSIBLE_RISK und NO_DATA

Bitte den Nutzer beim Erhalt dieser Ergebnisse zu prüfen, ob Play Protect aktiviert ist und hat einen Scan durchgeführt. NO_DATA sollte nur in seltenen Fällen angezeigt werden.

MEDIUM_RISK und HIGH_RISK

Je nach Risikotoleranz kannst du den Nutzer bitten, Google Play zu starten Play Protect-Warnungen schützen und entsprechende Maßnahmen ergreifen Wenn der Nutzer das Formular nicht ausfüllen kann diese Anforderungen nicht erfüllen, könnten Sie sie von der Serveraktion ausschließen.