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 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 zusätzliche Labels im Integritätsurteil 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. Für Geräte mit Android 13 oder höher ist die Schlüsselattestierung der Android-Plattform erforderlich. 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, der Bootvorgang nicht verifiziert wurde 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. Für Geräte mit Android 13 oder höher ist außerdem ein Sicherheitsupdate im letzten Jahr erforderlich. Das Gerät besteht die Systemintegritätsprüfungen und erfüllt die Android-Kompatibilitätsanforderungen.
Für ein einzelnes Gerät werden mehrere Gerätelabels im Urteil zur Geräteintegrität 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:
|
Geräteattribute
Sie können auch Geräteattribute aktivieren, die die Android SDK-Version des Android-Betriebssystems auf dem Gerät angeben. In Zukunft wird es möglicherweise um weitere Geräteattribute erweitert.
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 dem Risiko von App-Zugriffen kann Ihre App prüfen, ob andere Apps ausgeführt werden, die möglicherweise den Bildschirm aufnehmen, Overlays einblenden oder das Gerät steuern. 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 für den App-Zugriff 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 mitKNOWN_
.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-Prüfung der Barrierefreiheit für Ihre App beantragen möchten, veröffentlichen Sie sie bei Google Play und achten Sie darauf, dass im Manifest Ihrer App das Flag isAccessibilityTool
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, die dazu verwendet werden könnten, den Bildschirm anzusehen oder andere Eingaben und Ausgaben aufzuzeichnen. |
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 Risikourteil für den App-Zugriff verursacht haben. Sie können auch CLOSE_ALL_ACCESS_RISK anzeigen, um den Nutzer aufzufordern, alle Apps (bekannte und unbekannte) zu schließen, die das Risikourteil für den App-Zugriff verursacht haben.
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 wurde 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 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
undNO_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
undHIGH_RISK
- Je nach Risikobereitschaft 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 von der Serveraktion ausschließen.