SafetyNet Attestation API からの移行

すでに信頼できるサーバーを使用してレスポンスを検証している場合、SafetyNet Attestation API から Play Integrity API への移行は簡単です。Play Integrity API は、AIDL を介して Google Play ストアアプリで直接実行されるアプリのライセンスのチェック（Licensing Verification Library（LVL）によって実行されるものなど）の代替手段としても使用できます。必要な変更のほとんどは信頼できるサーバーサイドで行われるため、必要な作業は Play Integrity レスポンストークンの読み取りと分析だけです。まだ更新していない古いクライアントをサポートするには、移行中に、アプリとサーバーの両方で両方の API を同時にサポートする必要があることに留意してください。

SafetyNet Attestation API の割り当て上限が引き上げられたアプリの場合は、割り当てられている Play Integrity API の使用量ティアを確認し、必要に応じてティアの引き上げをリクエストしてください。

Play Integrity API をサポートするには、次の変更が必要です。

Android クライアント:

コードが正しい形式のノンスを IntegrityTokenRequest ビルダーに渡すようにします。
- String（バイト配列ではなく）
- URL-safe
- Base64、ラップなしでエンコード
- 16 文字以上
- 500 文字以下
再試行ロジックを確認し、アプリがエラーを適切に処理できるようにします。
信頼できるサーバーに送信されるレスポンスデータで、SafetyNet Attestation API レスポンスと Play Integrity API レスポンスを区別できるようにします。

信頼できるサーバー:

ノンスの生成ロジックを確認し、Play Integrity API の要件を満たすようにします。
サーバーコードで、SafetyNet Attestation API レスポンスと Play Integrity API レスポンスを区別できるようにします。コードでこれらのレスポンスが適切に解析および検証されるようにします。
Play Integrity API レスポンスの検証と解析を行うロジックを追加します。
新しい Play Integrity API レスポンスでは詳細な情報が得られるため、意思決定ロジックと、クライアントデバイスに返送されるフィードバックデータを強化することが必要な場合があります。詳細については、このトピック内の API レスポンスのマッピングセクションをご覧ください。

ノンスエンコード

整合性関連のノンスは、Base64 ベースエンコード、URL セーフ、かつラップなし String として Play Integrity API に渡す必要があります。この形式は、byte[] を必要とする SafetyNet Attestation API とは異なります。

「URL セーフ」は、Base64 の「URL セーフおよびファイル名セーフ」のバリアントを使用することを意味します（RFC 4648 のセクション 5 を参照）。「URL セーフ」では「+」と「/」の代わりに「-」と「_」が使用されます。Base64 エンコードの詳細については、RFC 4648 をご覧ください。
「ラップなし」は、すべての行終端子を省略することを意味します。つまり、出力は単一の長い行になります。

.setNonce(Base64.encodeToString(NONCE_BYTES,
        Base64.URL_SAFE | Base64.NO_WRAP))

さらに、Play Integrity API ガイドラインに沿ってノンスが生成されるようにします。

API レスポンスのマッピング

次の表では、SafetyNet Attestation API のフィールドを、Play Integrity API の対応するフィールドにマッピングしています。

SafetyNet Attestation API	Play Integrity API	注
`timestampMs`	`requestDetails.timestampMillis`
`nonce`	`requestDetails.nonce`
`apkPackageName`	`appIntegrity.packageName`
`apkCertificateDigestSha256`	`appIntegrity.certificateSha256Digest`	`appRecognitionVerdict` が `PLAY_RECOGNIZED` に設定されるようにします。
`ctsProfileMatch`	`deviceIntegrity.deviceRecognitionVerdict` への統合
`basicIntegrity`	`deviceIntegrity.deviceRecognitionVerdict` への統合
`evaluationType`	`deviceIntegrity.deviceRecognitionVerdict` への統合
`advice`	`Not available`
`error`	`Not available`	デバイスの完全性ラベルのリストは空になります。

デバイスの完全性判定の結果のマッピング

SafetyNet Attestation API			Play Integrity API
`ctsProfileMatch`	`basicIntegrity`	`evaluationType`	`deviceRecognitionVerdict`
`FALSE`	`FALSE`		ラベルなし
`FALSE`	`TRUE`		`MEETS_BASIC_INTEGRITY`
`TRUE`	`FALSE`		ラベルなし
`TRUE`	`TRUE`	`BASIC`	`MEETS_DEVICE_INTEGRITY, MEETS_BASIC_INTEGRITY`
`TRUE`	`TRUE`	`HARDWARE_BACKED`	`MEETS_STRONG_INTEGRITY, MEETS_DEVICE_INTEGRITY, MEETS_BASIC_INTEGRITY`

アプリが複雑な適用戦略を使用していて、すべての指定可能な値を必要とする場合は、デバイスの完全性レスポンスのセットを構成することが必要な場合があります。

Play Integrity API の再試行ロジック

特定のエラーコードが発生した場合、アプリは API 呼び出しを再試行する必要があります。すべてのエラーコードを確認し、アプリが必要に応じて指数バックオフで再試行するようにします。最小遅延を 5 秒以上とし、指数関数的に増加させて（5 秒、10 秒、20 秒、40 秒など）、デバイスとアプリの完全性を API が評価するのに十分な時間を確保してください。

App Licensing API の代替オプション

App Licensing API を使用している場合は、Play Integrity API トークンにアプリのライセンス情報が含まれているため、オプションとして Play Integrity API を使用するように移行できます。SafetyNet Attestation API の移行と同様、多数のデバイスにアプリの旧バージョンが残っている状況を想定する必要があります。信頼できるサーバーには、App Licensing API と Play Integrity API の両方のレスポンスを処理する能力が必要です。

完全終了までレスポンスを受け取る

移行期限（2024 年 1 月 31 日）までに Play Integrity API への移行または SafetyNet 証明書の削除が完了しない場合は、こちらのフォームに記入して延長をリクエストできます。延長が承認されたアプリには、サポート終了期限（2025 年 1 月 31 日）まで引き続き SafetyNet 証明書からレスポンスが届きます。

利用規約とデータセーフティ