Android Radio Technologies:
Capabilities & Constraints

What BLE can do

• Continuous background advertising — Radar uses a foreground service to keep a BLE advertiser running indefinitely, broadcasting a compact presence beacon that contains a peer ID, relay counter, and signal-strength data. Android API 21+
• Background scanning with callbacks — The BLE scanner can report nearby advertisements in real time, powering the live peer map and feeding the mesh relay logic. Android 8.0 and later deliver scan results via PendingIntent even when the foreground service is briefly paused. Android API 26+
• GATT connections for data exchange — Once two devices discover each other via advertisements, Radar can open a GATT client/server channel to exchange structured messages, routing tables, and compressed payloads at up to ~250 kbps, all without internet.
• Bluetooth 5 extended advertising — On BT 5-capable hardware, Radar can use extended advertisements with payloads up to 254 bytes (versus the 31-byte limit of legacy advertisements), enabling richer peer metadata in a single beacon without a GATT connection. Android API 26+, BT 5 hardware
• Manufacturer-specific data (MSD) — Unlike some locked-down platforms, Android lets Radar embed arbitrary bytes in the manufacturer-specific data section of BLE advertisements, carrying routing metadata, message fragments, and hash identifiers.

Restrictions & limitations

• Android 8.0+ scan throttling. Google introduced a hard limit of 5 scan starts per 30-second window per app. If Radar restarts its scanner too frequently (e.g. due to Bluetooth stack resets), the OS silently blocks subsequent starts until the window resets. Radar works around this with an adaptive back-off strategy, but the constraint is real and cannot be bypassed. Android 8.0 / API 26
• Background scan de-duplication. Android de-duplicates BLE advertisements from the same MAC address, reporting a new result only after a configurable interval. If a peer's advertisement payload is static, Radar may not receive updated signal-strength readings for many seconds, reducing proximity accuracy.
• Android 10+ location permission required for BLE scanning. Google tied BLE scanning to ACCESS_FINE_LOCATION because BLE scan results can be used to infer a user's location. Without this permission, the startScan() call silently returns zero results — no error, no warning. On Android 12+, this was split into BLUETOOTH_SCAN and BLUETOOTH_CONNECT permissions. Android 10 / API 29 · Android 12 / API 31
• MAC address randomisation. Android 10 enabled random MAC addresses by default for all BLE advertising and scanning. This prevents passive tracking by third parties, but it also means a device's BLE identity changes periodically. Radar uses application-layer peer IDs embedded in the advertisement payload rather than relying on MAC address stability.
• Foreground service requirement for sustained scanning. Android 14 tightened rules around background-started foreground services. Radar must use a foreground service with the correct foregroundServiceType (specifically connectedDevice) to maintain BLE scanning and advertising after the user leaves the app. The persistent notification this requires is mandatory and cannot be suppressed. Android 14 / API 34
• Effective range is short and environment-dependent. BLE advertising range in real-world urban or indoor conditions is typically 10–40 m, dropping sharply through walls, bodies of water, or dense crowds. Signal-strength (RSSI) readings are noisy — ±5–10 dBm variation is normal — making reliable distance estimation difficult without averaging across many samples.
• Throughput ceiling. The BLE 4.x physical layer tops out at roughly 1 Mbps raw, with a GATT application-layer throughput of approximately 100–250 kbps in practice. Larger payloads (images, voice clips, maps) are transferred over Wi-Fi Aware or Bluetooth Classic instead.

What Bluetooth Classic can do

• RFCOMM serial sockets for reliable data transfer — Once two devices are paired, Radar can open an RFCOMM channel to exchange files, routing tables, and binary payloads at practical speeds of 1–3 Mbps. This is substantially faster than BLE GATT for large payloads. Android API 5+
• Discoverability scanning — Android can query nearby discoverable devices via a classic Bluetooth device discovery scan, useful for bootstrapping connections before switching to BLE or Wi-Fi Aware.
• Mature and universally available — Every Android device since API 5 supports Bluetooth Classic. It requires no special hardware beyond the standard Bluetooth radio, and works across all Android versions without additional feature flags.

Restrictions & limitations

