Game Night app icon Game Night
Bluetooth multiplayer on Android explained — Game Night blog hero Under the hood

Bluetooth multiplayer games on Android: how it works offline

2026-05-15 · 9 min read · by Asad Mahmood

"Why does this game need internet to play with the person sitting next to me?" is one of the most-asked questions in casual-game support channels. The honest answer is that most casual games could absolutely work offline — the studios just chose not to ship that mode because their analytics and matchmaking pipelines all assume a connected device. Game Night ships Bluetooth multiplayer because the underlying Android API has been quietly excellent for years and almost nobody uses it. This post explains how the plumbing actually works, why Google's Nearby Connections API beats classic Bluetooth pairing for game lobbies, and what "no internet required" really means.

Two Bluetooth stacks, not one

The first thing worth understanding is that "Bluetooth" on a modern Android phone is two stacks, not one. There's Bluetooth Classic (BR/EDR — Basic Rate / Enhanced Data Rate), the older protocol that runs things like audio streaming to your car or wireless keyboard pairing, and Bluetooth Low Energy (BLE), introduced with Bluetooth 4.0 in 2010, which is the low-power stack that powers fitness trackers, beacons and the modern AirDrop-style discovery flows.

Stack Typical use Throughput Power profile
Bluetooth Classic (BR/EDR)Audio, sustained streams~1-3 MbpsHigher draw, always-on connection
Bluetooth Low Energy (BLE)Discovery, small messages, beacons~256 kbps practicalLower draw, advertise + connect-on-demand
Wi-Fi Direct / AwareLarge transfers, screen mirroring50+ MbpsHigh draw, Wi-Fi hardware required

For a turn-based board game like Ludo, the messages are tiny (a dice value, a token id, a target square — maybe 30 bytes per turn). BLE is overkill on bandwidth and perfect on battery. For a fast-paced arcade game where the players are passing larger packets — say a 240-byte arcade snapshot 30 times a second — Wi-Fi Direct is the right pick. Google's Nearby Connections API makes that choice for the developer, dynamically.

Why "Nearby Connections" beats classic pairing

Before Nearby Connections, building a Bluetooth multiplayer game on Android meant something like: prompt the user to open Settings ❯ Bluetooth ❯ make their device discoverable ❯ pair manually ❯ return to the app ❯ bind a socket to the paired device's MAC address ❯ hope nothing in the OS pairing cache was stale. It's the worst UX in mobile gaming, which is why almost nobody shipped Bluetooth multiplayer in the 2014-2018 era.

Google's Nearby Connections API, launched in Google Play services 11.0 (June 2017) and substantially upgraded in subsequent releases, replaces all of that with a single high-level call: startAdvertising() on the host, startDiscovery() on the joiners, an in-app confirmation dialog, and you have a socket. The library picks the underlying radio (BLE, Bluetooth Classic, Wi-Fi hotspot, Wi-Fi LAN, even ultrasonic audio in some configurations) automatically, and it transparently upgrades the bandwidth tier mid-session if a larger payload needs to flow.

"Nearby Connections is a peer-to-peer networking API that allows apps to easily discover, connect to, and exchange data with nearby devices in real-time, regardless of network connectivity." — Android Developer documentation, developer.android.com/nearby/connections/overview

P2P_STAR vs P2P_CLUSTER — pick a topology

When you call startAdvertising() you have to declare a strategy. Two are relevant to games:

  • P2P_STAR. One host, many clients. The host is the source of truth; all clients talk to the host, not to each other. This is what most board-game apps want — the host's device holds the canonical game state, and every move broadcasts from there to the other three players.
  • P2P_CLUSTER. A mesh — everyone can talk to everyone. Useful for chat-like applications and for free-roaming games where there's no obvious authority device, but harder to reason about state in.

For Ludo, Truth or Dare and Tic Tac Toe, P2P_STAR is the right pick. The host's device runs the game state machine, validates every move (so a malicious client can't claim to roll a six four times in a row), and ships the diff to the other clients. Game Night uses P2P_STAR for the Bluetooth lobby and P2P_CLUSTER only for the discovery scan itself.

