How to Inspect Wi-Fi RTT and Indoor Ranging Measurements on Android Using ADB dumpsys wifirtt

While Global Navigation Satellite Systems (GNSS) like GPS and Galileo provide meter-accurate positioning outdoors, satellite signals attenuate rapidly inside steel-reinforced concrete buildings, subterranean facilities, and shopping malls. To deliver precise indoor positioning, modern Android platforms leverage Wi-Fi Round-Trip-Time (Wi-Fi RTT), standardized under IEEE 802.11mc and IEEE 802.11az. By measuring the time-of-flight of radio frames between an Android device and supporting Wi-Fi access points or Wi-Fi Aware peers, the operating system calculates physical distance with sub-meter accuracy without requiring traditional signal strength (RSSI) fingerprinting. Using Android Debug Bridge (ADB), engineers can query dumpsys wifirtt to inspect real-time ranging capabilities, peer measurements, and hardware controller states.

How Wi-Fi Round-Trip-Time (RTT) Ranging Operates

Traditional Wi-Fi positioning relies on Received Signal Strength Indication (RSSI). However, RSSI is highly susceptible to multipath reflections, physical obstructions, and dynamic interference, frequently yielding errors of 10 to 15 metres. In contrast, IEEE 802.11mc Fine Timing Measurement (FTM) computes distance based on speed-of-light calculations: Distance = (Time of Flight × Speed of Light) / 2.

The Android WifiRttManager coordinates with the device Wi-Fi chipset firmware to execute FTM handshakes:

• Initiator (Client): The Android device dispatches an FTM request frame to an access point or peer.
• Responder (Access Point): The target access point receives the frame, records its hardware timestamp, and transmits an FTM acknowledgment frame containing the departure and arrival timestamps.
• Multilateration: By ranging three or more 802.11mc-compliant access points with known geographic or building coordinates (LCI – Location Configuration Information), the Android Location Provider computes a precise 2D or 3D coordinate fix indoors.

Querying dumpsys wifirtt exposes whether the underlying Wi-Fi hardware supports FTM, how many ranging requests are actively queued, and whether access point responses pass hardware signal-to-noise thresholds.

Verifying ADB Connection and Wi-Fi RTT Hardware Support

Connect your Android device to your computer via USB or wireless debugging and verify authorization using ADB from your terminal:

adb devices

Confirm that your device is authorized. Next, verify that the wifirtt system service is active and registered in the Service Manager:

adb shell service check wifirtt

The system returns: Service wifirtt: found. (On some older Android 9 and 10 builds, this was registered under rttmanager). To verify that your physical hardware supports 802.11mc ranging, check system feature flags:

adb shell pm list features | grep -i wifi.rtt

If the device supports RTT, the output will return feature:android.hardware.wifi.rtt.

Dumping Wi-Fi RTT Subsystem Diagnostics

To inspect the entire internal telemetry of the Wi-Fi RTT manager, invoke dumpsys targeting the service:

adb shell dumpsys wifirtt

The diagnostic report displays hardware capabilities, active client sessions, and ranging history:

WIFI RTT MANAGER (dumpsys wifirtt)

Hardware Capabilities:
  Supported Features: 802.11mc, 802.11az, One-Sided RTT, Peer-to-Peer RTT
  Maximum Peer Ranging Targets: 8
  Hardware State: AVAILABLE
  Firmware Version: WCN6855_FTM_v4.2.1

Active Ranging Sessions:
  Client UID: 10142, Package: com.indoor.navigation, PID: 3821
  Requested Peers: 3
    Peer[0]: BSSID=00:1a:2b:3c:4d:5e, Channel=36 (5180 MHz), Status=SUCCESS
      Distance: 4.82m (stdDev=0.21m)
      RSSI: -54 dBm
      Measurement Bandwidth: 80 MHz
      Num Successful Measurements: 8/8
    Peer[1]: BSSID=00:1a:2b:3c:4d:6f, Channel=36 (5180 MHz), Status=SUCCESS
      Distance: 7.15m (stdDev=0.34m)
      RSSI: -62 dBm
      Measurement Bandwidth: 80 MHz
      Num Successful Measurements: 7/8
    Peer[2]: BSSID=00:1a:2b:3c:4d:7a, Channel=44 (5220 MHz), Status=SUCCESS
      Distance: 12.40m (stdDev=0.62m)
      RSSI: -71 dBm
      Measurement Bandwidth: 80 MHz
      Num Successful Measurements: 6/8

Auditing Ranging Precision and Standard Deviations

When deploying indoor location services in warehouses or retail facilities, evaluating the standard deviation (stdDev) and success ratio of FTM bursts is critical for calibrating navigation algorithms. You can isolate ranging results using grep:

adb shell dumpsys wifirtt | grep -E "BSSID|Distance|Measurement Bandwidth|Successful Measurements"

Key metrics to audit include:

• Distance: Calculated distance in metres.
• stdDev: Standard deviation of the distance estimate across the measurement burst (values below 0.5m represent high precision).
• Measurement Bandwidth: Ranging accuracy scales with channel bandwidth; an 80 MHz or 160 MHz channel provides significantly sharper timing resolution than a 20 MHz channel.
• Successful Measurements: The ratio of received FTM packets (e.g. 8/8), indicating minimal radio packet loss between initiator and responder.

Inspecting Peer-to-Peer (Wi-Fi Aware) Ranging

In addition to ranging fixed access points, modern Android platforms support ranging between two mobile devices directly via Wi-Fi Aware (Neighbor Awareness Networking – NAN). When two devices communicate over Wi-Fi Aware, RTT calculates relative proximity without an access point.

To audit peer-to-peer ranging transactions, filter the dump for Aware identifiers:

adb shell dumpsys wifirtt | grep -A 6 "Peer-to-Peer RTT"

This reveals MAC-randomised peer tokens and real-time mutual distance calculations, which are commonly utilized in social presence and local device sharing apps.

Troubleshooting RTT Failures and Throttling

If an application fails to acquire indoor distance fixes, inspect the diagnostic dump for common failure conditions:

adb shell dumpsys wifirtt | grep -E "Status=|Error="

Common operational issues include:

• STATUS_FAIL_AP_NOT_RESPONDING: The target access point advertises 802.11mc support in its beacon frames, but its FTM firmware is disabled or overloaded.
• Location Disabled: Wi-Fi RTT requires device Location to be toggled on; if Location is disabled, the RTT manager rejects user-space calls to prevent privacy leaks.
• Scan Throttling: If an application requests ranging bursts too frequently in the background, Android’s power manager throttles execution to protect battery runtime.