• Pairing is mandatory for all data connections. Unlike BLE advertising — which is connectionless and requires no prior relationship — every Bluetooth Classic data connection requires the two devices to be bonded (paired). Pairing involves a user-facing confirmation dialog on both devices, making it impractical for automatic mesh discovery with unknown nearby peers.
• Discoverability is time-limited and user-controlled. A device only announces itself to classic Bluetooth scans while in "discoverable" mode, which Android limits to a maximum of 300 seconds per activation and requires explicit user consent each time. A device is never discoverable by default. This prevents passive background peer discovery for mesh networking.
• Background discovery scanning requires location permission. Like BLE, classic Bluetooth device discovery requires ACCESS_FINE_LOCATION on Android 9 and below, and BLUETOOTH_SCAN on Android 12+, because nearby device names can infer location.
• Higher power consumption than BLE. BR/EDR radio operation consumes significantly more battery than BLE advertising. Maintaining a classic Bluetooth connection continuously in the background would materially drain the battery of both devices. Radar reserves Classic Bluetooth for short bursts of high-bandwidth transfer rather than persistent connections.
• No connectionless advertising or broadcast. Bluetooth Classic has no equivalent of BLE advertising — there is no way to passively broadcast data to nearby devices without establishing a paired connection first. This makes it unsuitable as a primary mesh discovery channel.
• Android 12+ BLUETOOTH_CONNECT permission required to initiate connections. Google split the legacy BLUETOOTH permission into granular permissions in Android 12. Connecting to a paired device now requires BLUETOOTH_CONNECT to be explicitly granted at runtime — a change that broke some older apps and must be handled carefully. Android 12 / API 31

What Wi-Fi Aware can do

• Peer discovery without any network infrastructure — Wi-Fi Aware (IEEE 802.11az/NAN) lets devices publish and subscribe to named services. When a subscriber finds a matching publisher, both devices are notified — with no router, hotspot, or internet connection involved. Android 8.0 / API 26
• Encrypted peer-to-peer data sockets — After discovery, Radar can negotiate a direct Wi-Fi Aware data path — essentially a private network link between two devices — and open standard TCP/UDP sockets over it. Practical throughput reaches 50–150 Mbps, enabling rapid file transfer completely offline.
• Sub-second discovery latency — The NAN synchronisation protocol keeps participating devices loosely time-synchronised using a shared Discovery Window. Devices wake periodically (typically every 512 ms) to exchange NAN frames, achieving peer discovery in one to a few seconds without constant radio activity.
• Background operation via foreground service — Radar keeps a Wi-Fi Aware publish/subscribe session alive in the background using a foreground service, enabling the live radar view to update continuously while the app is not in focus.
• Distance estimation (ranging) — On Android 9+ with Wi-Fi RTT (Round-Trip Time / 802.11mc) capable hardware, Radar can also query the distance to a Wi-Fi Aware peer to within approximately ±1–2 m. Android 9 / API 28, Wi-Fi RTT hardware

Restrictions & limitations

• Hardware support is not universal. Wi-Fi Aware requires a Wi-Fi chipset and firmware that implements the NAN protocol stack. While all major Android flagship devices since 2019 support it, budget and mid-range devices from many manufacturers do not. Radar falls back to BLE-only mesh when Wi-Fi Aware is unavailable on a device.
• Location permission required — and checked at runtime. Google requires ACCESS_FINE_LOCATION to use Wi-Fi Aware because NAN service names and MAC addresses can reveal a user's location. If the user has denied location permission, Wi-Fi Aware sessions cannot be created. On Android 13+, this must be granted at runtime with the full precision location permission — approximate location is insufficient. Android 13 / API 33
• Cannot function as a general-purpose mesh relay across more than two hops. Wi-Fi Aware data paths are point-to-point. To relay a message from device A to device C through device B, device B must actively receive, decode, and re-advertise the data — there is no broadcast or multicast data path. Radar handles multi-hop relay in its application layer, but each hop is a discrete NAN session.
• Concurrent NAN sessions are chip-limited. The number of simultaneous Wi-Fi Aware publish/subscribe instances and active data paths a device can maintain depends on the chipset. Most devices support a handful of concurrent sessions, but there is no guaranteed floor across all hardware. Radar manages session pools carefully to avoid exhausting the limit.
• Wi-Fi must be enabled; hotspot mode conflicts. Wi-Fi Aware requires the Wi-Fi radio to be on. On most Android devices, enabling a Wi-Fi hotspot disables the station-mode Wi-Fi interface, which also disables Wi-Fi Aware. Radar detects this state and relies solely on BLE when the user has a hotspot active.
• Android 13 "Nearby Wi-Fi Devices" permission. Google introduced NEARBY_WIFI_DEVICES in Android 13, separating Wi-Fi peer-discovery from location permission. Apps must request this new permission in addition to (or instead of) location permission when targeting API 33+. Devices running older Android versions ignore this permission, so Radar must handle both code paths. Android 13 / API 33
• Power management can interrupt NAN sessions. Aggressive battery optimisation (Doze mode, manufacturer-specific battery optimisers such as MIUI's battery saver, Samsung's Adaptive Battery) can suspend the Wi-Fi radio and terminate NAN sessions without notice. Radar prompts users to whitelist the app from battery optimisation, but cannot programmatically bypass these restrictions.

