When working with Devices, a common request is how to identify the device when you don’t know what platform, operating system, or even who the vendor is. Even when you do, differences in OS releases, amongst other things can lead to different results. If you need to track devices, here is a summary of various choices, and a recommendation on how to address the problem.
First, both Apple and Google have made statements about protecting the privacy of the users of their platforms, and consequently have actively removed access to device identifiers for 3rd party developers. For example, Apple prevents access to the IMEI number, UDID Unique Device Identifier (Starting with iOS 5.0) and the MAC address of the Wi-Fi and Bluetooth radios (iOS 7.0). Google has done similar things, though not quite to the same degree given the openness of their platform.
Here are several common identifiers you might use to track your device, and some comments on why they may not be useful as a developer.
iOS
UDID Unique Device Identifier will uniquely identify an iOS device. It is no longer accessible through the iOS APIs. UUID Universally Unique Identifier is a per app identifier. If the app is not deleted, the UUID will remain the same. If reinstalled, it will be a different value. Apple gives Managed App configurations special access to device identifiers, i.e. this is why a UEM server knows what your apple UDID is when your device is under management: https://developer.apple.com/library/content/samplecode/sc2279/Introduction/Intro.html
Android
Android ID is set at first boot, and lasts if the device is not factory reset. Google Service Framework (GSF), like above, lasting if the device is not factory reset. Device ID (Build.serial) is the serial number of the device, and will stay the same, not affected by a factory reset. Knox devices have an additional ID. Device ID would seem to be the ideal choice for tracking an Android device however, Android is used by many manufacturers, and not all set a hardware ID. Android mentions this in its documentation, saying “A hardware serial number, if available.” A software based id is guaranteed to be there.
On the upcoming Android O, there are additional changes. Both Android_ID and device serial number behaviour is changing – https://developer.android.com/preview/behavior-changes.html to make them unique to certain app scope (in case of Android_ID) and require a new API which requires user permission (in the case of Build.serial)
Other identifiers:
SIM
Subscriber identity module – stores the IMSI (international mobile subscriber identity) number on a SIM card. Not all Android and iOS devices use a SIM (i.e. tablets usually do not have a SIM card). And you can swap SIM cards.
IMEI & MEID
IMEI is a unique serial number given to almost all mobile 3GPP phones (i.e. GSM, LTE, UMTS). Not accessible with an API on iOS. MEID or Mobile equipment identifier is a unique serial number given to all CDMA2000 equipment. Like IMEI, it’s not accessible with an API on iOS. Both values can be found manually on iOS and Android devices. Asking a User to type them in to your app to identify the device is tedious, and not reliable compared to a programmatic approach
MAC address
Media access number is a unique identifier assigned to network interfaces. Usually found as part of the Wi-Fi radio or Bluetooth radio on mobile devices. Apple already hides this as mentioned earlier, Google does similar with recent (since 5.0) Android builds, though not all android devices are rigorous hiding it.
MDM (Mobile Device Management) activated device
When a device is MDM activated, some hidden attributes by various vendors are now accessible. For example, with iOS devices, the UDID is recorded on UEM. If your device is not under MDM control, you won’t have access.
Recommendation
The previous choices are not recommended based on their various risks, availability, and consistency… however, we do recommend a choice guaranteed to be there by BlackBerry.
BlackBerry Dynamics and BlackBerry UEM have been designed specifically with a unique device identifier independent of the vendor’s hardware, OS or release version.
All devices under UEM control will have a unique value assigned by the server. There are 2 use cases, 1) just the applications on your device are managed by UEM, the device itself is not and 2) the applications AND the device is managed by the UEM.
1) For devices, NOT under MDM, each BlackBerry Dynamics app activated on the device will have a unique GD container ID.
a) BlackBerry Dynamics (BD) provides the GDUtility API. Inside your BD SDK enabled app, call GDUtility to get a GD AuthToken
b) BD app sends GD AuthToken to the App Server (your app sends it to your app server)
c) App Server validates the GD AuthToken by calling the GD Auth API for App Server. As part of the validation response it receives the GD Container ID:
i) X-Good-GD-ContainerID: container_id
The GD Container ID should then be used to identify the app in any WebServices calls to the GC/UEM, for example if the App Server wanted to issue a Generic action to Block/Wipe the App.
2) For devices under MDM by UEM, each device will have a Globally Unique ID (GUID) for its container. Its available thru BlackBerry Web Services (BWS), accessed by using the BWS SOAP call getUsers(). Look for <ns2:uid> under <ns2:devices>. See this blog on Making Web Service Calls to BES12 for more info (BWS still works the same for UEM). You can also view this item through the UEM Admin console, doing the following:
- Login to UEM Admin Console and go to Users, Change from “default” to “Advanced” view.
- Click the + sign and then check GUID.
Note: the GD container ID and the BWS GUID are NOT the same value. One refers to an application, one refers to a MDM managed device container.
In both these cases the GD AuthToken/GD container ID and the BWS GUID are guaranteed to be there if the device is under UEM control. If you delete and reinstall the app, or the MDM container, the GD container ID/BWS GUID will be reset.
Handy link to access the GD auth token programmatically:
