Android Nearby Connections: Build Offline Peer-to-Peer Features

Last updated: October 6, 2026

If you've ever wanted two Android phones to talk to each other without a cell signal or Wi-Fi network, Google has an API built exactly for that job. A new tutorial published on kodeco.com walks developers through the Nearby Connections API, showing how to wire up a peer-to-peer TicTacToe game that runs on two handsets in the same room.

The guide is aimed at Android developers who already write in Kotlin. It leans on Bluetooth and Wi-Fi under the hood, but you don't touch those radios directly. Instead, the API picks the best path for you and cleans up after itself when you're done.

Key facts:

• Google offers an Android API that lets nearby phones link up without internet.
• It blends Bluetooth and Wi-Fi behind a single interface.
• The kodeco.com tutorial builds a two-player TicTacToe game using the API.
• It assumes Kotlin experience and physical devices (emulators aren't supported here).
• The library ships as a Play Services dependency, so it isn't baked into the OS.

How the API actually works

At its core, the API splits devices into two roles. One phone acts as the Advertiser, meaning it announces itself and waits for someone to join. The other phone is the Discoverer, scanning the local area for that announcement. Once the two find each other, they negotiate a connection and can push data back and forth.

What's clever is the plumbing. You don't write Bluetooth Classic code, you don't wrangle Wi-Fi Direct sockets, and you don't ask the user to manually pair anything. The API picks whichever radio fits the situation, swaps mid-session if needed, and hands back a simple payload channel. When the session ends, your phone's radios go back to whatever state they were in before.

According to kodeco.com, the project pulls in the Google Play Services Nearby Maven library at version 18.3.0. That delivery model is the same one you've seen with Maps and Firebase, where it's distributed through Play Services rather than shipped inside the core Android OS.

Setting up permissions and the client

Before any of that runs, your app needs the right permissions. The tutorial walks through the manifest changes: Bluetooth, Bluetooth admin, Wi-Fi state access, location access, and the newer Bluetooth advertise, connect, and scan permissions for newer Android releases.

Location shows up because Bluetooth scanning on older releases piggybacks on it. You also need a small block of version-aware logic so the app asks for the right permissions depending on which Android generation it's running on, without breaking older installs.

Getting the connection client is a single call: `Nearby.getConnectionsClient(context)`. The tutorial threads that client into a ViewModel through a factory, which is a tidy way to keep the connection logic testable and separate from your UI code.

Our analysis

Here's where it gets interesting for Android developers eyeing their next feature. Most apps today assume the internet is always there, which falls apart on airplanes, in basements, at crowded conferences, and in regions with patchy coverage. Nearby Connections fills that gap without forcing you to become a networking specialist.

There's a trade-off, though. Because it's a Play Services module, anything using it inherits the usual Google Mobile Services baggage: extra APK size, a Play Services dependency, and no support for fully de-Googled devices. The tutorial also notes you can't test it on emulators. Real hardware is the only way to see two devices handshake.

For the kinds of apps our readers tend to love, this opens up some fun possibilities. Think local multiplayer party games, classroom tools that sync tablets without a school router, or field-service apps that hand off inspection reports between a technician's phone and a coworker's tablet on the same site. You also get a clean path to phone-as-remote-controller setups for Android TV, since the same payloads work across device types.

A worked example: offline score sharing at a game night

Say you run a weekly pub-quiz app, and you've always relied on a backend to sync team scores between players. Your players, though, are crammed into a basement bar where the Wi-Fi is shaky and the 4G is worse.

Here's how you'd approach it with this API. On the host phone running your quiz, you start an Advertising session that publishes the room name and quiz ID as a service ID. Other players open the app, hit Join, and become Discoverers. Once the connection settles, every correct answer gets sent as a small payload from the player phone to the host, which tallies scores in real time. When the round ends, the host pushes the final leaderboard back out as a single payload so every screen updates at once.

You'd still need your normal online sync for analytics and persistent records. But for the actual live experience, the API removes a network you can't count on.

What to watch next

Bottom line: the Nearby Connections API is one of the more underrated pieces of the Android toolbox, and the new kodeco.com walkthrough is a solid starting point if you've been curious. It's not going to replace your cloud backend, but it can make the in-the-room experience dramatically smoother, which is often the moment that matters most.

Keep an eye on three things as you evaluate it for your own apps. First, watch Google's release notes for any future moves to unbundle this from Play Services. Second, pay attention to how Bluetooth permission changes evolve on newer Android versions, since that half your door code touches user-facing prompts. Third, think about your fallback path: always design an online mode so users aren't stranded if the API ever changes or drops support on a specific OEM skin.

Key takeaways

• Nearby Connections lets two Android phones swap data without internet, using Bluetooth and Wi-Fi under the hood.
• The kodeco.com tutorial demonstrates it by building a two-player TicTacToe game in Kotlin.
• Because it's a Play Services module, it works on most consumer Android phones but skips emulators and de-Googled devices.
• The API is a strong fit for local multiplayer, classroom tools, and offline-first field workflows.
• Plan for version-aware permissions and keep an online fallback so your app isn't trapped if the offline path fails.