I'm attempting to write an app that involves connecting two android devices via bluetooth.
It is my understanding that one device acts as a server, listening for incoming connections while the other acts as the client, and initializes the connection using the server's MAC address.
Consider the following:
I have my android phone in my pocket, I start working on my android tablet. I want to connect the tablet to the phone (via bluetooth) without taking the phone out of my pocket (I do not want to pull out the phone and manually start listening for incoming connections).
What would be a good way to achieve this? It seems like I would have to make the phone the server, constantly listening for connections 24/7. However, my gut says this will violently drain the battery.
Any suggestions?
You are right, you could make your phone (or your tablet) the server. But it ought not use that much battery; once you set up a server socket and start accepting connections the code simple blocks and waits for an incoming connection. In my experience I haven't found this to be too much of a battery drain (but I have no hard figures to back that up).
If there is a UI involved with the server you'll want to split out the server socket into a separate thread so as to not block UI events.
Typically phones behave this way - i.e wait for incoming connections from paired devices. Waiting / Scanning for incoming connections is less power hungry than trying to find or connect to devices in a poll mode. Many bluetooth chips have low power scan which implements power efficient scanning.
Related
I am trying to make an app, that when it sees a specific bluetooth device to connect to it and send a command and before loose that connection to send another command.
The device is standard bluetooth serial device.
Is there a way to check when i am going to loose the connection?
No unfortunately Bluetooth doesn't work this way. You are usually notified that the remote device disconnected and you can even get the disconnection reason (e.g. BT_HCI_REMOTE_USER_TERMINATED_CONNECTION), but by then it is already too late and the link between your device and the remote device is already lost. Generally speaking, the way a disconnection works is that there are empty Bluetooth packets sent back and forth between the two devices (similar to an ACK) to indicate that the link is alive. If that packet does not arrive after a certain timeout, the BLE stack throws an event to the application notifying it that the connection has been lost (i.e. a disconnection event).
If you are using Bluetooth Low Energy, and if you are in control of both devices (your one and the remote one), then you could implement additional communication on the advertising channels. This is not as efficient as performing the communication through a connection, but you can advertise this additional command upon disconnection, and the remote device would scan for this new command upon disconnection as well.
I hope this helps.
I am using the Nearby Connections API. From what I've read, one should not be discovering while simultaneously being connected to a device because this reduces bandwith and causes possible dropped connections.
However, I am building an application where each phone tries to relay any message it receives to as many other phones as possible. As such, it is best to always be discovering in order to maximizing the number of endpoints.
What is the best method for ensuring that discovery time does not overlap with actual connection time? Should I be entering discovery mode on a regular preset interval? Is there a way to store discovered devices for later (so I can connect to them after I have discovering all local devices)?
You can connect to discovered devices even after calling stopDiscovery, so one solution is to scan for a fixed duration, and then connect to the devices that were found. (Note: If you're trying to do something in the background, try to synchronize the devices by advertising on the start of the hour since discovery can drain a lot of battery.)
Alternatively, you can try to keep the devices continuously connected to each other, by forming 2~3 connections per device, and flooding the network by updating all of your connected peers, who then do the same, until everyone sees the message. (Note: Being connected drains battery, although not as much as discovery does)
I would like to minimize the need for user involvement in working with SPP medical devices. The user should only have to pair the device and then connections happen automatically when the device becomes connectable. HDP classic devices are like this and so are BTLE devices (the latter takes work on Android).
So the obvious solution is after pairing, create the RFCOMM Socket and invoke the connect() method (and perhaps all the workarounds to handle the various bugs).
However, this blocking method times out after 12 or so seconds according to the documentation so if I really want to continuously be ready for the device when it 'comes on-line', I need to do this in a while-loop until the connection succeeds.
So the question is if I do this, will this continuous 'pinging' for the device overload the system and drain the battery? Given that something like this happens for HDP implementations on Android, they must also do something like this but maybe they reduce the frequency of pinging so it isn't so resource demanding.
Does anyone have any experience with attempting to do continuous monitoring for SPP devices? Thanks!
I have used Bluetooth SPP connection for industrial devices and had a similar problem. It does not seem a good idea to have a service trying to connect all the time, as it will need to always run on the background and drain more battery.
My solution would be if possible to have the SPP medical device to ask for connection once powered to the paired device(your android), or when you try to connect to the medical device, automate the connection procedure which should take about 1-2 seconds (if you can filter the devices by their MAC address(preferably) or name in your app)
Based on the bluetooth chip in your medical device, you should have plenty of connectivity options from this end, but if not you can try to connect on demand.
I have to implement bluetooth connectivity with multiple devices(4 devices) from my android java application. App will be continuously receiving data from 2 connected BT (bluetooth) devices, the other 2 BT devices can be connected on need basis & no need to maintain continuous connection. As per the requirements, app has to run continuously for 24 to 48 hours. The device with the app installed will be dedicatedly used for the app & the app will be continuously pushing the bluetooth received data to a remote server. The connected BT devices can be disconnected & reconnected any time from the app. Also if the BT connection is lost, automatic reconnect should happen. What is the best approach to implement this?
Hi i have developed a similar app for BLE Heart rate Belts (Polar H7)
what i did (may not be the best approach but it works smoothly for me as i am able to mangae 5-7 belts at a time) is i made a service to manage the connection with multiple BLE devices
in the service i keep record of all the GATT Callbacks.
so i am using one service in backgorund to keep and mange the connections and separate GATT callbacks for each device in a list or Hashmap .
If a device disconnects or new connection needs to be established i connect/disconnect accordingly and update my record of GATT callbacks .
take a look at the Android BLE sample something similar
I have: 1) An embedded device with a Bluetooth connector that I use with BlueZ, and 2) I have an Android phone that I am writing an application on.
Goal: I want to make sure that when these two devices are near each other, they quickly detect each other and establish communication. Unfortunately, I'm running in to complications of what is feasible on Android and power efficient.
Initial Design: Originally, I've been thinking and implementing the following --
Embedded Device: Constantly in discoverable mode, creates a service with an RFCOMM server running to accept multiple connections.
Android Phone: Listen for Broadcast intents that would tell me when the embedded device (discoverable) is nearby, and then create an RFCOMM client socket to it.
The difficulty I am having with this design is that I do not get intents when I would expect them. Even if I turn the embedded device on and cycle the Android phone's Bluetooth adapter to off/on ... none of these Broadcast intents are received:
BluetoothDevice.ACTION_FOUND
BluetoothDevice.ACTION_ACL_CONNECTED
BluetoothDevice.ACTION_BOND_STATE_CHANGED
The only thing that seems to work is to periodically either have the phone try to connect to the Bluetooth device's RFCOMM socket, or to periodically trigger Bluetooth scans (both power inefficient). This will trigger ACTION_FOUND and ACTION_ACL_CONNECTED. If i shutdown the embedded device, I will receive ACTION_ACL_DISCONNECTED. The issue, again, is that none of these are received if I do not explicitly have the phone try to initiate a socket connection. This is bad for power efficiency on the phone.
Do I have this logic backwards? Should the embedded device keep track of Bluetooth MAC addresses that it has paired with and be the RFCOMM client, whereas the Android application creates a service and is the RFCOMM server just hanging around and waiting for a connection? This seems logically backwards, though... I wouldn't think the Android phone would create a service or be the server to make this happen.
If I go in to my car, it almost immediately manages to establish a connection with my phone. So, I know this is possible!
The concrete questions I have are two-fold: 1) Is there something I am doing wrong with my "initial design" to make it more effective, and 2) Is the 2nd logic I propose what things like cars use to establish quick communication and poll frequently? (since the battery power of the car is not a concern...)