What UWB can do

• Centimetre-accurate ranging — UWB (IEEE 802.15.4z) uses time-of-flight measurement of ultra-wideband radio pulses across the 6–8 GHz band to determine the distance between two devices to within ±10–30 cm. This is an order of magnitude more precise than BLE RSSI estimation or Wi-Fi RTT. Android 12 / API 31
• Angle-of-arrival direction finding — Devices with multiple UWB antennas (such as the Google Pixel 6 Pro and later, Samsung Galaxy S21+ and later) can report not just distance but also the azimuth and elevation angle to a peer, enabling true 3D relative positioning. This powers a directional pointer compass in Radar, showing which physical direction a peer is in.
• Secure ranging sessions — Android's UWB API requires a two-device handshake (Ranging Controller / Controlee) and a shared session key before ranging begins. This prevents a third party from covertly ranging against your device without mutual consent.
• Works in combination with BLE for session setup — Radar uses BLE to exchange the UWB session parameters (channel, preamble, session key) out-of-band, then starts UWB ranging. This pairing of BLE for control and UWB for ranging is the standard Android pattern. UwbManager API, Android 12+

Restrictions & limitations

• Very limited device support. As of 2025, UWB hardware is only found in flagship Android devices: Google Pixel 6 Pro and later (with some model exclusions), Samsung Galaxy S21 Ultra and newer flagships, and a small number of other premium handsets. Mid-range and budget devices universally lack UWB hardware. Radar degrades gracefully to Wi-Fi RTT or BLE RSSI proximity when UWB is unavailable.
• UWB_RANGING permission required at runtime. Google gates UWB access behind the UWB_RANGING runtime permission (introduced in Android 12). Without it, no ranging session can be opened. Unlike BLE, UWB does not require location permission — it is considered a dedicated ranging technology rather than a location inference vector. Android 12 / API 31
• Both devices must support UWB and have the app installed. UWB ranging is strictly peer-to-peer with bilateral consent. You cannot range against a device that does not also have Radar running and has not granted the permission. This limits UWB to connected Radar pairs, not the wider mesh.
• Short effective range. UWB ranging in the Android/FiRa (Fine Ranging) profile is reliable up to approximately 20–50 m in line-of-sight conditions. Range drops sharply through walls and dense materials, and multipath reflections in indoor environments can introduce measurement outliers.
• No data transfer capability. Android's UWB API is ranging-only — it reports distance and angle, nothing more. It cannot transfer messages, files, or any application data. All communication still flows over BLE or Wi-Fi Aware; UWB only adds precision location context.
• Background ranging is restricted. A UWB ranging session initiated in the foreground will continue briefly in the background, but Android does not guarantee sustained background ranging without a foreground service. Radar requires an active foreground service to maintain UWB sessions for the live proximity compass while the app is backgrounded.
• Google Play's UWB policy and CDD requirements. The Android Compatibility Definition Document (CDD) defines required UWB behaviour for devices that declare the UWB feature flag. Manufacturers may implement UWB in proprietary ways that differ from the AOSP API contract, meaning Radar must handle device-specific quirks and variations in ranging accuracy and update rate across different chipsets (NXP SR100T, Qorvo DW3000, etc.).

