Evolution and Best Practices for Obtaining Unique Device Identifiers in Android

Background of Device Identifier Requirements

In Android application development, obtaining unique device identifiers is a common requirement, particularly in scenarios such as user tracking, data analysis, advertising delivery, and security verification. However, with the continuous evolution of the Android system and increasing awareness of user privacy protection, obtaining stable and privacy-compliant device identifiers has become increasingly challenging.

Analysis of Traditional Identifier Methods

In early versions of Android, developers primarily relied on two methods to obtain device identifiers: ANDROID_ID and IMEI.

Usage and Limitations of ANDROID_ID

ANDROID_ID was once the recommended method for obtaining unique device identifiers, with implementation code as follows:

import android.provider.Settings.Secure;

private String android_id = Secure.getString(getContext().getContentResolver(), Secure.ANDROID_ID);

This method generates a 64-bit identifier created and stored when the device first boots, but it is reset when the device undergoes a factory reset. Although ANDROID_ID has good reliability after Android 2.2 ("Froyo"), it was unstable in earlier versions, and bugs were observed in some manufacturer devices where all instances had the same ANDROID_ID.

Acquisition and Restrictions of IMEI Identifiers

IMEI (International Mobile Equipment Identity) is another traditional method for obtaining device identifiers:

TelephonyManager telephonyManager = (TelephonyManager)getSystemService(Context.TELEPHONY_SERVICE);
String deviceId = telephonyManager.getDeviceId();

Using IMEI requires adding permission declaration in AndroidManifest.xml:

<uses-permission android:name="android.permission.READ_PHONE_STATE"/>

However, IMEI identifiers pose significant privacy risks because they remain unchanged after factory resets, potentially leading to data association errors when user devices change hands. More importantly, starting from Android 10 (API level 29), access to non-resettable identifiers (including IMEI and serial number) has been strictly restricted.

Modern Identifier Best Practices

With the strengthening of user privacy protection in the Android system, Google recommends that developers adopt more privacy-friendly identifier solutions.

Firebase Installation ID (FID)

Firebase Installation ID is currently the recommended solution for most non-advertising use cases. FID has application instance-level scope, can only be accessed by the application instance for which it was provisioned, and is relatively easy to reset when the application is uninstalled. These characteristics give FID better privacy properties compared to non-resettable, device-scoped hardware IDs.

Globally Unique Identifier (GUID)

In cases where FID is not suitable, developers can use custom globally unique identifiers:

// Java implementation
String uniqueID = UUID.randomUUID().toString();

// Kotlin implementation
val uniqueID = UUID.randomUUID().toString()

Since this identifier is globally unique, it can be used to identify specific application instances. To avoid concerns related to linking identifiers across applications, GUIDs should be stored in internal storage rather than external (shared) storage.

Usage Specifications for Advertising ID

For advertising-related use cases, Android requires the use of Advertising ID, which is a user-resettable identifier suitable for advertising purposes. When using Advertising ID, the following key principles must be followed:

• Always respect the user's intention in resetting the advertising ID, and do not use another identifier or fingerprint to link subsequent Advertising IDs together without the user's explicit consent
• Always respect the associated Personalized Ads flag, using the AdvertisingIdClient.Info.isLimitAdTrackingEnabled() method to ensure that you are not circumventing your users' wishes
• The Advertising ID must not be connected to personally-identifiable information or associated with any persistent device identifier

Identifier Characteristics Comparison

Understanding the characteristics of different identifiers is crucial for selecting the appropriate solution:

Scope Characteristics

The scope of an identifier determines which systems can access it:

• Single app: The identifier is internal to the app and not accessible to other apps
• Group of apps: The identifier is accessible to a pre-defined group of related apps
• Device: The identifier is accessible to all apps installed on the device

The wider the scope granted to an identifier, the greater the risk of it being used for tracking purposes.

Resettability and Persistence

Resettability and persistence define the identifier's lifecycle and how it can be reset:

• Session-only: A new ID is used every time the user restarts the app
• Install-reset: A new ID is used every time the user uninstalls and reinstalls the app
• FDR-reset: A new ID is used every time the user factory-resets the device
• FDR-persistent: The ID survives factory reset

Uniqueness Considerations

Uniqueness establishes the likelihood of collisions, meaning the probability that identical identifiers exist within the associated scope. A globally unique identifier never has a collision, even on other devices or apps. Identifiers with lower uniqueness levels provide greater privacy protection in populations because they are less useful for tracking individual users.

Use Cases and Identifier Selection Guide

Select appropriate identifiers based on specific usage scenarios:

Advertising-Related Use Cases

For advertising targeting, measurement, conversion tracking, and remarketing, the Advertising ID must be used. This is required by the Google Play Developer Content Policy because users can reset this ID.

Application Analytics Use Cases

For application analytics, crash reporting, and performance monitoring, Firebase Installation ID or App Set ID are recommended. These identifiers have application scope, preventing them from being used to track users across applications.

Security-Related Use Cases

For abuse detection and ad fraud protection, it is recommended to use the Google Play Integrity API integrity token to verify that requests come from genuine Android devices.

User Preference Settings

For saving per-device user states, especially when users are not signed in, FID or GUID are recommended. Persisting information through reinstalls is not recommended because users may want to reset their preferences by reinstalling the application.

Privacy Protection Best Practices

To protect user privacy, the following best practices should be followed:

• Choose user-resettable identifiers whenever possible; most use cases can be achieved even without using non-resettable hardware IDs
• Avoid using hardware identifiers; in most use cases, you can avoid using hardware identifiers like IMEI without limiting required functionality
• Only use Advertising ID for user profiling or advertising use cases; when using Advertising ID, always respect users' selections regarding ad tracking
• Use Firebase Installation ID or privately stored GUID whenever possible for all other use cases, except for payment fraud prevention and telephony
• Use APIs that are appropriate for your use case to minimize privacy risk; use the DRM API for high-value content protection and the Play Integrity APIs for abuse protection

Technical Evolution Trends

The Android system continues to evolve in identifier management, mainly reflected in:

• Transition from device-level identifiers to application-level identifiers
• Development from non-resettable identifiers to user-controllable identifiers
• Privacy protection becoming a core consideration in identifier design
• System-level APIs providing more secure alternatives

Conclusion

The methods for obtaining Android device identifiers have evolved from simple hardware identifiers to complex privacy protection solutions. Modern Android development should prioritize the use of user-resettable identifiers such as Firebase Installation ID, App Set ID, and Advertising ID, while avoiding hardware identifiers like IMEI. Developers need to select the most appropriate identifiers based on specific use cases while strictly adhering to privacy protection best practices, ensuring that functional requirements are met while fully protecting user privacy.