是否可以使用 Google Cloud Messaging 的实例 ID（现已弃用）进行应用跟踪？答案

【问题标题】：Is it okay to use Google Cloud Messaging's Instance ID (now deprecated) for app tracking purposes?是否可以使用 Google Cloud Messaging 的实例 ID（现已弃用）进行应用跟踪？
【发布时间】：2019-12-06 03:06:21
【问题描述】：

我目前在我的应用中使用 android 的设备 ID (ANDROID_ID) 作为我自己的分析 API 的唯一标识符。最近听说谷歌在Android 10（Q）下，Android在使用唯一标识符方面会有更严格的限制，如https://developer.android.com/training/articles/user-data-ids中所述

Android 10（API 级别 29）增加了对不可重置标识符的限制，其中包括 IMEI 和序列号。您的应用必须是设备或配置文件所有者应用，具有特殊的运营商权限，或拥有 READ_PRIVILEGED_PHONE_STATE 特权权限才能访问这些标识符。

所以我继续使用 Google Cloud Messaging 的实例 ID 作为替代（具有 GCM 依赖项）。但我又一次看到该库已被弃用，所以我想到 GCM API 可能会在不久的将来停止使用。

仍然可以使用 GCM 的实例 ID 吗？请注意，我只想将其用于获取设备的唯一 ID。

如果对我可以使用的另一个唯一 ID 有任何建议，以下是我的注释：

尽可能减少或不依赖项
如果唯一 ID 在应用卸载/设备恢复出厂设置时刷新，则可以，只要它在刷新时全局唯一即可
不会妨碍或打扰设备安全
如果可能容易设置，如果没有，必须是可重复使用的代码
极小（十亿分之一的机会）或没有复制的机会
我知道 Java 的 UUID，但我仍在研究它的可行性

非常感谢您！

编辑（截至 2020 年 2 月 11 日）

由于生成唯一 ID 是一个非常棘手的问题，我求助于使用 Google 自己的 Firebase API。他们负责处理唯一 ID（前提是您的设备有 Google Play。

对于那些想要每个设备独立的唯一 ID 的人，只需坚持 API 处理/抛出唯一 ID。

【问题讨论】：

标签： android google-cloud-messaging uniqueidentifier

【解决方案1】：

使用加密 RNG（例如 java.security.SecureRandom）生成一个随机的 128 位或更长的 ID 足以满足您的目的。

即使对于 122 位 ID（包括在随机 UUID 中发现的 ID），只有在生成大约 27 亿个值后，碰撞的预期几率才为 50%（请参阅“Birthday problem”）。

另请参阅 Android 开发者网站中的“Best practices for unique identifiers”和我的部分“Unique Random Identifiers”。

【讨论】：

好的，我去看看，谢谢。我会在阅读完您的部分后立即更新您，现在我想专注于几乎

【解决方案2】：

由于生成唯一 ID 是一个非常棘手的问题，我求助于使用 Google 自己的 Firebase API。他们负责处理唯一 ID（前提是您的设备有 Google Play。

对于那些想要每个设备独立的唯一 ID 的人，只需坚持 API 处理/抛出唯一 ID。

【讨论】：