我通过程序获得的安卓设备UDID与AirWatch获取到的相同设备的UDID不同。是否有其他方法可以获取设备UDID呢？
我使用了Secure.ANDROID_ID来获取UDID，但它仍然与AirWatch获取到的UDID不同。
Secure.getString(getContentResolver(), Secure.ANDROID_ID);
AirWatch UDID的长度如下:
ak26fs007bf8S786f2fr281d22c6996d
我期望得到相同的输出，但是我从上面的代码中获得的UDID是:
63a34441u6ajj2ed
空气手表的UDID是通过对设备的多个方面进行哈希生成的，其中Secure.ANDROID_ID只是其中之一-ro.serialno可能是另一个方面，但主要的一点是将它们结合在一起，使用128位哈希，这就是你得到的结果。
如果您绝对必须匹配他们的计算，那么并不难-找到他们的APK .dex，在其中他们在类方法中执行计算，然后通过反编译查看代码。
他们的代码自然是混淆的，但您可以从以下内容开始
com.airwatch.core.AirWatchDevice.isDeviceUDIDInitialized()
这个函数从一个或两个位置调用，如果返回false，它们会调用UDID方法（实际完整的方法名被混淆了，类似于“ d.a.p0.d0.g0.c”，每次构建都会更改，但isDeviceUDIDInitialized（）仍然可见）。
另一种方法是查找他们获取ro.serialno的位置，
通过java.lang.Class.getMethod("android.os.SystemProperties","get",..)
在其中他们还寻找android.os.Build.MANUFACTURER和一堆其他属性。
此外，在某些版本中的某个地方有一个名为formatDeviceUid的方法-它直接应用MD5。
我认为你是新手Android应用程序开发者。在Android中，与唯一设备标识符有关的某些困惑总是存在。ANDROID_ID是在API级别3中引入的，返回的值会随时间而异。
以前，Android操作系统提供了一些唯一的设备ID。但是，如果设备被格式化或安装了新的自定义操作系统，则返回新值。后来，在某些设备上返回null值。在Oreo（Android 8.0）之后，它的工作方式有所不同。
谷歌建议应用程序开发人员跟踪应用程序安装而不是设备，这将适用于大多数用例。
要跟踪应用程序安装，您可以创建一个类似于UUID.randomUUId().toString()的唯一ID，或者可以制定自己的解决方案。
以下是一些可能对您有帮助的链接。
https://developer.android.com/reference/android/provider/Settings.Secure.html#ANDROID_ID
最佳实践中提到的一些要点是：
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.