除了 IMEI、Android_ID、WLAN Mac 和蓝牙地址之外的设备的完美唯一 ID

Posted 2023-02-19

【中文标题】除了 IMEI、Android_ID、WLAN Mac 和蓝牙地址之外的设备的完美唯一 ID

【英文标题】：Perfect unique_id for device except IMEI,Android_ID,WLAN Mac and Bluetooth address

【发布时间】：2015-01-29 18:15:50

【问题描述】：

目标：

我正在寻找一种方法来找出适用于 android 设备的 unique_id。

背景：

我将在登录请求负载中使用 ID，因为我的应用是基于许可证的服务应用，因此 ID 在正常情况下不应更改。

现有方法：

在 ios 中有一些 unique id solutions for iOS，例如 CFUUID 或 identifierForVendor 加上 Keychain em>、Advertising Identifier 等。可以达到预期的效果。

但在 Android 中，我所知道的所有选项似乎都有漏洞。

IMEI：

TelephonyManager TelephonyMgr = (TelephonyManager)getSystemService(TELEPHONY_SERVICE); 
String m_deviceId = TelephonyMgr.getDeviceId();

缺点

它依赖于 sim 卡所以

如果没有 sim 卡，那我们就完蛋了

如果有双卡，那我们就完蛋了

Android_ID：

  String m_androidId = Secure.getString(getContentResolver(), Secure.ANDROID_ID);

缺点

如果操作系统版本升级，则可能会发生变化 如果设备已植根，则会更改 不保证 device_id 是唯一的，有报道称某些制造商的 device_id 重复

WLAN MAC 地址

WifiManager m_wm = (WifiManager)getSystemService(Context.WIFI_SERVICE); 
String m_wlanMacAdd = m_wm.getConnectionInfo().getMacAddress();

缺点

如果没有 wifi 硬件，我们就完蛋了 在某些新设备中，如果 wifi 关闭，我们就完蛋了。

蓝牙地址：

   BluetoothAdapter m_BluetoothAdapter = BluetoothAdapter.getDefaultAdapter(); 
   String m_bluetoothAdd = m_BluetoothAdapter.getAddress();

缺点：

如果没有蓝牙硬件，我们就完蛋了。 将来在某些新设备中，如果它关闭，我们可能无法读取它。

可能的解决方案：

我认为有两种方法可以解决这个问题

我们通过使用我提到的唯一 id 散列时间戳生成一个随机 id 并将其存储，以便下次登录时我们将检查存储的 key 值是否为空，如果是这样，那么我们将生成并存储它否则我们将使用键的值。

如果有类似 iOS 的 keychain 的东西，那么我们很适合这种方法。

找到一个类似于 iOS 的 advertisingIdentifier 的全局标识符，该标识符对于设备中的所有应用程序都是相同的。

感谢任何帮助！

【问题讨论】：

不错不错。我读了你的问题，点赞和收藏。您在 4 个多月前问过这个问题，但没有得到真正的回应。我不确定处理 iOS + Android 唯一 ID 的最佳方式。那就是把它带到一个新的水平。我现在会使用无缝的东西，比如使用 OAuth 的“使用 Google 登录”。这样它就可以在 iOS 和 Android 或 Web 设备上运行。

@JaredBurrows - OAuth 是否提供跟踪单个设备的功能？我为每个用户提供设备配额。即一个用户最多可以在三台设备上使用一个帐户

@DuraiAmuthan.H，我在下面阅读了您的评论。您说您的应用程序依赖于 wifi，并且您需要一个唯一的设备标识符。因此我认为mac地址是最好的选择。我现在几乎面临同样的问题，介于 AndroidUUID 和 MacAddress 之间。使用 AndroidUUID 后有什么要补充的吗？谢谢。

我使用的是Android_ID，因为它不依赖于任何硬件，而mac地址确实依赖于Wifi

【参考方案1】：

我选择使用 Android_ID 因为它不依赖于任何硬件。

Build.SERIAL 还取决于 wifi 专用设备 中 telephony 的可用性，此 Build.SERIAL 将不起作用。 p>

