Nearby Messages: Sharing Information With The Person That Is Near You

Let’s say you don’t want to shout like you were doing using Nearby Notifications, but rather talk to someone more privately. Good news, Google had you covered with Nearby Messages.

In my previous blog post I covered Nearby Notifications. A piece of technology that gives you means to advertise yourself to people near you. Note that according to the last update Google is discounting support for Android Nearby Notifications.

Chit chat

Let’s say you don’t want to shout like you were doing using Google Nearby Notifications, but rather talk to someone more privately. Good news, Google had you covered with Google Nearby Messages. It is designed to cover scenarios when you want to share small amount of data between devices that are in a near vicinity. What is very important is that this solution works seamlessly on Android and iOS. It uses combination of WiFi, Bluetooth, Bluetooth Low Energy and ultrasounds. An ultrasound, how cool is that!

A yet another messenger…. nooooot!

“…share small amount of data between devices…”. Well, nothing new you may think. We already can do this over SMS, Bluetooth or some kind of a messenger application. Yes, we can, but let’s think what you have to do before message can be sent. Enter a phone number of a person that you will probably never see again, go through Bluetooth pairing procedure or register in a social media service, all that just to do this one simple thing. With Google Nearby Messages app you have none of this. Just open an app, find a person that is near you, share content and that is it.

google nearby google nearby apps android nearby google set up nearby device google nearby beacon iphone nearby

Google nearby devices are using all kinds of modems and audio peripherals to communicate. Data goes also over Google Cloud servers, hence the Internet connection is required. Let’s start from the beginning.

Unlike for Google Nearby Notifications, two devices must explicitly advertise and discover which forces user to use some kind of an application.

When application starts to advertise message, it connects to Google Cloud where registration token is sent. The token will use speakers to emit ultrasounds (earshot strategy) or Bluetooth (default strategy) to broadcast the token to the nearby devices. More on ultrasounds and strategies in ‘Security’ paragraph.

When second device starts to discover Google nearby devices it uses a microphone to pick up ultrasounds (earshot strategy) or Bluetooth (default strategy) and searches for the broadcasted token.

Everyone that has a registration token of another device can go to Google Cloud and say “Hey! Give me a message that is related to the token”

The above can be condensed into the graph. See HERE!

Nearby Esperanto

Communication being so simple has another advantage. “Everyone can talk to and listen to everyone” model allows for messages to be sent and understood across different applications. The key is the message format being simple byte arrays. In most case scenarios I expect simple strings to be sent, so an application can just call String.fromBytes(…) / String.toBytes(…) and that’s it. We can come up with a wrapping protocol where first bytes describe message type (string, URL, JSON / XML, small image content).

Security of Nearby Messages

There are three concerns when it comes to security of Google Nearby Messages:

  • a device to Google Cloud communication
  • device-to-device communication
  • token and data payload relation.

Let’s analyze them one by one.

The first channel can be considered as secured. Communication between device and Google Cloud is as secured as any other HTTPS situation. Thus, your trust is as strong as, for instance, when you are using Google service.

The only situation where a device communicates with another device directly is when exchanging a token. This is when everyone is talking to everyone and everyone is listening to everything. A handshake protocol is not described in documentation but I assume that cracking is as hard as hard was to intercept communication for cars keyless solution. There is one thing that we can do to enforce security and that is the strategy that we use when advertising. We have two possibilities, earshot and default. The first one uses near ultrasound spectrum to advertise the token. Why? Broadcasting range is limited (Google says about 1,5 m or 49 ft, for me it was more like 30 cm, so 12 inches), so it reduces possibility of getting the token into unauthorized hands.

Default strategy uses Bluetooth, so whoever is in 10 m (32 ft) range can tap in.

The last thing to discuss is relation between token and data that is being sent. Are we safe here? The answer is no! Token is a function of a device and application which is valid for ca. 10 minutes. If you have a token from a different device you can hear what the owner is talking for the next 10 minutes, even if message changes over time.

To sum up, Nearby Messages provide low level of confidentiality in a bare form and with a little bit of code which can be strengthened. The problem is that there is no possibility to reject once someone wants to listen to us. We are broadcasting, but we don’t know who is listening to us.

Find beacons with ease

So far I showed you how to communicate between two phones. In my previous post we’ve learned that beacons are such devices that constantly transmit some chunks of data. Using Google Nearby Messaging we can take advantage of it and use them to carry a message for us. For Google Nearby Notifications, the Eddystone-URL format was the only viable option while we are interested in Eddystone-UID and iBeacon only. In a contrary to Nearby Notifications, we can use beacons for proximity alerts. What we are getting are notifications alerting that we’ve picked up a beacon, a beacon is not in range anymore or distance to beacon has changed. Sounds familiar? For me it works exactly the same as if I was using different beacon library (eg. AltBeacon).

google nearby google set up nearby device iphone nearby google nearby devices nearby notifications google nearby apps android nearby google nearby notifications google nearby beacon

Scuderia Nearby

There you have it. Messages, next to Notifications, are a yet another tool that can help you build great contextual aware applications. It gets rid of logins, passwords, numbers or any other gimmick that user is burden with when he or she wants to do one simple thing… share information. Whether you want to exchange contact information, share a link to a video with playing kittens or pay for a parking in a BLE enabled parking meter, Nearby Messages can make it easy as one click. The only complain that I have is the security. I would not recommend using Google Nearby Messages to build business class secured applications. Even with most harsh restrictions there is still a gap that someone can take advantage of.

