Wenn Sie Antworten bereits mit einem vertrauenswürdigen Server verifizieren, ist die Migration von der SafetyNet Attestation API zur Play Integrity API unkompliziert. Die Play Integrity API kann auch als Ersatz für App-Lizenzierungsprüfungen verwendet werden, die direkt mit der Play Store App über AIDL durchgeführt werden, z. B. über die Licensing Verification Library (LVL). Die meisten erforderlichen Änderungen werden auf der vertrauenswürdigen Serverseite vorgenommen. Diese muss das Play Integrity-Antworttoken lesen und analysieren. Beachten Sie, dass während der Migration sowohl die Anwendung als auch der Server beide APIs gleichzeitig unterstützen müssen, um ältere Clients zu unterstützen, die noch nicht aktualisiert wurden.
Wenn Ihrer App höhere Kontingentlimits für die SafetyNet Attestation API gewährt wurden, sollten Sie die zugewiesene Nutzungsstufe für die Play Integrity API prüfen und bei Bedarf eine Anfrage zum Wechsel zur erhöhten Stufe senden.
Die folgenden Änderungen sind für die Unterstützung der Play Integrity API erforderlich:
Android-Client:
- Achten Sie darauf, dass der Code die richtig formatierte Nonce an den
IntegrityTokenRequest-Builder übergibt:String(anstelle eines Byte-Arrays)- URL-sicher
- Als Base64 codiert und ohne Wrapping
- Mindestens 16 Zeichen
- Maximal 500 Zeichen.
- Prüfen Sie die Wiederholungslogik und achten Sie darauf, dass die Anwendung Fehler entsprechend verarbeitet.
- Achten Sie darauf, dass die an den vertrauenswürdigen Server gesendeten Antwortdaten die Unterscheidung zwischen Antworten der SafetyNet Attestation API und der Play Integrity API ermöglichen.
Vertrauenswürdiger Server:
- Prüfen Sie die Logik zur Nonce-Generierung und achten Sie darauf, dass sie den Anforderungen der Play Integrity API entspricht.
- Achte darauf, dass der Servercode zwischen SafetyNet Attestation API-Antworten und Play Integrity API-Antworten unterscheiden kann. Achten Sie darauf, dass der Code diese Antworten korrekt parst und validiert.
- Fügen Sie Logik zum Validieren und Parsen von Play Integrity API-Antworten hinzu.
- Da die neue Play Integrity API-Antwort zusätzliche Details enthält, müssen möglicherweise die Entscheidungsfindungslogik und die an die Clientgeräte gesendeten Feedbackdaten verbessert werden. Weitere Informationen finden Sie im Abschnitt API-Antwortzuordnung in diesem Thema.
Nonce-Codierung
Eine integritätsbezogene Nonce muss als Base64-codiert, URL-sicher und nicht gepackt String an die Play Integrity API übergeben werden. Dieses Format unterscheidet sich von der SafetyNet Attestation API, für die byte[] erforderlich ist.
- „URL-sicher“ bedeutet, dass die Base64-Variante „URL- und Dateiname-sicher“ verwendet wird (siehe Abschnitt 5 von RFC 4648), wobei „-“ und „_“ anstelle von „+“ und „/“ verwendet werden. Weitere Informationen zur Base64-Codierung finden Sie unter RFC 4648.
- "no-wrap" bedeutet, dass alle Zeilenabschlusszeichen ausgelassen werden. Das bedeutet, dass die Ausgabe eine einzelne lange Zeile ist.
.setNonce(Base64.encodeToString(NONCE_BYTES,
Base64.URL_SAFE | Base64.NO_WRAP))
Achten Sie außerdem darauf, dass die Nonce-Generierung den Richtlinien der Play Integrity API entspricht.
API-Antwortzuordnung
In der folgenden Tabelle werden die Felder der SafetyNet Attestation API ihren Entsprechungen der Play Integrity API zugeordnet.
| SafetyNet Attestation API | Play Integrity API | Notizen | |
timestampMs |
requestDetails.timestampMillis
|
||
nonce |
requestDetails.nonce |
||
apkPackageName |
appIntegrity.packageName
|
||
apkCertificateDigestSha256
|
appIntegrity.certificateSha256Digest
|
appRecognitionVerdict muss auf PLAY_RECOGNIZED festgelegt sein
|
|
ctsProfileMatch |
Zusammengefasst in deviceIntegrity.deviceRecognitionVerdict
|
||
basicIntegrity |
Zusammengefasst in deviceIntegrity.deviceRecognitionVerdict
|
||
evaluationType |
Zusammengefasst in deviceIntegrity.deviceRecognitionVerdict
|
||
advice |
Not available |
||
error
|
Not available
|
Die Liste der Geräteintegritätslabels ist leer. |
Zuordnung des Ergebnisses der Geräteintegrität
| SafetyNet Attestation API | Play Integrity API | ||
ctsProfileMatch
|
basicIntegrity
|
evaluationType
|
deviceRecognitionVerdict
|
FALSE |
FALSE |
Keine Kennzeichnungen | |
FALSE |
TRUE |
MEETS_BASIC_INTEGRITY |
|
TRUE |
FALSE |
Keine Kennzeichnungen | |
TRUE |
TRUE |
BASIC
|
MEETS_DEVICE_INTEGRITY, MEETS_BASIC_INTEGRITY
|
TRUE |
TRUE |
HARDWARE_BACKED |
MEETS_STRONG_INTEGRITY, MEETS_DEVICE_INTEGRITY,
MEETS_BASIC_INTEGRITY
|
Möglicherweise müssen Sie den Satz der Geräteintegritätsantworten konfigurieren, wenn Ihre Anwendung eine komplexe Erzwingungsstrategie verwendet und alle möglichen Werte benötigt.
Wiederholungslogik der Play Integrity API
Bei bestimmten Fehlercodes sollte eine Anwendung API-Aufrufe wiederholen. Prüfen Sie alle Fehlercodes und sorgen Sie dafür, dass die Anwendung bei Bedarf den Vorgang mit exponentiellem Backoff wiederholt. Achten Sie darauf, dass die minimale Verzögerung mindestens 5 Sekunden beträgt und exponentiell ansteigt (5 Sekunden, 10 Sekunden, 20 Sekunden, 40 Sekunden usw.), damit die API genügend Zeit hat, um die Geräte- und Anwendungsintegrität zu bewerten.
Optionaler Austausch des App Licensing API
Wenn Sie die App Licensing API verwenden, können Sie optional zur Play Integrity API migrieren, da ein Play Integrity API-Token die Lizenzinformationen der App enthält. Wie bei der SafetyNet Attestation API-Migration sollten Sie davon ausgehen, dass auf einigen Geräten eine ältere Version der Anwendung beibehalten wird. Ihr vertrauenswürdiger Server sollte sowohl Antworten der App Licensing API als auch Play Integrity API verarbeiten können.
Antworten erhalten, bis die Deaktivierung abgeschlossen ist
Wenn Sie noch nicht zur Play Integrity API migriert oder die SafetyNet-Attestation vor Ablauf der Migrationsfrist (31. Januar 2024) noch nicht entfernt haben, können Sie dieses Formular ausfüllen, um eine Verlängerung zu beantragen. Wenn eine Verlängerung genehmigt wird, erhält Ihre App bis zur vollständigen Einstellungsfrist (31. Januar 2025) weiterhin Antworten aus der SafetyNet Attestation.