Most IT teams can tell you exactly how many Windows laptops they own. Ask them about Android, and the number gets soft. Handsets roam between Wi-Fi and cellular, sit in drawers, get handed between employees, and never announce themselves to a network scanner. That gap is where compliance findings, license waste, and lost hardware live.
Learning how to inventory Android devices across your organization is less about buying one tool and more about deciding which system holds the truth. Get that decision wrong and you end up with three half-complete lists that disagree with each other.
This guide breaks down why Android breaks conventional discovery, the two data planes you actually need, and a workflow that keeps the count accurate as the fleet churns.
Why Android devices defeat traditional inventory tools
Network discovery was designed around a persistent, cooperative endpoint. A Windows workstation stays on the corporate subnet, answers WMI queries, and exposes a stable footprint. A network scanner walks an IP range, fingerprints the OS, and pulls a rich hardware and software snapshot.
Android violates almost every one of those assumptions. Phones drop off Wi-Fi and route over LTE, so they aren’t in the scan window when the audit runs. They don’t speak WMI, and consumer builds don’t expose SNMP the way a switch does. When a scanner does catch one, it usually sees a transient MAC and IP with no reliable link to a serial number or an owner.
This is worth stating plainly, because vendor marketing blurs it. A cloud discovery engine like Alloy’s AlloyScan is genuinely strong at what it targets – Windows, Linux and macOS computers, physical servers, hypervisors, SNMP-managed network gear, and cloud resources across AWS, Azure and Google Cloud. Handsets are not in that scope, and no amount of network scanning turns a roaming Android phone into an inventory-grade record. Recognizing that boundary is the first step to a mobile device inventory that actually reconciles.
Telemetry vs. system of record: the two data planes
A durable Android device inventory separates two responsibilities that teams tend to collapse into one.
The first plane is live telemetry: the device’s current state – OS version, security patch level, storage, installed apps, encryption status, compliance verdict. This comes from an Enterprise Mobility Management (EMM) or Mobile Device Management (MDM) platform through enrollment, not from a scan.
The second plane is the system of record: the business truth about the asset – who owns it, what it cost, its warranty and contract, its location, its lifecycle stage, and the tickets and CMDB relationships tied to it. This lives in IT Asset Management (ITAM), and it survives even when a device is offline, wiped, or between users.
MDM knows what a device is right now. ITAM knows what the device means to the business. Confuse the two and you get an inventory that’s technically accurate and operationally useless – a list of live handsets with no clue whose they are or when the lease ends.
What EMM/MDM actually collects (and where it lies to you)
Enrolled corporate Android devices report a lot: model, manufacturer, IMEI, serial, OS build, patch level, and full app inventory. Google’s Android Management API is now the recommended path for this, and Google is actively deprecating the older custom device policy controllers that platforms like Intune, Ivanti and Jamf used to rely on.
But the telemetry has sharp edges that quietly corrupt inventories. Android serial numbers aren’t guaranteed to be unique or even present, and the value the OS reports may not match what’s printed in device settings. A single device can carry multiple IMEIs. Personally owned (BYOD) work-profile devices intentionally return only partial data – partial app inventory and partial phone number – because the personal side is walled off for privacy. And the data isn’t real time: Intune, for example, refreshes hardware and software inventory roughly every seven days after enrollment, so a device compromised on day two looks clean until the next pull.
If you build reconciliation logic on serial number alone, these quirks generate duplicate rows and phantom devices. That’s not a tooling failure; it’s the nature of the platform.
Comparing your Android inventory data sources
No single source covers the whole picture. The practical decision is which sources you combine, and which one you crown as authoritative. The table below reflects how these methods behave in production, not on a datasheet.
| Data source | What it captures for Android | Real coverage | Key limitation | Best used as |
| Network scan (AlloyScan, Lansweeper) | Transient MAC/IP/hostname while on Wi-Fi | Poor for handsets | No agent hook, roams to cellular, no WMI/SNMP | The fleet’s computers, servers, network gear – not phones |
| Android Management API (Google) | Model, IMEI, serial, OS, patch level, apps, compliance | Full on corp-owned; partial on BYOD | Requires enrollment; DPC path deprecating | Live telemetry and policy enforcement |
| MDM/EMM (Intune, Ivanti, Jamf) | Same telemetry class + compliance state | Full on managed; partial on work profile | Serial not guaranteed unique; ~7-day refresh | Compliance, patch, and remote actions |
| Barcode scan (Alloy Inventory Scanner) | Asset tag, serial, location by human scan | Only what you physically scan | Point-in-time, labor-intensive | Receiving, physical audits, spot-checks |
| ITAM / CMDB (Alloy Navigator) | Owner, cost, warranty, location, lifecycle, ticket links | Every asset you record or import | Only as accurate as the feeds into it | The single system of record |
The pattern is clear: EMM supplies state, ITAM supplies meaning, barcode scanning fills the gaps for devices that never enroll, and network discovery handles everything that isn’t a phone. The system of record is the one that ties them together.
Why Android inventories drift out of sync
Even a well-tooled fleet decays without deliberate reconciliation. The drift almost always traces back to a handful of root causes.
Enrollment gaps come first: any device that’s provisioned but never enrolled is invisible to telemetry, and BYOD hardware that employees decline to enroll simply doesn’t exist in the count. The BYOD privacy boundary compounds this, because even enrolled personal devices return deliberately incomplete data. Offline and cellular-only devices miss scan and refresh windows. Identity collisions from non-unique serials and multi-IMEI hardware spawn duplicates. And underneath all of it sits the real problem – no agreed system of record – which lets each tool maintain its own conflicting list with no referee.
A 6-step workflow that holds up
Here is the sequence that keeps an organization-wide Android inventory accurate through hardware churn. The order matters; skipping the first step is why most attempts collapse.
- Name the system of record before choosing tools. Decide that your ITAM/CMDB – not any single MDM – owns the authoritative Android asset record. Everything else feeds it.
- Enroll every corporate device through Android Enterprise. Provision at purchase using zero-touch or Knox where possible, so a device is managed from first boot rather than chased down later.
- Connect the EMM to your ITAM on a schedule. Sync IMEI, serial, model, OS version, patch level, owner and compliance state automatically, not through periodic CSV exports that go stale the day after.
- Reconcile identity on a stable key to kill duplicates. Match on enrollment ID plus IMEI rather than serial alone, since Android serials aren’t reliably unique or present.
- Tie each record to a user, location, cost and ticket. This is the business context MDM never holds, and it’s what turns raw telemetry into an asset you can manage, bill and audit.
- Schedule re-audit and enforce offboarding. Re-pull telemetry regularly (weekly refresh is typical) and build wipe-on-return into the lifecycle so retired handsets actually leave the count instead of lingering as ghosts.
Enrollment mode decides what you can ever see
Step two above carries more weight than it looks, because the Android Enterprise enrollment mode sets a hard ceiling on visibility. You can’t report on data the mode was designed to hide. Choose it for the device’s real purpose, not by default.
| Enrollment mode | Ownership | Inventory visibility | Practical note |
| Fully managed (COBO) | Corporate | Full hardware + full app inventory; phone number reported | Best for issued work phones; maximum control |
| Dedicated (COSU) | Corporate | Full, single-purpose | Kiosks, scanners, signage; not tied to one user |
| Corporate work profile (COPE) | Corporate | Full device inventory, but phone number not reported | Work/personal split on a company device |
| Personally owned work profile (BYOD) | Personal | Partial app inventory and partial phone number | Privacy boundary caps what IT can ever see |
The takeaway for anyone planning how to inventory Android devices across your organization: decide the ownership model before deployment. Converting a BYOD device to fully managed later means a factory reset, so the visibility you want has to be designed in at enrollment.
When network discovery isn’t enough
For the parts of your estate that do respond to scanning – the servers, laptops, hypervisors and SNMP gear around your Android fleet – a cloud-native discovery engine keeps that data fresh automatically. AlloyScan audits those assets agentlessly or via agent and feeds them into a unified inventory, so your mobile records don’t sit in isolation from the rest of the environment.
The mobile handsets themselves belong in an ITAM system of record that can absorb EMM telemetry and hold the business context around it. Alloy Navigator plays that role: it links each device to an owner, a location, a cost and a service ticket, and maintains the CMDB relationships that let you answer “whose phone is this, what’s on it, and what does it cost us?” in one place. That’s the difference between a live device list and an inventory you can defend in an audit.
Deep dive: making discovery data trustworthy
Accurate inventory ultimately depends on how you collect and reconcile the underlying data – agent-based versus agentless, scheduled versus on-demand, and how snapshots de-duplicate into a single record. If you want to go deeper on the mechanics of dependable auditing for the non-mobile side of your estate, this breakdown of agentless network discovery and audit explains the trade-offs that carry over to how you should treat mobile telemetry too.
FAQ
Can I inventory Android devices with a network scanner alone? No. Network scanners fingerprint devices that stay on the subnet and expose WMI or SNMP. Android handsets roam onto cellular, sleep, and don’t answer those protocols, so a scanner sees only transient traffic. Reliable Android telemetry requires EMM enrollment, with ITAM holding the authoritative record.
What’s the difference between MDM and ITAM for Android inventory? MDM (or EMM) reports a device’s live state – OS version, patch level, apps, compliance. ITAM records the business truth: owner, cost, warranty, location, lifecycle, and ticket links. MDM knows what a device is now; ITAM knows what it means. A complete inventory feeds MDM data into ITAM as the system of record.
Why do the same Android devices appear twice in my inventory? Duplicates usually come from matching on serial number, which Android doesn’t guarantee to be unique or even present. A device can also report multiple IMEIs. Reconcile identity on a stable composite key – enrollment ID plus IMEI – rather than serial alone, and duplicates largely disappear.
Does BYOD limit what I can inventory? Yes. Personally owned work-profile devices deliberately return partial data – partial app inventory and phone number – because the personal side is walled off for privacy. If you need full visibility, deploy corporate-owned fully managed devices, and set that ownership model at enrollment rather than trying to convert later.
The bottom line
An accurate Android device inventory isn’t a scan you run once; it’s an architecture. EMM supplies live telemetry, barcode scanning covers the devices that never enroll, network discovery handles everything that isn’t a phone, and a single ITAM system of record ties it all to owners, cost and lifecycle. Decide which system holds the truth first, enroll deliberately so the mode never caps your visibility, and reconcile on identity keys that Android won’t undermine. Do that, and the number stops being soft – even as the fleet churns.
