I'm building a app to test Google Nearby Messages API. For that test, I'm using DISTANCE_TYPE_EARSHOT.
According to this thread Nearby API's Strategy.DISTANCE _TYPE_ EARSHOT doesn't seem to restrict message proximity , after the initial link between devices, they can receive messages for 10 minutes regardless of distance. I would like to know if this 10 minute limit can be interrupted (in order to prevent that a device can receive a message when its distance to another device is more than ~5ft - EARSHOT).
Alternatively, is there a way to get the distance between devices?
Thank you.
(I work on the Nearby API)
Today, Nearby doesn't expose distance directly nor does it provide a way to force "un-pairing" of devices programmatically. We've heard folks want both of these things, the features are on our radar, but we can't comment or commit beyond that.
As a manual hack, you can clear data on "Google Play Services" to un-pair devices.
You can get a rough approximation of distance by measuring BLE RSSI if one of the devices is capable of BLE advertising. This will be sensitive to how the device is held, antenna gain and environmental factors but better than random.
There's not a straight-forward "tape measure" API, though.
Related
So I am working with trying to transfer data between two phones with Google Nearby Connections.
For example, say I want to transfer a variable from each phone to another and then show a toast containing the text from the other phone.
I have been looking into the Connections API but I can't seem to limit it to when two phones are really close to each other. I have seen that the Nearby Messages API has an Earshot distance option.
But there isn't an option for earshot distance in the Nearby Connections API since the Nearby messages API doesn't seem to contain what I need to make something like the example above work.
Hope you can help me :)
There hadn't been a feature request for it until now, which is why there's no support in Nearby Connections.
I believe Nearby Messages would support your use case, though. It can exchange a few KB of data to other devices nearby. It's not a live bi-directional channel, like Nearby Connections is, but it doesn't sound like you need that.
Nearby connections uses bluetooth, BLE (Bluetooth Low Emissions) and WiFi. This signals can't be adjusted to reach a certain distance.
Nearby messages, on the other hand, also uses ultrasounds which can limit the phone's reach to a much shorter distance. See this video. It's also stated in the documentation of messages.
So your options are either fully offline connections without distance setting, or online messages with distance setting. Note that messages is not fully online, it only publishes the message to be shared in a google server. The key necessary to retrieve that message is sent offline between users.
I believe that your precise requirement for distance is what is being addressed in this Bluetooth Core Specification 5.1. Therefore, the solution is pending on:
Bluetooth hardware chips 5.1 will happen
Smartphone manufacturer will use these chips
Android Bluetooth library is updated to exploit the new feature of this chip
I'm working on an Android app that needs to detect if other users of the app are close to each other (lets say within the same room or Bluetooth range). The app needs to be able to detect this without any user interaction.
Geolocation is not an option as this is too inaccurate indoors.
The app runs only on company owned phones that stay on company ground, privacy is not a concern.
All devices are always connected to the same wifi network and BT is always enabled.
My idea is to detect if users are within a close distance of eachother by periodically Bluetooth scanning and checking the results against a list of MAC adresses that contain all the devices that have the app installed.
The MAC adresses of all devices are send to a server, the devices then grab this list of mac adresses from the server to compare to the results of a BT scan.
Problem is, BT and Google's seem to use Advertisement / Discovery patterns where one device acts as the server and one device acts as the client. For this to work properly i feel like the devices need to always be discoverable.
Will an implementation based on Google's Nearby or BT work for my needs ?
Is it possible to detect the presence of a nearby device without it being discoverable ?
As battery life is a concern (need to be able to do this for atleast 8 hours a day) is BLE an option?
You can almost certainly handle 8 hours a day if the phones aren't really used for much else. There are a lot of variables, however.
Many older phones require a different type of scanning using infinite scanner restarts in order to properly report "seeing" a peripheral. This can dramatically decrease battery life.
If the phones are running Marshmallow or later, they have a doze mode which interrupts scanning. This can be circumvented using an AlarmManager, JobService/Dispatcher, or WorkManager. This can dramatically decrease battery life.
If the phones are running Oreo or later, they require a foreground service (persistent notification) in order to prevent the app from being automatically killed by the OS to save battery. The app should also be whitelisted from battery optimization because even with the foreground service, the app will still be killed off by the OS.
Finally, scanning and broadcasting and using location services is pretty expensive battery-wise. If you're attempting to cluster phones and guess their position based upon what other phones are nearby, at some level you'll still need the location data off of the phones to figure out where they're at.
You're much better off just scanning. You could carpet your company property with beacons, where each individual beacon's location is recorded. When the phone "enters a region" (comes within range of a beacon), it should send something to your api reporting which beacon it just found. This will tell you what room/area it's in.
Another less flashy (and potentially less accurate) way to track everything would be via the IP addresses of the wireless access points they're connected to. Use a WorkManager to periodically update an api with some unique ID for the phone and the IP address of the AP. Your IT department should know the locations of each of them. This way you get reasonably good tracking and virtually no battery drain.
I'm working on an app at the moment for Android and iOS that uses Nearby Connections to communicate small amounts of data (like a string, character, or int) to other devices. I was originally looking into Nearby Messages but noticed that it needed an internet connection at all times to be able to send the messages to the google server and then to the targeted devices(s). That was not the functionality I wanted and saw that Nearby Connections was more appropriate.
However, unlike Nearby Messages, I could not find a way to limit the range at which the data can be sent like using DISTANCE_TYPE_EARSHOT. Currently, I believe it is always 100m which is ridiculously large and want to reduce it down to possibly a couple feet (maybe 5-10ft). Is this possible somehow with Nearby Connections or would I have to just work with Nearby Messages?
Thank you.
There is no way to limit the range.
Nearby Messages uses ultrasonic to exchange IDs in EARSHOT mode and there is a physical limitation of this kind of exchange.
But Nearby Connections uses radio and only way (very inaccurate) to limit is by signal strength, but Nearby Connection does not expose signal strength via its API.
But don't rely on ~100 meters you see in Nearby docs. As far as I know Nearby Connections only use Bluetooth for initial discovery, and this type of radio is often limited by ~30 meters.
What is the speed at which the broadcasts happens when we advertise using Nearby API in Android? Also, is there any way the speed can be controlled?
I'm supposing you are talking about the Nearby Connections API. In my observations, (pure empirical evidence) in most cases you will be able to discover devices in less than 5 seconds, some older devices can take longer. Anyway, there is no way to directly control these events in the API.
In my application, we want to warn the user when he is at distance from Phone or watch.
We are scanning nearest nodes using APIs of wear OS.
Is there any way I can detect the distance between two such nodes?
Getting geolocation of both & calculate distance using formula is one possible way.
But aren't the APIs on wear OS has something which can detect distance using Bluetooth range or signal strength?
The best that's directly supported by the platform is the Node API's isNearby method, but that essentially just returns true iff the phone-watch connection is over Bluetooth rather than cellular or wifi. It doesn't give you anything resembling a real distance number.
Beyond that, you'd have to roll your own solution using GPS on both devices, as you mention. But that has a lot of downsides: complexity, reliability, and battery use are ones that immediately occur to me. Someday, you'll be able to get this kind of accuracy from the fused location provider using wifi, but probably not for some years.