I am working on my Bachelor Thesis and I have to implement an application using Google Nearby Connection API. The goal is to develop a disaster assistance app.
I tested Google Nearby Connection for the past two day and I have some problems, quesitons.
I have 6 devices, 4 Motorola G (2nd Generation), 1 Nexus 5X and 1 OnePlus 5T. They all are up to date. I also use the latest version of Google Nearby
'com.google.android.gms:play-services-nearby:15.0.1'
Here are my questions:
The Motorola devices ask for a pairing code to connect one to another, but even when the pairing is accepted they do not connect.
Some device connect flawlessely (OnePlus and Nexus) but the Motorola have problems connecting, the often throw this error : STATUS_BLUETOOTH_ERROR
Is it possible to create a mesh application that will forward message form device to device? With the testing I made I am starting to wonder if that's really feasable.
During my testing I often discover and advertise in the same time. Is there a better way to do so that might avoid problems?
I used the documentation of google and some other ressources I found online.
Here is the code I had at the end: Gist Link
Thank's a lot for the help guys!
Disaster assistance apps have actually been talked about a lot on our team, as a really interesting use-case. I work on Nearby, the team that built (and maintains) Nearby Connections. It's definitely feasible, once you know the limitations.
I believe that Motorola bug has been fixed on our internal builds, so look out for it in the coming months. The update will be pushed out to all devices (you don't need to update your app) in 1.5~2 months. Wish we could push it faster, but it is what it is. They should be connecting if the pairing dialog is accepted, though. If that's not working, I unfortunately don't have a work-around.
We've found that toggling Bluetooth is the best way to get around STATUS_BLUETOOTH_ERROR, as the radio can get into a bad state (especially on Android versions older than N... which is... a lot of Android versions...). We do our best to toggle semi-often, by toggling the radio after apps stop using Nearby Connections, but sometimes that's not enough. In extreme cases, the phone may have to be rebooted. This error can also go away on it's own, and can also be somewhat alleviated by stopping discovery before connecting.
Yup, meshes are definitely possible. For an always connected mesh, you'll want to use P2P_CLUSTER. Try to keep 3~4 simultaneous connections per device (and have some kind of logic to avoid forming islands). Once the devices are connected, you'll need to build a protocol to send messages, flooding the network for broadcasts or hoping between nodes for directed messages. Other ways to solve this problem that I've seen are using advertise / discovery to transmit short pieces of information asynchronously, or setting up a timer (eg: Once an hour, everyone scans and tries to connect to exchange data, and then quickly disconnects), or forming a 'snake-like' connection where everyone connects to at-most 2 devices and forms a long string of connections.
Advertising is usually lightweight, but discovery can be hard on the radio. We turn it off internally while you connect, but we turn it back on for the duration of the connection. This can lead to flaky connections. If you're able, try to limit discovery to short bursts.
PS: You can check my post history to get some more in depth information about Nearby Connections.
PPS: In the future, break up your stack overflow questions into smaller, more pointed questions. It's more helpful for people searching in the future.
Related
Recently my team has been working on developing an Android application to serve as a purpose similar to a teacher-attendance tool. The idea is a teacher device will advertise and around ~20 student devices will discover and connect with it.
Right now, we are testing with three Kindle Fire 7 devices. One is the "teacher" and the other two are students. Our use case is:
"Teacher" device advertises
First "student" device discovers
Verify first "student" device is connected to teacher
Second "student" device discovers
Verify second "student" device is connected to teacher
It turns out, when a specific one of the devices is used as the "teacher," the above use case works every time with no problems. However, when the "teacher" is hosted on either of the other two devices, we encounter some problems. The most common result in this case is that the teacher will advertise, the first student will discover it and connect, and then the second student will discover it as well, but will fail to request a connection (line 5 above), returning STATUS_BLUETOOTH_ERROR. In some cases, the same device will significantly delay its process of discovery, in which it stalls for several minutes before it even starts looking for endpoints, and eventually results in the same error.
I've scanned through Stack Overflow posts regarding this bluetooth error, and we've tried to make the fixes that have been suggested- having bluetooth toggled, setting both P2P_STAR and P2P_CLUSTER as the strategy, restarting the devices, stopping discovery of the faulty device and re-attempting discovery and requesting the connection- but unfortunately it seems like none of these are really resolving the issue.
Does anyone have insight into why this could succeed on certain devices, but not for others? We made sure all of these devices have identical network settings/configurations, and they're the same model of Kindle, so I'm not sure what could be going wrong.
EDIT: I haven't included my code because there's a lot pertaining to Nearby Connections and I didn't want to make the length of this post overblown; In general, we directly emulated the approach demonstrated by Google's example repos for Rock, Paper, Scissors and Walkie-Talkie. If it would still be helpful to see the code, I will post it.
During testing of Google Nearby Connections 2.0 using the sample walkie-talkie program in automatic mode, sometimes the device will ask for Bluetooth pairing pin number. I have seen two scenarios:
Only one device has a pop-up dialog asking for pin. Enter any data or dismiss the dialog will cause the connection to fail
Both devices have pop-up dialogs. One to ask for setting up pin and other ask to enter the pin. After pin has been entered, the connection was a success.
Senario 1 happens more often.
How can I avoid this problem? I can not find any information on the Nearby Connections 2.0 SDK documentation.
I am also seeing this error in my own app, which uses Google Nearby Connections 2.0. The "walkie-talkie" sample program uses the P2P "star" strategy, whereas my app uses the P2P "cluster" strategy. Therefore, we can see that the problem occurs in both cases. I would like to know:
(1) What causes this error?
(2) What (if anything) can the app receiving the error do to remedy it?
(3) If something needs to be done to the physical devices in this situation, what would be a reasonable message to tell the user?
I have found very little good technical documentation about error conditions in Nearby Connections 2.0, and would very much like to see some. Therefore, even if nobody is able to answer this specific question directly, I will consider awarding the bounty to the best answer that provides other technical information about Nearby Connections errors.
After some testing, I believe this problem is related to BLE advertising function. Here is what I did to minimize the problem:
We can roughly group android devices into three groups:
Non Bluetooth-BLE devices
Bluetooth-BLE but does not support BLE Advertising with API level 21
Bluetooth-BLE with proper support of BLE Advertising with API level 21
When using Nearby Connections 2.0:
Group 1 is only good for searching and link with device that is
advertising
Group 2 can do advertising, but it is difficult to judge how reliable it is
Group 3 probably offer more reliable performance
For people who is working with Nearby Connections 2.0, I suggest that you find out which of the three groups that your devices belong to. Using group 3 devices is preferable and minimize problem with Bluetooth.
PS: Always read Google announcement with caution.
I am developing an p2p application in android for an educational project in which I want to form groups android phones of students nearby and exchange sensor data in a university campus.
Now there are some considerations :
Devices will automatically discover each other and upon discovering connect and exchange data.
The process runs for a long time maybe 4-8 hours per day. (process of periodically sensing data and exchanging )
Now the p2p groups can be formed using either Bluetooth or WiFi (Not WiFi Direct, simple UDP packets over WiFi considering phones are connected on campus WiFi).
What are pros and cons of using Bluetooth and WiFi in this scenario in terms of reliability, power usage of phones, scalability and any other you can suggest.
Among other answers and input, I would added this answer.
First of all, before we chose WiFi or Bluetooth we need to find out the difference between those two technologies.
I have made comparison chart that covers some of the important information you might need regarding your project.
Note: There are different versions of Bluetooth's and WiFi, this chart is to represent the the general picture of Standard Bluetooth,
Bluetooth v4 and WiFi. It is always suggested to refer to manufacture
specification of each technology.
From the chart we can conclude that Bluetooth has lower power consumption vs WiFi, but at the other hand WiFi has more bandwidth than Bluetooth.
Range in general is just approximation, a lot of things affecting range like human body, obstacles, location (inside or outside), if inside; structure type and materials used inside the building, noise from other sources and devices etc.
(*) Regarding scalability, I have tested WiFi and Bluetooth v4, both system with up to 8 devices, where one of those is host (group owner, server) device and 7 others are guest (clients). see the figure below.
What regards reliability, with Bluetooth v4 I have had some time connectivity problems, but when it works than every-thing is fine.
Note: Bluetooth v4 is not back compatible with older versions of Bluetooth, so if your host is Bluetooth v4 than all other clients
should have Bluetooth v4 or vice versa.
So I will not say which one is best, but if you need longer battery life and light data communication than Bluetooth is the way. Regardless if it is Bluetooth OR WiFi you might need to start with Bluetooth to and test it, if you are happy with it than keep it, otherwise switch to WiFi.
In case you want to build your own code, the code example I followed and used previously for another university research project. It is based on 8 phones (host and client) as seen in the figure above, we collected sensor information and send it to host phone using Bluetooth 4 connection. The source code we used for that can be found here. The same project has WiFi and other type of connections.
Android official google documentation has some information and code example regarding WiFi peer to peer connection, you can follow with example of the code as well.
Regarding collecting your sensor data and sending those to one device. You could added a method that starts collecting sensor or what ever data, and after connection is established successfully than start sending it over to the other device.
As others suggest https://developers.google.com/nearby is also a way to go.
As you can rely on campus Wifi, I would definitely go with the implementation of Google Nearby APIs in my App as it was designed for such use cases...
The way it works answers your question : it makes all the heavy stuff for you, including choice between wifi or Bluetooth for better performance...
Google Nearby is definitely a good choice. You don't have to tackle all the problems when working with WiFi or Bluetooth directly. But Google Nearby only works when both devices are online and have their screens on. For a more critical review of Nearby have a look at http://blog.p2pkit.io/how-google-nearby-really-works-and-what-else-it-does
If you can not accept these limitations, you should look into other frameworks like http://www.p2pkit.io.
Disclaimer: I work for Uepaa, developing p2pkit for Android and iOS.
Currently I have a question about using Android Wifi, Bluetooth APIs together.
(Please be noted that it's a problem on app development, not for a normal user guide)
I have a trouble when search device' services via Wifi at the same time with searching device via Bluetooth.
For more info:
On wifi search, I use Bonjour protocol (an Apple's implement of Zeroconf which can help locating services that local network devices offer). The Java implement that I use is jmdns. During the search session, I create a MulticastLock in order to receive multicast packages of Bonjour.
On bluetooth search, I just use BluetoothAdapter together with BroadcastReceiver to get bluetooth device info.
Problem happens to the search result, whenever two search sessions above are executed at the same time, mysearch result on Bonjour (Wifi) search has never get enough like it does when only it is executed.
Ex: Bonjour search just gets 1 instead of 2 device' services when search together with Bluetooth. Bluetooth search result is always enough, however.
This is tried many times and I surely confirm that there is nothing related to network' strength problems.
Has anyone met this problem yet?
Even if your situation is about using Wifi together with Bluetooth, any experiences or guests are very helpful to me!
Khoi.
I am doing pretty much the same stuff you are doing.
My experience differs in that:
I do not use Bluetooth discovery, as I know what device I want to connect to. I just initiate a client connection.
I use Asynctasks for background operations. What are you using?
Two possible issues:
Multiple Asynctasks not executing in parallel due to Android faulty implementation. I have had a similar bug after setting my Android API target to the latest SDK (as it is best practice). Now, after API13, Android Asynctask implementation changed and tasks are NO LONGER executed in parallel (so my wifi thread never started for example, if bluetooth thread was running!!!). The fix is to put a couple of lines of code to make the default executor parallel again, or to just use API11 or lower as target version. See this thread for details.
OverTheAir interference between the 2. Bluetooth discovery is, to my knowledge, the most expensive operation you could do on Bluetooth. So that 2.4GHz multi-purpose chip may be swamped over the air. Internally it has coexistence between WiFi and BT. Remember the WiFi and Bluetooth channels over the 2.4GHz overlap. So what I am saying doing discovery over the same main frequency at the same time might not work that great. You should investigate that...
Is it possible to set up the Android Bluetooth Chat sample app to connect more than one person at a time, and have a mini chat room? What would that entail?
tl;dr version: Bluetooth sucks for this, don't use it, use wifi instead, probably backed by a web backend.
I have investigated this issue thoroughly throughout the years in the interests of a social wireless network research project. My general advice is: it doesn't work with more than two / three people. Bluetooth just isn't designed with wireless peer to peer networks in mind.
In general, it seems that the cheap Bluetooth controllers included on Android devices (especially HTC's devices, iirc) don't really handle any more than two or three connections at a time. I'm unsure if this is a hardware or firmware problem, but I can recount some basic anecdotes. I was working to implement this idea at the SDK level (i.e., without firmware modifications) around the beginning of 2011, and was able to get a peer to get two additional connections (i.e., three devices, each connecting to the other two) to work for a period of a few minutes to an hour before the connections would suddenly die and the socket would become unusable, requiring reconnection. Unfortunately, 20 minutes was an upper bound, and generally it was impossible to get connections to more than one other device at all reliably.
The goal of the project was to support multiple people interacting with each other silently in the background, but this never materialized, instead we ditched Bluetooth and went with wifi instead, which worked much much better. In the abstract, I think people view Bluetooth as a possible medium for reliable peer to peer communication, but it wasn't really designed that way: it's more of a medium used for short range communication between small devices (think headsets).
Be aware that if you want to do this, the maximum number of devices to which you can connect is fixed, because as per the Bluetooth spec, a piconet supports a maximum of seven devices. (See the wikipedia article.)
The required change is simple: you use a different UUID for each device. This can be implemented a number of ways, using an out of band exchange mechanism, or simple scheme where you assign UUIDs in an increasing fashion and when connecting to the network, try each in succession.
Here are some relevant Google groups threads:
Bluetooth peer to peer networks
Multiple connections on Android Bluetooth
I remember posting a more elaborate one detailing how to do this (with code) that I might dig up as well.., if I can find it. It should be from late 2010 or early 2011.
So the answer is, in the abstract, yes, you can try to do this, by using multiple UUIDs (after you use one, that's it, and you have to try another using some assignment protocol). However, in practice, after a lot of trial and error, this doesn't really work for what you probably want to use it for, and it's a lot better to go with an internet backend instead. By the way, this is also good for another reason, most users don't really like to turn on their Bluetooth for fear of their battery being drained..
Leaving this here, in case it helps someone else.
I was able to make my custom chat room following official bluetooth tutorial and modifying it a little.
Unfortunately, I cannot provide most of my code, but main idea is:
Every device is acts both as server and as a client. When Chat is started, device starts its server thread. Server thread is the same as official but doesn't ends when accept connection. It just keep listening.
Client thread is identical as in tutorial.
Both server and client thread manages connection same. I created separated threads for accepting messages following this tutorial and one for sending them.
private void manageConnectedSocket(BluetoothSocket socket) {
//create thread responsible for sending messages.
SendingThread w = new SendingThread(socket);
MainActivity.addSendingThread(w);
//Creates listener for messages to accept.
MainActivity.addListener(socket);
}
Now in main activity always when user click send button, for each worker (sending thread) send message to remote device. Listening is running asynchronously.
IMPORTANT:
You need to handle exceptions when message send fails and remove sending and recieving thread for device when you detect it is disconected. In my case I used well known UUID "00001101-0000-1000-8000-00805f9b34fb". For every device.
You need to wait 3 second between atempts to connect as client because some devices has weak bluetooth hardware and it is refusing connect as client.
Bt connection is supporting up to 7 -10 connections. So you will be limited in that range. I think it is designed for extensions of main device and not for random comunication
Source: search "bluetooth programming" on google