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.
Some example use cases:
- Collaborative whiteboard: Jot ideas down with nearby participants on a shared virtual whiteboard.
- Local multiplayer gaming: Set up a multiplayer game and invite other users nearby to join.
- Multi-screen gaming: Use a phone or tablet as a game controller to play games displayed on a nearby large-screen Android device, such as Android TV.
- Offline file transfers: Share photos, videos, or any other type of data quickly and without requiring a network connection.
Nearby Connections enables advertising, discovery, and connections between nearby devices in a fully-offline peer-to-peer manner. Connections between devices are high-bandwidth, low-latency, and fully encrypted to enable fast, secure data transfers.
A primary goal of this API is to provide a platform that is simple, reliable, and performant. Under the hood, the API uses a combination of Bluetooth, BLE, and Wi-Fi technologies, leveraging the strengths of each while circumventing their respective weaknesses. This effectively abstracts the vagaries of Bluetooth and Wi-Fi across a range of platforms and OS versions, allowing developers to focus on the features that matter to their users.
Usage of the API falls into two phases: pre-connection, and post-connection.
In the pre-connection phase, Advertisers advertise themselves, while Discoverers discover nearby Advertisers and send connection requests. A connection request from a Discoverer to an Advertiser initiates a symmetric authentication flow that results in both sides independently accepting (or rejecting) the connection request.
After a connection request is accepted by both sides, the connection is considered to be established and the devices enter the post-connection phase, during which both sides can exchange data.
Advertising and discovery
Advertisers will become visible to other discovers and discoverers will be notified when a new advertiser is found or has been lost.
When a discoverer wishes to connect to a nearby advertiser, the discoverer can request a connection.
Both sides will be notified of the connection initiation process and both will have the opportunity to accept or reject the connection.
Once both sides have responded, each will be notified of the result. If both sides accepted the connection, the connection is considered established, and data transference can then begin.
After a connection is established, further API usage is symmetrical, so there’s no longer a distinction between Advertiser and Discoverer.
Both sides can now exchange data. There are 3 types of supported Payloads:
- Bytes: Byte arrays limited to 32k; these are good for sending things such as metadata or control messages.
- File: Files of any size; these are transferred from the app to the network interface with minimal copying across process boundaries.
- Stream: A stream of data that is generated on the fly, as in the case of recorded audio/video, with no final size known beforehand.
Receivers will be notified of new incoming data and any progress updates, cancellations or failures.
The connections established are full-duplex, which means that advertisers and discoverers can simultaneously send and receive data.
When using the Google Play services Nearby SDK, usage analytics are collected to improve the experience.
- Performance metrics: Discovery and connection latency, reliability and throughput are collected when scanning for and connecting to devices using the Nearby SDK.
- Device information: Device model, country, build version and the application package name are collected and associated with the performance metrics to identify regional and device-specific slices.
End users can allow or deny this collection by navigating to Settings > Google > Usage & diagnostics.