Android Device Udid vs AirWatch Udid

user_6809271 0
Viewed 1185

The android device UDID I get programmatically is different from AirWatch Udid of the same device. Is there another method to get the device Udid?

I used the Secure.ANDROID_ID to get the udid, but it is still different from the UDID that AirWatch get.

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

AirWatch UDID is in the following length: ak26fs007bf8S786f2fr281d22c6996d

I expect the same output but The Udid I get from the code above is: 63a34441u6ajj2ed

airwatch vmware android java
2 Answers

The air watch UDID is generated by hashing together multiple aspects of the device, of which Secure.ANDROID_ID is just one - ro.serialno is likely another, but the main point is they take those together, use a 128-bit hash, and that's what you get.

If you absolutely must match their computation, it's not that hard - locate their APK .dex , wherein they perform the calculation in a class method, and just see the code for yourself by decompiling it.

Their code is naturally obfuscated, but you can start with

com.airwatch.core.AirWatchDevice.isDeviceUDIDInitialized()

which is called from one or two locations, and - if it returns false - they call the UDID method (the actual full method name is useless here as it obfuscated, along the lines of "d.a.p0.d0.g0.c" which changes in every build, but isDeviceUDIDInitialized() is still visible).

Another approach is too look for where they fish out ro.serialno,

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

wherein they also look for android.os.Build.MANUFACTURER and a bunch of other attributes.

Also, there's formatDeviceUid as a method somewhere in some builds - that applies the MD5 directly.

user_17344390

I think you are new to Android Application Development. There is always some kind of confusions related to Unique Device Identifier in android. The ANDROID_ID was introduced in API level 3 and the value returned is differing from time to time.

Previously Android OS had provided some unique device id. But new value is returned if the device is formatted or new custom OS is installed. Later on, null value is returned in some devices. After Oreo (Android 8.0) it works differently.

Google suggests app developers to track app installs rather than devices, and that will suit most use cases.

For tracking app installation, you can either create a unique id like UUID.randomUUId().toString() or can make your own workaround.

Here are some links that might help you.

  1. Is there a unique Android device 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()

Some points written on best practices are:

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.
user_37103410
Related