The BLE discovery dance

Here is what actually happens when two phones find each other in a Game Night lobby:

  1. The host calls startAdvertising(serviceId). Under the hood, Nearby Connections starts a BLE GATT advertisement with a custom service UUID embedding the Game Night identifier.
  2. The joiner calls startDiscovery(serviceId) with the same UUID. Their phone starts a BLE scan filtered to that UUID — which is why you don't see every random Bluetooth device on the planet appear in the picker, you only see the one running Game Night.
  3. The joiner's phone sees the host's advertisement, fires onEndpointFound with a friendly name (e.g., "Sara's Pixel").
  4. Joiner taps the name; the library calls requestConnection(), which prompts both devices with a four-digit verification code to confirm.
  5. Once confirmed, the library decides whether to keep the BLE channel or upgrade to Bluetooth Classic or Wi-Fi-based transport — based on the payload sizes the app declares.

The whole thing typically completes in 3-6 seconds. No Settings excursion, no MAC addresses, no manual pairing.

Why your phone asks for LOCATION permission for Bluetooth

This trips up roughly every Android user the first time they hit it. You install a Bluetooth multiplayer game and the permissions dialog asks for location, which sounds intrusive. The reason is historical: Android 6 (2015) through Android 11 used the LOCATION permission to gate BLE scanning because Bluetooth advertisements can be used to infer location (the famous "iBeacon" use-case). Android 12 introduced new BLUETOOTH_SCAN and BLUETOOTH_ADVERTISE permissions that can be requested without location only if the app declares android:usesPermissionFlags="neverForLocation" in its manifest. Game Night declares that flag — which is why on Android 12+ the app does not ask for location, but on Android 11 and below it still has to.

The TL;DR. If your friend on an older Android phone gets a location prompt to play Bluetooth Ludo, that's not the app spying on you. It's a legacy Android permissions model. Modern Android (12+) does not require it.

Bandwidth, latency and the Wi-Fi LAN fallback

For a turn-based game like Ludo, none of this matters at the millisecond level. The latency budget is "human reaction time" — 200-400ms is invisible to the player. BLE round-trip latencies are 30-80ms, Bluetooth Classic round-trips 20-50ms; both well below perception. For a parallel arcade tournament with score updates, the bandwidth requirement is even lower — a handful of bytes per second per player.

Wi-Fi LAN sits alongside Bluetooth in Game Night for two reasons: Bluetooth radios on some Android budget phones silently throttle after a few minutes of advertising, and if everyone's already on the host's Wi-Fi, scanning a QR is faster than any radio handshake. The third mode (online via a six-letter code) kicks in only when your friends aren't physically near you. For the broader survey of offline-multiplayer party games, see our local-multiplayer roundup.

How to actually start a Bluetooth room on Game Night

The theory's interesting; the practical steps take 90 seconds. Both phones need Game Night installed. Then:

  1. Both phones: open Game Night ❯ tap the Friends tab (third icon in the bottom navigation).
  2. Tap the blue Same Room — Bluetooth card. This opens the room screen with a Host/Join toggle.
  3. On the host phone: type a display name, leave Host selected, tap Open the room.
  4. Android may prompt for Bluetooth + Location permission the first time — accept both (Location is required by Android's BLE discovery API; Game Night never reads your geographic location, see the privacy policy).
  5. On the joiner phone: tap Join, type a name. The host's room appears in the discovered list automatically once Nearby Connections finishes its BLE handshake (~3-8 seconds).
  6. Joiner taps the host's name ❯ connected. Host's screen shows the new player as a chip.
  7. Host taps a game tile inside the room — Ludo, Tic Tac Toe, Truth or Dare, Flappy, or Doodle Jump. The chosen game loads on every connected phone.

For a full walk-through with screenshots of all four transports (Pass & Play, Bluetooth, Wi-Fi LAN, online), see the Multiplayer guide.

The TL;DR for users

Most casual games could run offline. Google's API has been good for years. Game Night uses it. Free, no signup, no server-side account required for Bluetooth or Wi-Fi mode.

GET IT ONGoogle Play

Sources