How to Optimise Wi-Fi for a Fleet of Android Devices
A fleet of Android devices – phones for staff, tablets on a shop floor, handheld scanners in a warehouse – puts a different kind of load on Wi-Fi than a handful of personal gadgets. The devices move constantly, they come from many manufacturers, and unlike Apple’s hardware they do not all follow one published set of rules. That fragmentation is the central fact to design around. The plan below covers what actually carries across Android vendors and versions: the roaming standards to turn on, how to plan coverage when you cannot rely on a fixed threshold, how authentication and MAC randomization affect a managed fleet, and how to check the result on site. It is a companion to the same exercise for Apple hardware in optimise Wi-Fi for Apple devices.
Design to standards, not to a single device
Apple publishes the exact signal levels at which iPhones, iPads, and Macs start looking for a better access point. Android has no equivalent. Roaming behaviour differs between Samsung, Pixel, Xiaomi, and the rest, and it shifts between Android versions, so there is no one number to design to. The reliable approach is to lean on the open roaming standards that modern Android devices understand, and to make sure every device always has a clearly stronger access point to move to. You are designing for a moving target, so you build margin into the coverage rather than trusting any single device to behave.
Turn on the roaming standards (802.11k / v / r)
Three IEEE standards make roaming faster and smarter, and Android has supported them for years. Enable all three on your controller or access points, and keep the setting identical across every unit:
- 802.11k (neighbour reports): the network hands a device a short list of nearby access points and their channels, so it does not have to scan the whole spectrum to find the next one.
- 802.11v (BSS transition management): the network can actively suggest that a device move to a better access point, instead of waiting for the device to decide on its own.
- 802.11r (fast transition): the device re-authenticates to the next access point in a fraction of the usual time. This matters most on secured enterprise networks, where a full re-authentication on every hop would otherwise interrupt a call or a barcode scan.
A small number of older clients handle 802.11r poorly, so test the fleet after enabling it rather than assuming every device is happy.
Plan coverage with real overlap
Because you cannot count on a uniform roaming threshold, the design has to do the work the device firmware will not: make the next access point obviously better long before the current one fades. Aim for overlapping cells, where a second access point already delivers a strong signal at the edge of the first. Signal is measured in dBm, a negative scale where closer to zero is stronger: around -30 dBm sitting next to an access point, roughly -67 dBm as a common rule of thumb for reliable voice and video on the move, and -80 dBm and below where connections stall and drop. Plan so that working areas stay comfortably above that rule-of-thumb level and a neighbouring access point reaches the same spot at a similar strength. A plan on paper is only a hypothesis until you walk the space and measure it.
Choose bands and let devices spread out
Android devices use 2.4 GHz, 5 GHz, and – on newer hardware running Android 12 or later – 6 GHz (Wi-Fi 6E). The 2.4 GHz band reaches farther and through more walls but offers only three non-overlapping channels (1, 6, and 11) and is crowded with other devices. The 5 GHz band has many more non-overlapping channels and shorter range, which is an advantage indoors because it limits how much one area interferes with the next; build dense, busy areas on it. The 6 GHz band adds a large block of clean spectrum for the newest devices. Band steering, where the access point nudges a dual-band device onto the less congested band, helps spread a mixed fleet across the available capacity. How channels and bands behave is covered in WiFi channels explained.
Keep the number of SSIDs small
Every Wi-Fi name (SSID) the network advertises carries a steady stream of management traffic that uses airtime whether or not anyone is connected. Extra names do not add capacity – they quietly subtract it. Keep the count low: one network for managed devices, one for guests, and a separate one only for equipment that genuinely needs its own. For why a hidden name is not a security measure, see SSID and BSSID explained; for separating visitors from the fleet, see how to set up a guest Wi-Fi network.
Authenticate the fleet without a shared password
For more than a handful of devices, WPA2 or WPA3-Enterprise (802.1X) is worth the setup. Instead of one Wi-Fi password that every device shares – and that you must change on every device when someone leaves or it leaks – each device gets its own identity or certificate, pushed and revoked centrally through your MDM (mobile device management). Access can then be removed one device at a time without touching the rest. If you do use a shared key (WPA2/WPA3-Personal), remember the trade-off: rotating that key means re-pushing it to the whole fleet, and every device has to reconnect before it works again.
Account for MAC randomization
Since Android 10, a device presents a randomized Wi-Fi address (MAC) to each network by default, and depending on settings that address can change over time. For a fleet this quietly breaks two common practices: MAC-based allowlists stop matching, and DHCP reservations keyed to a hardware address hand out the wrong lease or a brand-new one. There are two clean ways to handle it. Configure the devices through MDM to use their real (device) MAC on your managed network, or stop identifying devices by MAC at all and rely on 802.1X identity instead. Decide before you deploy, not after the address list quietly stops working.
Keep devices on Wi-Fi when you want them there
Many Android phones will fall back to mobile data when Wi-Fi looks poor – a behaviour variously called “switch to mobile data automatically” or adaptive connectivity. On a personal phone that is helpful; on a fleet it can mean devices burning cellular data or leaving your managed network in the middle of a task. If the fleet is meant to stay on Wi-Fi, the real fix is the coverage that triggers the fallback in the first place, and where the platform supports it, the policy can be set through MDM.
Keep access points consistent
Roaming is smoothest when every access point offers the same capabilities and configuration: the same encryption, the same band settings, the same network names, the same roaming standards. A device crossing between mismatched access points may hesitate or refuse to move at all – which undoes the rest of the design.
Validate with a site survey
A design is only a starting point; the real test is walking the space, ideally with the actual fleet devices in hand:
- Open the WiFi Analyzer in IP Tools (Android) or WiFi Tools (iOS).
- Walk each area and read the signal in dBm, confirming not just that the nearest access point is strong but that a second one already reaches the same working areas – that overlap is what makes roaming work.
- Check the channel graph for overlap, and confirm you are not advertising more SSIDs than you need.
Repeat the survey once the space is occupied and devices are active, because people and traffic change the result. For reading signal strength and channels, see WiFi channels explained and the WiFi Analyzer help page.
FAQ
Do Android devices roam at a fixed signal level like Apple?
No. Roaming behaviour varies by manufacturer and Android version, so there is no single threshold to design to. Lean on the 802.11k/v/r roaming standards and on overlapping coverage that always offers a clearly stronger access point.
What is the best way to authenticate a fleet of Android devices?
WPA2 or WPA3-Enterprise (802.1X) with per-device credentials or certificates pushed through MDM. Access can be revoked one device at a time, with no shared password to change across the fleet.
Why do DHCP reservations or MAC allowlists stop working on Android?
Since Android 10, devices use a randomized MAC per network by default. Either configure the real device MAC through MDM on your managed network, or identify devices by their 802.1X identity instead of their hardware address.
Should I enable 802.11r fast transition?
Yes on secured networks – it shortens re-authentication when a device moves between access points, which keeps calls and scans from dropping. Test any very old clients first, as a few mishandle it.