Get hands dirty

If you are one of those tech people and you are starving for “some meat” I prepared a small demo Android application (with iOS one in tow). Here is where Google Nearby Messages shine. To accomplish the above, there is very little development to be made. To add core implementation you need no more than half an hour and about 50 lines of the code. To prove that, a source code can be found HERE.

Before you start, make sure that you have a Google Account to enable Nearby API, Android Studio and 2 devices with access to the Internet to test on.

  • Create Android Application project

Nothing tough here, just use Android Studio to create a new project.

  • Obtain API key

Go to Google Console and create a new project or select the existing one.

Having the project selected, go to Library -> Google API, search for Nearby Messages API and enable it.

Go to Credentials -> Create Credentials -> API key -> Restrict key. Having the key created in Key restriction section, choose Android key, then Add package name and fingerprint. Specify your application package and sign key SHA-1 fingerprint. The letter can be obtain by calling signingReport Gradle task for your application.

  • Dependency and manifest

In application build.gradle file add Nearby dependency:

compile ‘’

In manifest add:

    android:value="API_KEY" />

Where API_KEY is the one created for you in Google Console when adding credentials, it should look something like this: AIzbSyBdVl-cTIXSwYKrZ95SuvNp7dbMuDt1KG0

  • Connect Google API Client

Here is basically the same story as for other Google APIs, eg. Maps.

googleApiClient = new GoogleApiClient.Builder(this)
    .enableAutoManage(this, onConnectionFailedListener)

The worthy thing about this code is enableAutoManage() method. It is optional, but I highly recommend using it because it automatically deals with permissions management by presenting an opt-in dialog.

  • Publish message

When Google API client is connected, you can start publishing messages to the devices near you

    .publish(googleApiClient, MESSAGE, publishOptions)

Publish options give you a possibility to specify some connection options like distance or message expiration time. publishResultCallback object is a simple success / failure handler.

  • Listen to the messages

Now, it is time to subscribe for Nearby Messages. Things are basically the same as for broadcasting a message:

    .subscribe(googleApiClient, messageListener, subscribeOptions())
//messageListener handles received messages

public void onFound(Message message) {
    final String message = "Found message: " + new String(message.getContent());

and notifies you that other party stopped transmitting (or you are out of range)

public void onLost(Message message) {
    final String message = "Lost message: " + new String(message.getContent());
  • Cleanup

As mentioned before Nearby Messages use all sorts of connectivity mediums. It impacts also on a battery. Therefore, when you are done with exchanging informations ,please be nice and release Nearby and Google API client. The best place to do this is in onStop() method.

Stop publishing

Nearby.Messages.unpublish(googleApiClient, message);

Stop listening

Nearby.Messages.unsubscribe(googleApiClient, messageListener);

Disconnect Google API client


Beacons have a voice too

Adding support for beacons to our yet existing application is no more than 20 lines of code. It is a matter of modifying MessageFilter

MessageFilter messageFilter = new MessageFilter.Builder()
    .includeNamespacedType(<message namespace>, <message type>)
    .includeEddystoneUids(<hex namespace>, <hex instance>)
    .includeIBeaconIds(<proximity UUID>, <major>, <minor>)

and providing beacon format specific values. You can learn these values by using simple “beacon scanner” application.

To properly handle messages from “BLE friends”, just add some code to MessageListener

public void onFound(Message message) {
    String log = null;
    if (isEddystoneBeacon(message)) {
        EddystoneUid eddystoneUid = EddystoneUid.from(message);
        log = "Found Eddystone UID: " + eddystoneUid;
    } else if (isIBeacon(message)) {
        IBeaconId iBeaconId = IBeaconId.from(message);
        log = "Found iBeacon Id: " + iBeaconId;
    } else {
        log = "Found message: " + new String(message.getContent());
    Log.d(LOG_TAG, log);

The implementation for onLost(Message message) is basically the same.

Wow! That’s a lot of information. Stay tuned for the next part from the “Nearby” series - Nearby Connections! If you have any questions, feel free to email us!

Read also

Most Read

1 What is a legacy system, and why do companies keep using them?
2 Mobile payments security. What should developers know about it?
3 How to fold QA into every sprint
4 Software development view of healthcare wearables
5 How to quickly add a date dimension to a Pentaho Mondrian OLAP cube
6 Nearby Messages: Sharing Information With The Person That Is Near You
7 Creating a digital product for the healthcare industry?
8 7 reasons to use real time data streaming and Flink for your IoT project
9 How to create an effective Asset Tracking System?
10 Minimum Viable Product (MVP) in software development - what it is and how to define it. Product Owner and Project Manager perspective.

Digital products from concept to launch

We understand that creating a product is a challenging and risky endeavor and believe that having a partner with experience and know-how is a critical first step.

Learn More

The Digital Product Journey

From idea to launch we guide you through the startup experience

Learn More
Path Created with Sketch.

Before you head out, you can download our latest E-book “18 Software Product Killers Every HealthTech Strategist Needs to Know (part 1)”

Yes, we know it's a mouthful, we're working on it. Enjoy!