How should I manage Bluetooth connections in Android?

Question

Q. What are your best practices in managing bluetooth connectivity?

I've read the android bluetooth guide & many bluetooth connectivity tutorials. Not helpful with encapsulation-design nor best practices.

• When should I open/close the connection?
• Is the "connection" with a single bluetooth device called a "socket" connection?
• Can a single connection send data while listening? (...or between listening states).

I've never coded connectivity with external devices before. It took two weeks for me to wrap my head around the code that scans for near-by bluetooth devices and throw them into a ListView. Listeners, Broadcasts, and Adapters!

My project will be printing 1-40 receipts every 15 minutes on a bluetooth receipt printer. At the moment, security is not an issue. On the same connection, it will also be receiving data (sending & receiving simultaneously does not appear to be necessary but would be useful). I'm not yet sure how the devices are configured on this single dongle device but I would guess the devices are connected via USB controller to the dongle.

So far, I have 1 object to manage a single I/O connection. Staticly I open an activity to select a connection (to later save the label , mac , and pin in the database). Based on tutorials, I have "open", "listen", "send", and "close" methods. What confuses me is "how" to use these functions. Can I leave a connection open all day (10hrs) and use it every 3mins? Should I open/close the connection when sending or requesting data? Where would I detect the need to reconnect?

Answer 1

sorry for the short answer, but from my practice with the Bluetooth API, I have found that this video describe the things very good (totally personal opinion...)

Video 1

In addition this is useful when you do NOT have any previous experience

Tutorial

And as last check out this question in stackoverflow it has a bunch of good references and examples!!

Again sorry for the shortage, but I believe that if you check these out at least most of your questions and concerns will become answered!

:)

---

EDIT

---

So, let me be a bit more descriptive and share some of my experience.

I have written an App that communicates with BLE device that has 3 functions

• double sided event driven button (push the button on phone -> event is fired to the device; push the button on the BLE device -> event is fired to the phone)

• send request from phone -> BLE device answers with current battery percentage

• continuously reading strength signal (as aprox. distance) between the phone and the BLE device

---

So far so good, now the things is that the basic approach is:

1. Search for BLE devices (bluetooth search or "discovery" of nearby bluetooth devices)

   • Here you will need android permissions!

2. Choose the device you want to connect to

   • To differ the devices (maybe there are a lot around you :) ) you can use BLE device's name or UUID or ... best - use the name ;)

3. After both devices connect to each other you can then start the Gatt communication. The approach with state machine is a little too much overkill for me. But anyway the communication is done through bytes (in my case...)

4. In one of the videos/resources there was something specific and VERY HELPFUL at least for me! To be honest I don't remember it exactly, but the idea was that before any communication it's RECOMMENDED to read/get all the options from the BLE device or something similar...

   • Maybe it was something like discoverOptions() or something like that

5. Great thing will be to know your device "communication codes" or at least I call them that way.

   • Check this link for example: Link ** Now you can see there are tables with the USEFUL INFO! Eg if you want to read the battery level you navigate to this page and find that in order to read the battery, the service name is UUID XXXXX and you need to send 0x01 to the BLE device and it will "answer" to your call with some data which is again in bytes.

---

I really hope that this is somehow helpful!

PLEASE NOTE This is strictly coming from my experience and there could be some mismatches or wrong terms, but that's how I personally see the things and because my project was long ago, I don't remember most of the things exactly.

Answer 2

IMPORTANT:

This is only a summery of STUCI's provided links above. He has since updated his answer and I have not updated/edited this summery. Topics in my summery are not explanatory but provided for reference and help in generating specific questions.

Original Post...

Thank you Stuci! Some of that was helpful:- some not. I thought it best to collect my thoughts and see what has been explained and if anything hasn't.

(I can't post this much in a comment tho, sorry)

PLEASE CALL ME ON ANYTHING THAT IS INCORRECT.

Video of Bluetooth LE

(Covers a bunch of random things)

While I "dont-like" videos of code:- I watched it because it was recommended ... and I am glad I did. While not very helpful it did introduce some concepts I was unaware of. Since I am targeting old android devices (v8+) the LE features are inconsequential.

• Pushing Data: [Depending on the source feature-set], one does not need to continually pull data (ex. with a temperature sensor) but some devices can "push" it to the device on change. Seems to use the 'advertisement" design concept.
• UUIDs define Services and/or Characteristics of the connected device.
• Possibility to write configuration on (to) connected devices.
• Characteristics which seem to be simply "settings" that can be assigned over bluetooth. Not sure if this (~19mins) applies to non-gatt connectoins but seems similar to the state-machine that controls
• Advertisements which seem to be the "metadata" regarding the devices current state or config (~24mins). Again, not sure if this even applies to non LE Bluetooth.

Leaving Connections Open

Bluetooth connections can indeed remain open; starting at the point which the "startActivityForResult(...) method is successfully called. Two basic things affect whether or not one would want to maintain an open connection:

1. Understand the power consumption.
   • Having the adapter active simply consumes additional power. If one can keep the adapter shut-off while it is not "absolutely-needed" will mearly save battery power.
2. Accidental disconnects are managed.
   • Other than leaving the connection continually connected, one could disconnect & reconnect regularly at specified intervals to ensure a connection is up.
   • In the thread(s) used for I/O, one could check for a disconnect and reconnect (possibly starting a new thread).

I/O Streams pr Connection

A single connection can indeed "have" simultaneous Input & Output streams. I

Since it was suggested, I re-read Android's Bluetooth Guide and under "managing a connection" (talking about a single socket) I noticed this...

1. Get the InputStream and OutputStream that handle transmissions through the socket, via getInputStream() and getOutputStream(), respectively.
2. Read and write data to the streams with read(byte[]) and write(byte[]).

...but continues with noting that read & write block each other. Something I still need to look further into. It seems like you cant I/O simultaneously on the same socket???

Max Connections

I also looked into the max connection issue Stuci added and found no documentation on the Android-side. It might exist, I cant find it. However, most people seem to agree that there is a limitation (that could be as low as 4) imposed by whatever hardware you are coding for. Some notable links: - How many devices we can pair via Bluetooth of BLE to Android? - How many maximum device can we pair via Bluetooth to android device at a time? - https://groups.google.com/forum/#!topic/android-developers/adeBD275u30