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...
Related
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.
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.
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
I have two Android devices. One is acting as a server and the other as a client. The client connects to the server and requests a file - this is done in one thread on the client and one thread on the server so that both can continue doing what they want.
The client then attempts to connect to the server again to request another file. Right now I am getting a java.io.IOException: Device or resource busy when attempting to connect (socket.connect()). Is it because Bluetooth (on Android) only allows one channel between two devices? (if it were another device it would work but if it is the same it doesn't ?) Note that both attempts are made with the same service name and UUID.
Even if the error is specific to my code, I would like to know if this is the case or not.
System: android 2.2.1 communicating with the bluecove bluetooth library.
Definitely not with the same UUID(universally UNIQUE Identifier).
Reference for that was taken from here
Maybe with more than one. You can connect multiple devices in the Server/Client style, you can try to set one of the devices as a server and start several clients on the other. My first guess would be to start several client threads, but you might have to find a way to change the MAC address for each of them.
Here you can find another discussion about how to change your mac address, but only works in rooted devices. I can't find anything else for non rooted ones. No idea on how to do this programmatically but it might give you a start.
Here there is a discussion about connecting several clients at the same time in a server. I got there from this question. ( I think this might be your closest shot)
Here you have a discussion about peer-to-peer networks.
AFAIK, multiple connectivity is not possible in case of Bluetooth Connection. Bluetooth is Connectivity API is by default Synchronized so only one connection at a time is possible. So you can not perform multiple connections.
However it can be possible in another way like making one connection , performing 2 seconds operation on it and then creating another connection and performing 2 seconds operations like in normal multitasking operating system happens.
I was reading this
http://developer.android.com/guide/topics/wireless/bluetooth.html#QueryingPairedDevices
which is allot of help on how to pair,connect to a bluetooth device.
I have a situation where I have several BT devices that are in Non-Discover mode always. I know the MAC and the PIN of these devices. IS there a way in Android Dev to manually add devices to the PAIRED list so i can just use the connect as a client.
I understand this maual is written allot for V3. i think i will need to do this on 2.0 ; 2.1- has anybody done this before?
Basically these devices I want to connect to are power saving modules I used pre built BT modules to monitor daylight, another one humidity, etc.. every 3hrs or when interrupted and runs of a single battery for months. So turning off divcory on server saves immense power and prevents other people trying to connect and waste battery.
Not sure what you mean by "manually": Do you mean "manually" as in GUI/user interaction, or "manually" as "I do it in my own application code"?
Some suggestions though:
If you can make your BT devices discoverable at all, you could do it this way:
Make your BT device discoverable
Let Android search for and find the device and then initiate a connection
Android will ask for the PIN for pairing with the device; enter the PIN.
Once pairing was successful, Android stores the pairing information for future use, so that you can
Make your BT device invisible again.
From then on your app should be able to connect to the BT device at any time without further pairing operations.
If the said is not an option for you, maybe you want to go another way:
In current Android versions there are different API routines implemented which are neither documented nor exposed in the normal SDK. A hack kind of solution may be to use some of these "hidden" ("#hide"...) APIs, either via reflection or via modification of your SDK installation.
But be aware that this is always a hack and it may work on a specific device with a specific version of Android and is likely to break your app on another device and/or any other Android version.
Having said that, here comes some reference:
Example of how to access "hidden" bluetooth API.
Then, have a look at the source code for android.bluetooth.BluetoothDevice, e.g. here.
In there, public boolean createBond(){...} may do what you want.