8

私のアプリは常に DeviceId を一意の識別子として使用しており、これにはもちろん、アクセス許可として READ_PHONE_STATE が必要です。以前は問題ありませんでしたが、現在は Marshmellow 23 に移行しました。この許可を求めると、実行時に非常に恐ろしいダイアログが表示されます...

「{my app} に通話の発信と管理を許可しますか?」

deviceId を取得したいだけのアプリにとって、これは非常に恐ろしいメッセージです。

許可が不要なAndroid IDに切り替えようと思っています。

String androidId = Settings.Secure.getString(getContentResolver(), Settings.Secure.ANDROID_ID);

グーグルで調べてみると、Android ID の使用にいくつか問題があることがわかりましたが、それはすべて古いものです。Froyo の時代には、すべての電話に同じ ID を作成する電話ベンダーがありましたが、私が見たのはこれだけです。

Android ID の使用に問題があることを知っている人はいますか? ありがとう、ディーン

4

1 に答える 1

4

どの一意の識別子を使用するかは、その識別子が必要な特定のユース ケースによって大きく異なります。一意の識別子のトレーニングのベスト プラクティスでは、多くの一般的なユース ケースと使用する識別子について説明します。彼らには、Android 識別子を使用する多くのテナントがあります。

1:ハードウェア識別子の使用を避けます。 SSAID (Android ID) や IMEI などのハードウェア識別子は、必要な機能を制限することなく、ほとんどのユースケースで回避できます。

2:広告 ID は、ユーザー プロファイリングまたは広告のユースケースにのみ使用してください。広告 ID を使用する場合は、広告追跡の制限フラグを常に尊重し、識別子が個人を特定できる情報 (PII) に関連付けられないようにし、広告 ID のリセットをブリッジしないようにします。

3:支払い詐欺の防止とテレフォニーを除く他のすべてのユースケースでは、可能な限りインスタンス ID またはプライベートに保存された GUID を使用します。広告以外のユースケースの大部分では、インスタンス ID または GUID で十分です。

4:ユースケースに適した API を使用して、プライバシー リスクを最小限に抑えます。高価値のコンテンツ保護には DRM API API を使用し、悪用防止には SafetyNet API を使用します。Safetynet API は、プライバシー リスクを負うことなく、デバイスが本物かどうかを判断する最も簡単な方法です。

ほとんどの場合、Android ID はまだ適切に使用できません。

于 2016-08-20T23:35:47.290 に答える