From IMEI to MediaDrm: The Evolution and Breakdown of Android Device Identity

The concept of a “device ID” on Android is not a single, static value. It’s a cat-and-mouse game between app developers, who want a stable and unique way to identify a user’s device for analytics, fraud prevention, and tracking, and Google (and privacy-conscious users), who want to limit persistent tracking to protect user privacy.

This ongoing tension has led to a sequence of evolving identifiers, each with its own benefits, flaws, and methods of circumvention.

Oct 20, 2025 • 5 min read

Phase 1: The IMEI

In the early days of Android (pre-Android 10), it was very simple for developers to get the most reliable, persistent, and unique identifier. The IMEI (International Mobile Equipment Identity) number.

What it is: A 15-digit number that is globally unique to a specific mobile phone’s hardware. It’s implemented into the device’s modem and is the primary identifier for a phone on a cellular network.
How it was used: Apps with the READ_PHONE_STATE permission could just get this number. Because it’s tied to the physical hardware, it would never change, even if the user factory reset the phone, changed their Google account, or uninstalled the app.
Why it died: This was a huge privacy issue. An app developer could build a permanent, non-resettable profile of a user. In 2019, with the release of Android 10, Google cracked down hard. Access to non-resettable hardware identifiers, including IMEI, was heavily restricted. Apps can no longer access it, and trying to do so will return null or throw an error. This forced the entire industry to find alternatives.

Phase 2: The “Official” Identifier (Android ID)

With IMEI restricted, the Android ID became the next candidate for identifying devices. (also known as Settings.Secure.ANDROID_ID or SSAID).

What it is: A 64-bit number (represented as a 16-character hex string) that is generated on the device’s first boot.
How it was used: This became the new standard. It was unique enough and, for a while, was persistent. An app could query this ID to identify the device.
How it was broken (by Google): Google intentionally weakened this ID for privacy:
Resets on Factory Reset: Unlike IMEI, the Android ID is wiped and a new one is generated after a factory reset. This gave users a “destroy” option to reset their device footprint.
App-Specific Scoping: Starting with Android 8.0 (Oreo), Google made the Android ID’s value different for each app. An app signed by developer “A” will see a different Android ID than an app signed by developer “B,” even on the same device. This made it useless for cross-app tracking and device identification.

Phase 3: The Current “Advanced” IDs (GSF & MediaDrm)

As the Android ID lost its persistence, developers working in high-integrity domains like fraud prevention, finance, and DRM turned to less-documented identifiers for stability and uniqueness.

1. GSF (Google Services Framework) ID

What it is: A 16-character hexadecimal value generated by Google Play Services the first time a user logs into a Google Account on a device. It’s not a hardware ID but a service-level ID that links a specific Google account to a specific device instance.
How it’s used: It’s a primary way Google’s own apps (like the Play Store) identify your device to deliver the correct services. Fraud-prevention apps began using it as a highly stable identifier, as most users don’t change the primary Google account on their phone.
How it can be changed:
Without Root: A user can navigate to Settings → Apps → Google Services Framework → Clear Data. On the next check-in, Google generates a new GSF ID.
With Root: LSPosed modules such as AndroidFaker or XPrivacyLua can intercept system calls to the GSF content provider (com.google.android.gsf.gservices) and feed fake values to applications.

2. MediaDrm ID

The MediaDrm API was originally built for secure digital rights management, not device identity. Yet, it quickly became one of the most persistent identifiers in use.

What it is: During device provisioning, the MediaDrm API assigns a cryptographic key that produces a property called PROPERTY_DEVICE_UNIQUE_ID. Apps like Netflix and Disney+ rely on this process to enforce DRM policies.
How it was used: Some apps, such as Snapchat, leveraged this ID to enforce device bans or detect rooted devices. Even after a factory reset or new account setup, the same MediaDrm ID could still be read, giving it the properties of a near-permanent identifier.

The Bigger Issue with MediaDrm ID

The fundamental problem with MediaDrm ID is not only its privacy implications but also its unreliability as a true unique identifier. Research shows that a measurable percentage of MediaDrm IDs collide across devices, especially within models from the same manufacturer. Approximately 2.5% of IDs are shared, meaning two users could unknowingly possess the same identifier.

For security systems, this is a serious flaw. A legitimate user might purchase a new phone, attempt to log into a banking or gaming app, and be automatically flagged or banned because another device with the same MediaDrm ID had been blacklisted.

This dual failure of privacy exposure and technical unreliability makes MediaDrm an identifier that satisfies neither developers nor users.

Industry Benchmark: Current Use of Device Identifiers

To understand how these identifiers are still used in practice, we analysed over 100 Android applications across multiple domains in India, including fintech, gaming, e-commerce, travel, and OTT.

Nearly 49% of the apps belonged to the fintech and banking segment, followed by e-commerce (18%) and gaming (11%), as shown in Figure 1.

Figure 1: Distribution of Apps Analysed across industries ( India)

Across these applications, more than half (51%) had no structured device identity framework, while 39% relied on internal implementations and 10% integrated third-party solutions for device identification (Figure 2).

Figure 2: Split of Solutions across all the apps (Android)

This analysis highlights a key insight: even in regulated or security-sensitive industries, many production Android apps continue to rely on basic identifiers like Android ID, GSF ID, or MediaDrm ID for risk, trust, or analytics workflows. Despite privacy restrictions and spoofing vulnerabilities, these identifiers remain deeply embedded in SDKs and back-end systems.

Summary of the methods used by common LSPosed modules to override Android device identifiers.

This is where the user’s control comes back. LSPosed is a framework (a successor to Xposed) that allows modules to “hook” into the Android system and apps. These modules are small apps that change the behavior of other apps in memory without touching their original code.

Summary

Android’s approach to device identity has evolved from static hardware identifiers to scoped and ephemeral values that favor user privacy. Each new phase has reduced the potential for persistent tracking but increased complexity for legitimate use cases that rely on stable device recognition.

For developers and security teams, the outcome is clear: traditional identifiers like IMEI, Android ID, GSF, and MediaDrm can no longer be trusted as consistent signals of device identity.

Loading blog...

Persistent device intelligence for Real-time risk decisions.

Product

Resources

Company