Android ID

Android exposes the value through Settings.Secure.ANDROID_ID, and it reads as sixteen lowercase hex characters such as 38400000-8cf0-11bd-b23e-10b96e40000d in its dashed form or c1a2b3d4e5f60718 as a bare string. Before Android 8 it was a single value every installed app could read, which made it a convenient global device identifier — and a privacy problem, since two unrelated apps could compare notes and confirm they were on the same handset.

What scoping changed in Android 8

From API level 26, the value is derived per combination of app signing key, user and device. Two apps from different developers see two different IDs on the same phone. Two apps signed with the same key see the same ID, which is how a developer keeps continuity across their own portfolio. The mapping lives on-device in /data/system/users/0/settings_ssaid.xml, keyed by package and signature.

• Uninstall and reinstall preserves the value, as long as the signing key has not changed — so it survives the obvious reset attempt.
• Rotating the app’s signing key produces a new value, which is why key rotation is a breaking event for any app using it as an identifier.
• A separate Android user or work profile gets a separate value, since the user is part of the derivation.
• A factory reset regenerates everything, which is why a reset genuinely reads as a new device.
• Apps installed before the device upgraded to Android 8 kept their pre-upgrade value until uninstalled — a long tail that has mostly aged out but still explains odd historical data.

The 9774d56d682e549c problem

A well-known batch of low-cost devices shipped with a firmware bug that made every unit report the identical Android ID, 9774d56d682e549c. It is the canonical illustration of why no serious system trusts this value alone, and it is worth knowing because a provider whose devices all report one value is reproducing that bug deliberately. If you see the same sixteen characters on two phones, they are the same image, not two devices.

Android ID versus advertising ID

These are constantly confused. The Google Advertising ID (GAID, or AAID) is a UUID intended for ad attribution, resettable by the user at any time from Settings, and since Android 12 it is zeroed entirely — returning 00000000-0000-0000-0000-000000000000 — when the user opts out. Play policy forbids linking it to any persistent identifier. The Android ID is the opposite: not user-resettable short of a factory reset, and not intended for advertising. An app that wants durable recognition uses the Android ID; an app that wants to respect the ad opt-out uses the GAID.

Reading it, and the trap in reading it

The obvious command is adb shell settings get secure android_id. It works, but it returns the value scoped to the shell UID — not what any given app sees, since scoping is per signing key. So the command is perfect for the one thing that matters most in a fleet, comparing devices against each other, and useless for predicting the value a specific app will observe.

• adb shell settings get secure android_id — run across every device and diff the results.
• adb shell cat /data/system/users/0/settings_ssaid.xml — requires root, shows the per-package mapping directly.
• Reboot and re-read — the value must not change. If it does, something is regenerating identity per boot.

Why it still matters for a fleet

Scoped or not, the Android ID must be distinct per device and stable per session. If a provider clones device images without regenerating it, every phone in the batch shares one value from the app’s point of view — the exact correlation that separate devices are meant to prevent, and one that no proxy configuration can undo. It costs two minutes to check, and it is one of the values worth verifying before committing to any cloud phone provider.

The reverse failure is subtler. A stack that resets the Android ID between sessions in the name of hygiene makes every login look like it comes from a phone the account has never seen before, which is precisely the signal that triggers a verification challenge. Stability is the feature.