What NFC can do on Android

• Tap-to-connect peer pairing — Radar uses NFC to bootstrap a trusted relationship between two devices with a single physical tap. The NFC exchange delivers a compact handshake payload containing a peer public key, device ID, and initial session token — the same data that would otherwise require scanning a QR code or manually entering a pairing code. Android API 14+
• NDEF tag reading and writing — Android provides full read/write access to NFC Data Exchange Format (NDEF) tags. Radar can write a peer-invite record to an NFC tag (sticker, card, keyring fob) so that any nearby Android device can tap it to join a Radar group without any prior setup. Android API 10+
• Android Beam / NDEF Push (legacy) — On devices running Android 9 and below, Radar could use NDEF Push (NFC peer-to-peer) to deliver pairing data between two unlocked, screen-on devices held back-to-back. This worked entirely over the NFC radio with no internet or Bluetooth required. Android API 14–28 (deprecated Android 10)
• Host Card Emulation (HCE) for contactless identity — Android allows apps to emulate an ISO 14443 contactless card using the device's NFC controller — no SIM or secure element required. Radar can use HCE to present a contactless peer-identity card, enabling a tap-to-identify gesture even when the other device does not have Radar installed (any NFC reader can receive the NDEF record). Android API 19+, HCE hardware
• Out-of-band key exchange for BLE and UWB sessions — NFC is an ideal out-of-band channel for securely bootstrapping higher-bandwidth radio sessions. Radar uses a single NFC tap to exchange BLE bonding keys or UWB session parameters, after which the connection migrates to BLE or Wi-Fi Aware for actual data transfer — combining NFC's physical security with the range and throughput of the other radios.

Restrictions & limitations

• NFC requires screen-on and device unlocked for foreground dispatch. Android's NFC foreground dispatch system — which routes incoming NFC tags or peer touches to the active app — only fires while the screen is on and the device is not locked. Radar cannot receive NFC events in the background or from the lock screen (except via HCE, which has its own restrictions).
• Very short range — typically 1–4 cm. NFC operates at 13.56 MHz with a practical coupling distance of 1–4 cm between antennas. This is not a limitation Radar can work around — it is a fundamental physical property of near-field inductive coupling. It also means NFC cannot substitute for BLE, Wi-Fi Aware, or UWB for distance-based proximity detection.
• Android Beam removed in Android 10. Google deprecated and removed the Android Beam (NDEF Push Protocol) API in Android 10, citing low adoption and the availability of better alternatives (Bluetooth and Wi-Fi). Radar's NFC pairing flow on Android 10+ relies solely on NDEF tag writing and HCE rather than P2P NFC push. Removed: Android 10 / API 29
• HCE competes with payment apps and the secure element. Host Card Emulation shares the NFC controller with contactless payment systems (Google Pay, bank apps). When the device screen is off, HCE is generally reserved for the default payment app. Radar's HCE-based identity card only operates while the screen is on, to avoid conflicts with payment flows.
• NFC hardware not guaranteed on all Android devices. While most mid-range and flagship Android devices include NFC, many budget handsets — particularly in price-sensitive markets — omit the NFC controller entirely. Radar checks for PackageManager.FEATURE_NFC at startup and disables NFC features gracefully on devices that lack the hardware.
• NFC permission and AndroidManifest feature declaration required. Apps must declare <uses-permission android:name="android.permission.NFC" /> and <uses-feature android:name="android.hardware.nfc" android:required="false" /> (with required="false" to remain installable on non-NFC devices). Unlike Bluetooth or location, NFC does not require a runtime permission grant — the install-time declaration is sufficient — but the user can disable NFC globally in device settings, which silently stops all NFC operations.
• Transfer speed is not suitable for bulk data. NFC ISO 14443 Type A/B operates at 106, 212, or 424 kbps. Even at the highest rate, transferring more than a few kilobytes takes perceptible time. Radar uses NFC exclusively for small handshake payloads (key material, peer IDs, invite tokens) and immediately hands off to BLE or Wi-Fi Aware for any substantial data exchange.