Jeśli weryfikujesz odpowiedzi za pomocą zaufanego serwera, możesz łatwo przejść z SafetyNet Attestation API na Play Integrity API. Interfejs Play Integrity API może też zastąpić testy licencjonowania aplikacji wykonywane bezpośrednio w aplikacji Sklep Play przez AIDL, np. przez bibliotekę weryfikacji licencji (LVL). Większość wymaganych zmian będzie wprowadzana po stronie zaufanego serwera, który musi odczytywać i analizować token odpowiedzi Play Integrity. Pamiętaj, że podczas migracji zarówno aplikacja, jak i serwer muszą obsługiwać oba interfejsy API, aby obsługiwać starsze klienty, które nie zostały jeszcze zaktualizowane.
Jeśli przyznano Twojej aplikacji większe limity dla interfejsu SafetyNet Attestation API, sprawdź przypisany poziom wykorzystania interfejsu Play Integrity API i w razie potrzeby poproś o przejście na wyższy poziom.
Do obsługi interfejsu Play Integrity API niezbędne są te zmiany:
Klient na Androida:
- Sprawdź, czy kod przekazuje prawidłowo sformatowany identyfikator jednorazowy do konstruktora
IntegrityTokenRequest:String(zamiast tablicy bajtów)- Do wykorzystania w adresie URL
- Zakodowane w formacie Base64 i bez opakowania
- Minimum 16 znaków
- Może mieć maksymalnie 500 znaków.
- Sprawdź logikę ponawiania prób i upewnij się, że aplikacja prawidłowo obsługuje błędy.
- Upewnij się, że dane odpowiedzi wysyłane do zaufanego serwera umożliwiają rozróżnienie odpowiedzi interfejsu SafetyNet Attestation API od odpowiedzi interfejsu Play Integrity API.
Zaufany serwer:
- Sprawdź logikę generowania identyfikatorów jednorazowych i upewnij się, że spełnia ona wymagania interfejsu Play Integrity API.
- Upewnij się, że kod serwera może odróżnić odpowiedzi interfejsu SafetyNet Attestation API od odpowiedzi interfejsu Play Integrity API. Upewnij się, że kod poprawnie analizuje i weryfikuje te odpowiedzi.
- Dodaj logikę do weryfikowania i analizowania odpowiedzi interfejsu Play Integrity API.
- Nowa odpowiedź interfejsu Play Integrity API zawiera dodatkowe szczegóły, dlatego może być konieczne ulepszenie logiki podejmowania decyzji i danych opinii wysyłanych z powrotem na urządzenia klienckie. Więcej informacji znajdziesz w sekcji Mapowanie odpowiedzi interfejsu API w tym temacie.
Kodowanie jednorazowe
Liczba jednorazowa związana z integracją musi zostać przekazana do interfejsu Play Integrity API jako zakodowana w formacie Base64, bezpieczna w adresie URL i niezapakowana.String Ten format różni się od interfejsu SafetyNet Attestation API, który wymaga byte[].
- Bezpieczny adres URL oznacza użycie wariantu Base64 „URL i bezpieczny na podstawie nazwy pliku” (zob. RFC 4648, sekcja 5), gdzie „-” i „_” zamiast „+” i „/”. Więcej informacji o kodowaniu Base64 znajdziesz w RFC 4648.
- „no-wrap” oznacza pominięcie wszystkich znaków końcowych wiersza. Wynik to jeden długi wiersz.
.setNonce(Base64.encodeToString(NONCE_BYTES,
Base64.URL_SAFE | Base64.NO_WRAP))
Upewnij się też, że generowanie liczby jednorazowej jest zgodne ze wskazówkami dotyczącymi interfejsu Play Integrity API.
Mapowanie odpowiedzi interfejsu API
W tabeli poniżej mapujemy pola interfejsu SafetyNet Attestation API na ich odpowiedniki w Play Integrity API.
| SafetyNet Attestation API | Play Integrity API | Notes | |
timestampMs |
requestDetails.timestampMillis
|
||
nonce |
requestDetails.nonce |
||
apkPackageName |
appIntegrity.packageName
|
||
apkCertificateDigestSha256
|
appIntegrity.certificateSha256Digest
|
Sprawdź, czy właściwość appRecognitionVerdict ma wartość PLAY_RECOGNIZED
|
|
ctsProfileMatch |
Połączone w deviceIntegrity.deviceRecognitionVerdict
|
||
basicIntegrity |
Połączone w deviceIntegrity.deviceRecognitionVerdict
|
||
evaluationType |
Połączone w deviceIntegrity.deviceRecognitionVerdict
|
||
advice |
Not available |
||
error
|
Not available
|
Lista etykiet integralności urządzenia będzie pusta. |
Mapowanie oceny integralności urządzenia
| Interfejs API atestu SafetyNet | Play Integrity API | ||
ctsProfileMatch
|
basicIntegrity
|
evaluationType
|
deviceRecognitionVerdict
|
FALSE |
FALSE |
Brak etykiet | |
FALSE |
TRUE |
MEETS_BASIC_INTEGRITY |
|
TRUE |
FALSE |
Brak etykiet | |
TRUE |
TRUE |
BASIC
|
MEETS_DEVICE_INTEGRITY, MEETS_BASIC_INTEGRITY
|
TRUE |
TRUE |
HARDWARE_BACKED |
MEETS_STRONG_INTEGRITY, MEETS_DEVICE_INTEGRITY,
MEETS_BASIC_INTEGRITY
|
Jeśli Twoja aplikacja korzysta ze złożonej strategii wymuszania i wymaga wszystkich możliwych wartości, może być konieczne skonfigurowanie zestawu odpowiedzi dotyczących integralności urządzenia.
Logika ponawiania prób w Play Integrity API
W przypadku wystąpienia określonych kodów błędów aplikacja powinna ponawiać wywołania interfejsu API. Sprawdź wszystkie kody błędów i zadbaj o to, by w razie potrzeby aplikacja ponawiała próby ze wzrastającym czasem do ponowienia. Upewnij się, że minimalne opóźnienie wynosi co najmniej 5 sekund i zwiększa się wykładniczo (5 s, 10 s, 20 s, 40 s itd.), aby zapewnić interfejsowi API wystarczająco dużo czasu na ocenę integralności urządzenia i aplikacji.
Opcjonalna wymiana interfejsu App Licensing API
Jeśli korzystasz z interfejsu App Licensing API, możesz opcjonalnie przejść na interfejs Play Integrity API, ponieważ token Play Integrity API zawiera informacje o licencjonowaniu aplikacji. Podobnie jak w przypadku migracji interfejsu SafetyNet Attestation API na wielu urządzeniach można spodziewać się zachowania starszej wersji aplikacji. Twój zaufany serwer powinien móc przetwarzać zarówno odpowiedzi interfejsu App Licensing API, jak i Play Integrity API.
Otrzymuj odpowiedzi do całkowitego wyłączenia
Jeśli przed terminem migracji (czyli do 31 stycznia 2024 r.) nie korzystasz jeszcze z interfejsu Play Integrity API ani nie usunięto certyfikatu SafetyNet, możesz poprosić o przedłużenie terminu, wypełniając ten formularz. Jeśli uzyskasz zgodę na przedłużenie terminu, Twoja aplikacja będzie nadal otrzymywać odpowiedzi z atestu SafetyNet aż do ostatecznego terminu wyłączenia tej funkcji (31 stycznia 2025 r.).