Direct answer: A rugged Android handheld connecting to Wi-Fi, or advertising Wi-Fi 6/6E, does not establish that it can measure distance to access points with Wi-Fi RTT. Indoor ranging requires the exact handheld hardware and Android build, compatible access points, an appropriately permissioned app and a tested method for turning distances into a useful location decision. Ask for those pieces together before adding “indoor positioning” to a purchase specification.
Choose the observation before choosing the radio feature
Ordinary Wi-Fi connectivity answers whether the work app can exchange data with a network. Wi-Fi round-trip-time (RTT), also called Fine Time Measurement (FTM) in the relevant standard, estimates distance to compatible access points from timing exchanges. One distance is not a floor-plan coordinate. Android’s Wi-Fi RTT guide describes using measurements to three or more access points with a multilateration algorithm to estimate device position. That requires reliable AP positions and useful geometry in the actual work area; a project must test its own result and must not adopt a general documentation accuracy figure as a device guarantee.
If the business only needs network coverage and application continuity, use the Wi-Fi 6/6E selection guide and the roaming and application-recovery guide. RTT is a separate purchase question when the application needs a device-location observation indoors. Outdoor receiver and field-app source selection are addressed by the external GNSS guide; GNSS capability cannot substitute for a tested indoor RTT design.
Specify the full ranging chain
Android introduced Wi-Fi RTT in Android 9 (API level 28). Its current developer guide requires compatible FTM hardware on the requesting device and access point, location services and Wi-Fi scanning, and the app’s relevant permissions. Android 15 (API level 35) adds support for 802.11az non-trigger-based ranging when the device supports that initiator mode; an Android version alone does not prove the hardware does. On the candidate build, the application team should check FEATURE_WIFI_RTT and runtime availability through WifiRttManager.isAvailable(), then perform an actual ranging request to the specified APs. Feature presence and current availability are different observations.
The Android guide distinguishes app target versions for permissions: an app targeting Android 13 or higher requires NEARBY_WIFI_DEVICES for the stated RTT path, while an earlier target uses ACCESS_FINE_LOCATION; a location-producing application must also review the guide’s location-permission details instead of copying a simplified manifest blindly. The guide also says ranging must be requested while the app is visible or in a foreground service, with background work subject to restrictions. Confirm the exact target SDK, granted permissions, device location settings and work pattern with the app owner. A Wi-Fi association or internet-speed result is not an RTT result.
Ask the AP supplier which installed AP model, firmware and configuration responds to the chosen 802.11mc or 802.11az mode, and how its surveyed position is recorded. Android notes that certain APs can return location information, but an AP position still needs a trustworthy project reference. Record floor, coordinate system, AP moves and calibration responsibility. A network survey for connectivity alone does not automatically supply these inputs.
Editorial example: finding the handset’s work zone
Constructed evaluation scenario, not a customer result or accuracy claim: a warehouse app wants to suggest whether a handheld is in receiving zone A or packing zone B before the operator opens a task. The site has three proposed RTT-capable APs with documented positions. Candidate 1 joins Wi-Fi and completes a WMS task, but its build does not expose RTT support; connectivity passes while indoor ranging remains unproven. Candidate 2 exposes the feature and receives distance results from only one of the three APs in zone B; that is insufficient to treat a calculated zone as confirmed. Candidate 3 receives usable observations from the intended AP set, but the app still has to compare a calculated position with the surveyed zone boundary and show what happens when results are stale or ambiguous.
For each candidate, retain device SKU and OS build, AP identities/firmware/locations, app version and target SDK, permission state, response status and timestamp for each range request, calculated position or zone and the operator’s verified reference point. Repeat at representative aisles, near metal racks, after an AP restart and after the device changes power or location settings. Set project thresholds for correct zone decisions and rejected/unknown outcomes before testing. Do not convert a single successful measurement into a promised building-wide precision or service level.
When a range disappears, do not invent a position
A request may fail because the handheld build lacks RTT, the AP lacks the selected responder capability, Wi-Fi scanning or location services are off, permission was denied, or availability changed while tethering or other device functions were in use. The Android guide describes separate feature and availability checks for precisely this reason. The application should expose missing or stale observations and its configured fallback; it should not silently reuse the last position as if it were current.
Good ranging data can still produce the wrong business zone if AP positions, floor association or geometry are wrong. Likewise, a correct zone suggestion does not prove which asset was scanned or whether a task transaction reached the backend. Keep the location observation, operator action and accepted business record separate. If the buyer instead needs the last area in which a tagged asset was observed, the UHF/BLE asset-observation comparison addresses a different object and evidence chain.
How to accept or reject the proposed configuration
- Confirm the feature chain: exact handheld SKU, radio chipset/firmware and Android build; AP model/firmware and selected RTT mode; app version, target SDK and permissions. Mark any unverified piece open.
- Confirm raw ranging: log per-AP responses, failures and timestamps at named survey points with unchanged device and AP configurations. Distinguish a range response from a derived location.
- Confirm the location decision: compare the calculated zone or coordinate with a surveyed reference and the application’s required tolerance, including ambiguous and unavailable outcomes. Do not treat the Android platform’s illustrative accuracy as an acceptance limit.
- Confirm operations: repeat after restart, permission change, AP outage or repositioning, and check how an old location is marked or rejected. Record who maintains the AP-location data.
- Confirm the business boundary: demonstrate that any task using a location hint still saves to the correct business record and that a failed ranging request does not create a false completed task.
Start with the rugged handheld category, then give the AP list, floor plan, Android/app requirements and acceptance thresholds to Integration Support. Use Contact to request exact-model RTT evidence and a bounded sample test. This article does not claim that any listed AIDC GO handheld, access point or application already supports Wi-Fi RTT.
Source and scope
Android Developers’ Wi-Fi location: ranging with RTT and WifiRttManager API reference were checked on 2026-09-23 for Android API levels, hardware/AP prerequisites, permissions, feature and availability tests, and ranging behavior. They describe platform conditions, not an AIDC GO model qualification or a measured warehouse result. The scenario and test plan above are editorial examples.