4

我以编程方式获得的 android 设备 UDID 与同一设备的 AirWatch Udid 不同。是否有另一种获取设备 Udid 的方法？

我使用 Secure.ANDROID_ID 来获取 udid，但它仍然与 AirWatch 获取的 UDID 不同。

Secure.getString(getContentResolver(), Secure.ANDROID_ID);

AirWatch UDID 的长度如下： ak26fs007bf8S786f2fr281d22c6996d

我期望相同的输出，但我从上面的代码中得到的 Udid 是： 63a34441u6ajj2ed

4

2 回答 2

1

air watch UDID 是通过对设备的多个方面进行哈希处理生成的，其中 Secure.ANDROID_ID 只是其中一个 - ro.serialno 可能是另一个，但重点是它们将它们放在一起，使用 128 位哈希，这就是你得到什么。

如果您绝对必须匹配他们的计算，那并不难——找到他们的 APK .dex ，他们在类方法中执行计算，然后通过反编译自己查看代码。

他们的代码自然是被混淆的，但你可以从

com.airwatch.core.AirWatchDevice.isDeviceUDIDInitialized()

从一个或两个位置调用，并且 - 如果它返回 false - 他们调用 UDID 方法（实际的完整方法名称在这里没有用，因为它被混淆了，沿着“dap0.d0.g0.c”的行每次构建，但 isDeviceUDIDInitialized() 仍然可见）。

另一种方法是寻找他们在哪里钓鱼 ro.serialno，

通过 java.lang.Class.getMethod("android.os.SystemProperties", "get", ..)

其中他们还寻找 android.os.Build.MANUFACTURER 和一堆其他属性。

此外，在某些版本中，formatDeviceUid 作为一种方法 - 直接应用 MD5。

于 2021-04-12T00:02:37.227 回答
-1

我认为您是 Android 应用程序开发的新手。在 android 中总是存在一些与唯一设备标识符相关的混淆。ANDROID_ID是在 API 级别 3 中引入的，返回的值有时会有所不同。

以前 Android 操作系统提供了一些唯一的设备 ID。但如果设备已格式化或安装了新的自定义操作系统，则会返回新值。稍后，null在某些设备中返回值。在Oreo (Android 8.0)之后，它的工作方式有所不同。

谷歌建议应用程序开发人员跟踪应用程序安装而不是设备，这将适合大多数用例。

对于跟踪应用程序安装，您可以创建一个唯一的 ID，UUID.randomUUId().toString()也可以制作自己的解决方法。

以下是一些可能对您有所帮助的链接。

  1. 是否有唯一的 Android 设备 ID？

  2. https://developer.android.com/reference/android/provider/Settings.Secure.html#ANDROID_ID

  3. https://developer.android.com/training/articles/user-data-ids.html
  4. https://developer.android.com/reference/java/util/UUID.html#randomUUID()

关于最佳实践的一些要点是：

When working with Android identifiers, follow these best practices:

#1: Avoid using hardware identifiers. In most use cases, you can avoid using hardware identifiers, such as SSAID (Android ID) and IMEI, without limiting required functionality.

#2: Only use an Advertising ID for user profiling or ads use cases. When using an Advertising ID, always respect users' selections regarding ad tracking. Also, ensure that the identifier cannot be connected to personally identifiable information (PII), and avoid bridging Advertising ID resets.

#3: Use an Instance ID or a privately stored GUID whenever possible for all other use cases, except for payment fraud prevention and telephony. For the vast majority of non-ads use cases, an Instance ID or GUID should be sufficient.

#4: Use APIs that are appropriate for your use case to minimize privacy risk. Use the DRM API for high-value content protection and the SafetyNet APIs for abuse protection. The SafetyNet APIs are the easiest way to determine whether a device is genuine without incurring privacy risk.
于 2019-06-30T16:56:01.143 回答