IMEI

Every device with a cellular radio ships with an IMEI burned into it. Because it belongs to the hardware and not the subscriber, swapping SIM cards does not change it, and a dual-SIM handset carries two — one per radio. It is not a random number: every one of the fifteen digits is constrained, which is what makes a malformed IMEI easy to spot.

The structure of the fifteen digits

• Digits 1-8, the Type Allocation Code (TAC) — allocated by the GSMA to a specific manufacturer and model. The first two digits are the Reporting Body Identifier of the body that issued it: 35 for BABT in the UK, 01 for PTCRB in the US, 86 for the Chinese body, 49 and 44 for others.
• Digits 9-14, the serial — assigned by the manufacturer within its own TAC block.
• Digit 15, the check digit — computed over the first fourteen with the Luhn algorithm.

A related format, the IMEISV, is sixteen digits: the same eight-digit TAC, the same six-digit serial, then two digits of software version instead of a check digit. Networks use it to know which firmware a handset is running.

Computing the check digit

Take the fourteen digits and double every second one starting from the second. If a doubled value exceeds nine, add its two digits together. Sum everything, then the check digit is whatever brings that sum to a multiple of ten.

Worked example on 49015420323751. Doubled positions give 9,1,4,0,2,7,1 → 18,2,8,0,4,14,2 → digit-summed 9,2,8,0,4,5,2 = 30. The untouched positions 4,0,5,2,3,3,5 sum to 22. Total 52, so the check digit is 8 and the full IMEI is 490154203237518.

What an invalid IMEI reveals

Validity has three levels, and each needs a different tool to assess. A number whose check digit does not validate is malformed, and arithmetic alone shows it, offline, with no database. A number that passes Luhn but carries a TAC the GSMA never allocated shows up in a TAC lookup. A number that passes both but names a different model from the one the device reports — an IMEI whose TAC says Pixel 7 on a device whose build.prop says Xiaomi — is inconsistent rather than invalid, and only a party that can read both values is in a position to compare them. As the next section explains, on modern Android that is rarely an app.

Desktop emulators tend to fall at the first level, because nothing ever allocated them an IMEI. The Android SDK emulator has historically returned constants such as 000000000000000, and other emulator stacks return a fixed placeholder shared by every instance ever launched — which means every device in a fleet built on them reports the same number.

Who can read a phone’s IMEI?

Since Android 10, ordinary apps cannot read a phone’s IMEI; the carrier, device-management tools and apps with privileged system permissions can. Most guidance on this is out of date. TelephonyManager.getImei() throws a SecurityException unless the caller holds READ_PRIVILEGED_PHONE_STATE, which is a signature-or-privileged permission — an app from the Play Store cannot obtain it (Android 10 privacy changes). The IMEI is therefore not part of the app-side device fingerprint on any modern handset.

It remains highly visible elsewhere. The carrier sees it on every attach to the network, which is how the GSMA blacklist works: a handset reported stolen has its IMEI added, and participating carriers refuse it service regardless of the SIM inside. Device management platforms, MDM agents and the provider who provisions your fleet all see it too. So the practical question is not "will an app read it" but "does the device have a coherent, unique, persistent one at the layer where it is read".

Checking it in practice

• Dial *#06# on the handset — the universal GSM code, works on every device, shows one entry per radio.
• adb shell service call iphonesubinfo 1 — works on many builds but the transaction number varies by Android version, so verify the output looks like fifteen digits before trusting it.
• Settings, About phone, Status — the reliable manual route when ADB is inconsistent.
• Validate the result yourself with the Luhn arithmetic above before paying for a lookup service.

In a fleet of devices

Two requirements, and providers fail them in opposite directions. Each device needs its own IMEI, so that two devices are never linked by sharing one — the failure mode when images are cloned without regenerating identity. And each IMEI needs to stay attached to the same device across reboots and sessions, so that an account does not see a different handset every time it connects — the failure mode when a stack regenerates identity on each boot in the name of privacy. Randomising per session and cloning across devices are both breakages of device isolation, just at different ends.

A useful acceptance test when evaluating a provider: record the IMEI on ten devices, reboot all ten, record again. Ten distinct values, unchanged after reboot, is the only passing result.