我已经解释了其他方法如何依赖于问题本身的硬件可用性。

【讨论】：

这个android-developers.googleblog.com/2011/03/… 解释了使用 Android_ID 的一些问题。具体来说，it is not 100% reliable on releases of Android prior to 2.2 (“Froyo”). Also, there has been at least one widely-observed bug in a popular handset from a major manufacturer, where every instance has the same ANDROID_ID.

@AviD 你确实意识到没有人再使用 Froyo，博客条目是从 2011 年（6 年前）开始的，他们所指的设备恰好是三星 Galaxy，对吧？你会很幸运能找到一个现在还在工作的，哈哈。

@mradzinski 哦，我们不希望是这样吗:-(。不幸的是，它仍然存在，而且有很多人不能也不会得到及时的更新，所以...¯_(ツ)_/¯

Ehmmm...我们的应用程序在超过 14 个国家/地区的下载量超过 1700 万次，我还没有在我们的数据库中找到重复或空的 ANDROID_ID...也许理论上它会发生，但是在实践中，我有足够的数据来证明过时的¯_(ツ)_/¯

@mradzinski - 感谢分享信息

【参考方案2】：

我认为，您可以使用设备序列号（硬件序列号，而不是 android id）。您可以在设备设置中看到它。在您的代码中，您可以通过 Build.SERIAL 获得它。

【讨论】：

一个赞成指出 Build.Serial。但没有电话的设备没有 Build.Serial。这对我来说是个问题，因为我的应用程序将用于 wifi only devices.Build。序列号可从 API 9 或 2.3 姜饼获得，但这对我来说不是问题，因为我的应用程序将针对 4.0 以上。

@Duraiamuthan.H 我认为所有设备都有“序列号”，但并非所有设备都有“IMEI”号。

@JaredBurrows - 我不确定所有设备在我阅读的某处都有Build.Serial 如果设备没有电话，那么该设备将没有build.serial例如考虑 wifi only 设备。你能确认一下吗。

@DuraiAmuthan.H 你想让我确认你读到的东西吗？您对 build.serial 的看法是正确的：developer.android.com/reference/android/os/Build.html#SERIAL。我已经用更多信息更新了我的帖子。我说你必须选择软件与硬件（最有可能是在设备之间跟踪用户的软件）。

【参考方案3】：

Android 上没有这样的 ID。您可以生成自己的，例如随机 UUID 并将其连接到用户的帐户。这就是 Kindle、Audible 和其他应用程序以非侵犯隐私的方式识别设备的方式。

如果您想“跟踪您的用户”，请考虑使用 Google Analytics Mobile，http://www.google.com/analytics/mobile/

如果您想更接近跟踪设备，可以将上述 ID 组合到哈希函数中。蓝牙 + wifi + android 串行，如果其中任何一个为空，则将 0 放入哈希中，例如如果没有 wifi mac 地址。正如您所指出的，您不能保证 id 不会改变。除非用户正在运行自定义 ROM，否则我希望这个计算的 ID 保持不变。

【讨论】：

Computed Ids 不适合我的应用程序。因为如果应用程序卸载并且 Id 消失了，那么我注定要失败。

@Duraiamuthan.H 散列方法是稳定的，并且在重新安装应用程序时将是相同的。它可能会在 ROM 重新安装/更改时发生变化！

如果应用程序被卸载，该值将如何保持。哈希值可能会根据 wifi/蓝牙状态和应用程序重新安装期间的可用性而改变。

@Duraiamuthan.H 没问题，hash函数每次执行的结果都是一样的，想象一下id = f(wifi_mac, bluetooth_mac, android_id)。对于相同的输入，id 将始终相同。您可以将此类用于散列 docs.oracle.com/javase/7/docs/api/java/security/…

你是对的，如果每次输入都相同，它会给出相同的哈希值但是输入可能会改变，例如，如果wifi在某些最新设备中关闭，wifi_mac返回null并且Bluetooth_mac也可能在即将发布的版本中遇到同样的问题，并且 android_id 并不是唯一的，毕竟有人抱怨这些是重复的