我以编程方式获取的android设备UDID与同一设备的AirWatch Udid不同。 还有另一种获取设备Udid的方法吗?
我使用Secure.ANDROID_ID来获取出价,但与AirWatch所获得的UDID仍然不同。
Secure.getString(getContentResolver(), Secure.ANDROID_ID);
AirWatch UDID的长度如下:
ak26fs007bf8S786f2fr281d22c6996d
我希望得到相同的输出,但是我从上面的代码中得到的Udid是:
63a34441u6ajj2ed
答案 0 :(得分: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。
答案 1 :(得分:0)
我认为您是Android应用程序开发的新手。总是有一些与android中唯一设备标识符相关的混淆。 ANDROID_ID是在API级别3中引入的,返回的值有时会有所不同。
以前,Android OS提供了一些唯一的设备ID。但是,如果格式化了设备或安装了新的自定义操作系统,则会返回新值。稍后,在某些设备中返回null
值。 Oreo (Android 8.0)之后,其工作方式有所不同。
Google建议应用程序开发人员跟踪应用程序的安装而非设备,这将适合大多数用例。
对于跟踪应用程序的安装,您可以创建唯一的ID(例如UUID.randomUUId().toString()
),也可以自行解决。
有些链接可能会对您有所帮助。
https://developer.android.com/reference/android/provider/Settings.Secure.html#ANDROID_ID
写在best practices上的一些要点是:
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.