Tracking Hardware Id

Context

Implementation

Affects

Security,User Conformity,User Experience

Problem

For some use cases it might be necessary to get a unique, reliable, unique device identifier.

This could be achieved by reading the IMEI, MEID, or ESN of the phone by calling TelephonyManager.getDeviceId(). But this needs the permission READ_PHONE_STATE.
Besides the fact that another supsicious permission that can track the user-phone combination, it is not stable nor reliable.

Unique
“Usually unique” See IMEI on Wikipedia
Reliable
On phones it is ok, but lacks on WiFi-only or music players devices
Stable
According to Identifying App Installations some devices return garbage.

Refactorings

Use unique generated Id

Resolves

Security,User Conformity

Affects

Solution

The goal of the problem is to identify one concrete installation instead of a concrete hardware.

Settings.Secure.ANDROID_ID is a 64-bit hex string that is generated when the device is booted the first time. It is set when the device is wiped.

The downside of this is is the fact that it is not 1005 reliable in Android Versions before Froyo (2.2). In Identifying App Installations it is said there is at least one known manufacturer bug that returns the same id on every device.

To target also older versions a legacy fallback method could be implemented that generates and stores a unique id at the first run of the app, eg. with the help of:

UUID.randomUUID().toString();

Links

Related