Structure of an IMEI
IMEI is typically 15 digits: Type Allocation Code, serial, and a check digit computed with the Luhn algorithm (same family as credit card checks). Some workflows show 14 digits plus software adds the check digit.
The check digit catches transcription errors when someone reads IMEI from a label or screenshot. It does not query a carrier database and does not prove the device is not cloned.
On Android, `TelephonyManager` and dialer codes (`*#06#`) expose IMEI on physical devices; emulators and privacy restrictions may block or fake values. Test accordingly.
What validation tools should do
A good validator strips spaces and dashes, enforces length, runs Luhn, and explains failure clearly (“check digit expected 7”). That is enough for support forms and internal admin UIs.
We have seen apps reject legitimate IMEIs because they stripped leading zeros or parsed input as a number. Store IMEI as string, always.
The IMEI Validator on DroidXP runs entirely in the browser — paste a batch from a spreadsheet, see pass/fail per row. Handy before importing device lists into a CRM.
What checksums cannot tell you
Blacklist status, financing locks, and regional SKU are carrier/OEM databases — separate APIs, contracts, and legal constraints. Do not promise “verified clean device” from Luhn alone.
Dual-SIM phones have multiple IMEIs. MDM consoles need a policy for which one you store as primary.
Privacy regulations treat device identifiers as sensitive. Collect only what you need, retain minimally, and disclose in your privacy policy.
Practical Android workflows
Use checksum validation at data entry time in repair shop portals and trade-in forms. Escalate failed rows to human review instead of silent discard.
Pair IMEI checks with your existing inventory barcode flow — operators already scan; validation reduces fat-finger returns.
For QA, keep a short list of known-valid test IMEIs from manufacturer docs — never use random Luhn-valid numbers that might belong to real hardware.