I wanted to experiment a bit with an old bluetooth device and my smartphone. The device uses the Bluetooth 3.0's unicast connectionless mode to send data. I'd like to read this data with my smartphone, without establishing a connection. Reason? The device has a big range of about 50 meters, the smartphone only about 10 meters. I'd like to receive the data even if I am further away than 10 meters. Is it possible?
I googled on the topic and I found somewhere in the API some mysterious constants definitions "L2CAP" or so, with a comment "Unicast connectionless mode", which means, there seems to be a support for this feature. But except of those constants I found nothing - no functions, classes, methods, examples.
I would be thankful for any advice.
Unfortunately L2CAP is not supported version 4.2 onwards, there is an open issue on Android website which have more details.
Issue 58164: Support Bluetooth L2CAP
There seem to be no response on when fix will be done. I am too waiting for fix :-(
Related
I am working on an Application which needs to communicate with BLE 5 powered peripheral devices, as our requirement to use the extended advertisement packet. As we know, BLE 5 devices are completely supports background-compatibility. So when the BLE 5 device broadcasts itself in legacy mode it is getting scanned on Andorid/ iPhone devices. But when it broadcasts without legacy mode it is not getting scanned. I don't know what I am missing. I believe there is nothing to do as much on the application side as it will be handled at stack level.
Any help would be highly appreciated. Thanks in advance.
Please check the following points:
Take a bluetooth sniffer. Is your device advertising at all?
What is the advertising interval? It is compatibel with the phone? If you have a bad interval, there might be kind of aliasing issue. A good point to start the the Accessory Design Guidelines from Apple. If the inverval is longer than, lets say 500 ms it might take very long to find the device.
What kind of advertising to you send? directed / undirected ? If you send directed, the stack of the non-targed device will just irgnore the advertisement
If you have a good BLE scanner it might also show you if the advertising data is malformed. I once had the issue that all my advertisements were ignored because a length field did not mach the payload.
Do you expect public or random BLE addresses? I am not sure about this, but it may be possible to filter for either or. So if your device switches to random addresses and you filter for only public you might not see it.
I hope this is a good start for debugging for any one having the same problem.
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 have read many, many SO questions and answers about this topic but none seem to work completely. The 3 most detailed answers I have found are:
Using the Android RecognizerIntent with a bluetooth headset
Programmtically connect to bluetooth headset from android app
bluetooth pair and connect device
Which references : https://github.com/giladHaimov/BTWiz
all of which are now quite old and have had no further discussion in some time.
and the Bluetooth chat example from the sdk. - compiles and works as a text chat example, but after modification I can not get it to create a connection to any headsets.
I have followed the above 3 examples and worked through the code and customized them to my application - adding extra variable references as required. Most if not all examples seem have major errors and are only pointers. I am not asking for "you email me complete working code", but there is enough missing from all the answer that the missing part can not be felt in the dark.
I have also downloaded the HSP and HFP and SPP and RFCOMM Bluetooth specifications docs. These are even more vague. They say "create a connection".. but don't indicate how... I understand they are trying to be OS/language agnostic... but ouch!!
I am able to get as far as a broadcast receiver or listener acknowledging the creation of a new connection, but there seems to be a gap between that point and getting a functional SCO audio connection.
After creation of the connection, looking at the built in BT manager app, the headset doesn't show as connected at all.. so this must be a low level connect (ACL) and not a high level connection.
I understand that each persons approach to programming a solution is different, but the underlying issue remains the same. Some are low level and close to the OS, others have a high degree of abstraction and referencing high level objects which perform the low level work.
Is anyone able to shed some light on the necessary steps to get from an ACL connection to a functional audio connection please?
I can post code examples later if requested.
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.
I need a way to send messages between 2 android devices, 1 a phone and 1 a tablet. I'm using Java to create the app. I'm looking at servers but I can't figure out where to start. Thanks for any help :-)
P.s. Both devices would be using the same wifi connection so could I use a port to send messages
Beside the obvious solution from #dilix you could use a library like JGroups which provides automatic discovery of other devices.
The answer depends on how far away the devices are. Right next to each other (inches)? NFC. Within about 20 feet? Bluetooth. Within a hundred meters or so? Wifi Direct, which is peer to peer wireless connections. More than that? You're going to need a central server, because no carrier allows incoming TCP or UDP data- they all firewall it off. Of course all of the longer distance answers will also work for shorter distances. But different solutions here also have different security requirements.
I think you can try sockets to send\receive messages:
http://developer.android.com/reference/java/net/ServerSocket.html
http://developer.android.com/reference/java/net/Socket.html
Try to searh "android socket" and you can find some information even on the stackoverflow.