4

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

Gustavo Pagani
  • 6,583
  • 5
  • 40
  • 71
Yaaqoub
  • 75
  • 1
  • 5
  • Maybe this will help clarify the question. AirWatch populates a "UDID" attribute for all devices, iOS and Android, even though there is nothing called "UDID" in Android. For iOS devices, it is obviously the actual UDID of the phone. For Android devices, it contains a 32-character hex value. Op is attempting to determine what this corresponds to on an Android device. It does not appear to match ANDROID_ID or serial. It might be some special format of IMEI/MEID? This is really an AirWatch question. – mtjhax Sep 22 '20 at 17:43
  • Same problem. Need a system ID that match with AirWatch Device ID. AirWatch currently using ro.serialno but I don't know how they are accessing this. – Shohan Ahmed Sijan Feb 04 '21 at 11:35

2 Answers2

1

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.

Technologeeks
  • 7,674
  • 25
  • 36
  • Thanks! is there any way so that I can get the same for my device ? – R15 Apr 12 '21 at 05:51
  • Yes. Taking their implementation, decompiling it, and embedding it in your own app will produce the same ID. Just make sure that you have the same permissions as them, if necessary. Another (albeit more complicated) option to pinpoint the exact method they use to compute the U[D]ID is to make their manifest android:debuggable, and resign, the walk through, or eve dump the memory until you find the UDID, and work from there. – Technologeeks Apr 12 '21 at 11:54
-1

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.
Sagar Chapagain
  • 1,683
  • 2
  • 16
  • 26
  • Thank you for the information, I understand what you mean, but in AirWatch they use UDID to identify the device, that's the ID I want to get to verify if the device exists in the AirWatch DB. – Yaaqoub Jun 30 '19 at 18:47
  • I am not clear on what you are trying to do. How Airwatch and Android is related here? What are you trying to do? – Sagar Chapagain Jul 01 '19 at 00:59