As network topology continues to become more complex and device network behavior becomes more sophisticated, managing your Android fleet of kiosks, digital display signs, and other dedicated devices by IP address is simply not practical. Devices may connect to different wireless access points depending on congestion, obtain a new IP address after a firmware update, or otherwise be a chore to identify because of networking hardware changes upstream. And that’s precisely why you shouldn’t be using IP addresses as identifiers.

Android has multiple immutable identifiers you can use to reduce drift and avoid tedious manual reassociation (or worse, mistaken identity). They fall into one of two piles, and both options require that the Android (AOSP or GMS) device is configured with a “device owner” under your control. This makes them a bit more involved to access initially, but they provide far more reliability than your old school IP.

Option one: Hardware MAC (hardware address)

Like any device with a network stack, Android can report an immutable hardware MAC address — one that will survive factory resets, network changes, and anything else (short of replacing the physical system on a chip). As of Android 10, this hardware MAC address can only be accessed at the fleet level if you have a device owner set on the device, and if you have a tool like Esper’s console to manage your fleet, you can pull that ID in and apply policies and deploy software appropriately.

This hardware MAC is the one that never changes, but it’s not Android’s only MAC address, and it’s not the one your network is likely to report. On Android, a MAC address isn’t always the *right* MAC address to track – you also have virtual MACs.

As part of Android 10, Google introduced MAC address randomization to Android. This behavior ensures that, instead of the hardware MAC address of the device reporting to the network, a virtual address generated on the first connection to a Wi-Fi SSID is reported. This virtual MAC address is stored and permanently associated with that SSID on the Android device. A network has no way to know this is not the “real” MAC address or any way to force the device to expose that “real” hardware MAC.

This virtual MAC address will also change under two circumstances:

  • The Wi-Fi SSID, Wi-Fi password, or Wi-Fi security type of a particular network change (even if it is the “same” network)
  • The device is factory reset (erased)

If either of these conditions is met, Android will generate a new virtual MAC for that SSID on the next connection. Each virtual MAC is unique to each saved Wi-Fi SSD on the device, meaning if you have multiple SSIDs on your network, you’ll create multiple MAC addresses for a single device if it needs to remember all of them. While a device that never needs to be erased and a network that never changes may be the ideal situation for your fleet, even we think that’s a little optimistic.

Further, in Android 12, Google introduced a new MAC randomization behavior that will make this virtual MAC address even less reliable as an identifier in the future, actively resetting the address daily (or even more often). While not enabled by default for most networks, it stands to reason Google may require it in later versions of Android, as it continues to invest in ways to make consumers harder to track without direct consent using things like device network identifiers.

Android offers a user-facing option to disable MAC randomization on a per-SSID basis, but enforcing this at fleet scale would be impractical, even using remote control. As such, to use the MAC address as a reliable, accessible hardware identifier, you need to ensure it is just not the “right” address, but that you have the right tools to obtain and meaningfully leverage it.

Option two: Serial number (or IMEI)

Given its mobile heritage, even the earliest versions of Android shipped with a standardized hardware identifier (IMEI) for all cellular devices. Android also provides a standard serial number field that must be associated at the factory, which is what you’ll generally find on Wi-Fi-only devices like most Android tablets.

Either identifier is a good candidate for a permanent hardware asset ID. While device IMEI can technically be changed by a person with root access to a device, on cellular hardware, this is illegal in many countries. IMEI survives factory resets, firmware upgrades, and just about anything else.

The serial number is the most common way to identify an individual device on Android devices without a cellular modem. Like IMEI, serial numbers in Android are strictly defined as immutable and survive any kind of device state change, including a factory reset.

And just like the hardware MAC address, both the IMEI and serial number are inaccessible to applications without special permissions in Android. While a user can access these identifiers in the system UI, gathering and collating them systematically is something you’ll need help with.

Esper makes it easy to get your IMEI or serial number from a device, ensuring the correct policies are applied and the right software deployed. Set up a demo with us today, or try it out for yourself right now.