I have an application that is talking over Bluetooth to a server on a beagle board. I have created the server code in C++ using bluez and an Android app on a tablet.
The issue I am seeing is when the server application is not up, I expect the tablet to keep trying to connect. Though after a random number of attempts the tablet will crash and actually restart on me. The server application may not be running, but the OS is running and Bluetooth is technically on. Its just the listen port is not listening since the server application is not running.
The 2 devices are bonded and can connect no problem when everything is running. The use-case is when the server is not running and the tablet is trying to connected via the communications loop. It will obviously never connect since the server application is not running which is great. I just don’t understand why it locks up the tablet after retrying for a while.
The number of retries have been anywhere from 40, to 300 to 1000 before the tablet freezes. It’s not a memory leak as I can see in logcat there is 10% free just before it crashes. I am closing all the sockets and streams and opening everything fresh on each retry connection attempt so I don’t see any of that being an issue.
Just before I connect I check to make sure discovery is not running as I am connecting to the bonded device.
So I think the error I get on the connection failed is just because the server is not running and thus there is no listen port open. This is valid and expected since I’m testing an error case. I just need help on why failing connection too many times will force the tablet to restart on it’s own.
D UI_BT: stateMachineCurrent: Connecting
E BluetoothEventLoop.cpp: onDiscoverServicesResult: D-Bus error: org.bluez.Error.InProgress (Discover in progress)
D BluetoothService: Cleaning up failed UUID channel lookup: 00:02:76:24:C2:8F 00001101-0000-1000-8000-00805f9b34fb
D UI_BT: FAILED Connection (95) – java.io.IOException: Service discovery failed
Anybody have an idea what could be wrong? Thanks.
EDIT:
Here is some more information. I decided to see if it has something to do with Bluetooth being on with no application running on the beagle board vs bluetooth being off all together. I had it retry all night, 6.5 million retries and no crash on the tablet which is great.
Now I turn on bluetooth and start my application and I expect everything to start communicating. I feel this is a standard use case for a communications link. Well once it all starts talking the tablet crashes like before.
Here is the some of the logcat output…
09-13 09:23:28.600 7581 7590 D UI_BT : stateMachineCurrent: Connecting
09-13 09:23:28.600 5419 5670 D BluetoothService: updateDeviceServiceChannelCache(00:02:76:24:C2:8F)
09-13 09:23:28.620 5875 5875 V BluetoothEventManager: Received android.bleutooth.device.action.UUID
09-13 09:23:28.620 5875 5875 V BluetoothEventManager: Received android.bleutooth.device.action.UUID
09-13 09:23:28.620 5875 5875 V BluetoothEventManager: Received android.bleutooth.device.action.UUID
09-13 09:23:28.620 5875 5875 V BluetoothEventManager: Received android.bleutooth.device.action.UUID
09-13 09:23:28.620 5875 5875 V BluetoothEventManager: Received android.bleutooth.device.action.UUID
09-13 09:23:28.620 5875 5875 V BluetoothEventManager: Received android.bleutooth.device.action.UUID
09-13 09:23:28.620 5875 5875 V BluetoothEventManager: Received android.bleutooth.device.action.UUID
09-13 09:23:28.620 5875 5875 V BluetoothEventManager: Received android.bleutooth.device.action.UUID
09-13 09:23:28.620 5875 5875 V BluetoothEventManager: Received android.bleutooth.device.action.UUID
09-13 09:23:28.620 5875 5875 V BluetoothEventManager: Received android.bleutooth.device.action.UUID
09-13 09:23:28.620 5875 5875 V BluetoothEventManager: Received android.bleutooth.device.action.UUID
09-13 09:23:28.620 5875 5875 V BluetoothEventManager: Received android.bleutooth.device.action.UUID
09-13 09:23:28.620 5875 5875 V BluetoothEventManager: Received android.bleutooth.device.action.UUID
09-13 09:23:28.620 5875 5875 V BluetoothEventManager: Received android.bleutooth.device.action.UUID
09-13 09:23:28.620 5875 5875 V BluetoothEventManager: Received android.bleutooth.device.action.UUID
09-13 09:23:28.620 5875 5875 V BluetoothEventManager: Received android.bleutooth.device.action.UUID
09-13 09:23:28.620 5875 5875 V BluetoothEventManager: Received android.bleutooth.device.action.UUID
09-13 09:23:28.620 5875 5875 V BluetoothEventManager: Received android.bleutooth.device.action.UUID
09-13 09:23:28.620 5875 5875 V BluetoothEventManager: Received android.bleutooth.device.action.UUID
09-13 09:23:28.620 5875 5875 V BluetoothEventManager: Received android.bleutooth.device.action.UUID
09-13 09:23:28.620 5875 5875 V BluetoothEventManager: Received android.bleutooth.device.action.UUID
09-13 09:23:28.620 5875 5875 V BluetoothEventManager: Received android.bleutooth.device.action.UUID
09-13 09:23:28.620 5875 5875 V BluetoothEventManager: Received android.bleutooth.device.action.UUID
09-13 09:23:28.620 5875 5875 V BluetoothEventManager: Received android.bleutooth.device.action.UUID
09-13 09:23:28.620 5875 5875 V BluetoothEventManager: Received android.bleutooth.device.action.UUID
09-13 09:23:28.620 5875 5875 V BluetoothEventManager: Received android.bleutooth.device.action.UUID
09-13 09:23:28.620 5875 5875 V BluetoothEventManager: Received android.bleutooth.device.action.UUID
09-13 09:23:28.620 5875 5875 V BluetoothEventManager: Received android.bleutooth.device.action.UUID
09-13 09:23:28.620 5875 5875 V BluetoothEventManager: Received android.bleutooth.device.action.UUID
09-13 09:23:28.620 5875 5875 V BluetoothEventManager: Received android.bleutooth.device.action.UUID
09-13 09:23:28.680 5875 5878 D dalvikvm: GC_CONCURRENT freed 467K, 14% free 6435K/7431K, paused 2ms+24ms
So I’m not sure why I received so many UUID action intents. Though I think the root cause of my issue may have something to do with the updateDeviceServiceChannelCache() call? I’m not sure what the answer is, but this internal call is messing up somehow after a prolonged reboot period? I know this method is executed as a result of my code calling the connect routine. So i don’t call it directly.
Hopefully this added information will help in somebody pointing me towards a resolution.
Thanks!
It looks like the issues was using createRfcommSocketToServiceRecord() for some reason this method doesn’t like to fail over and over when there is not connection.
Instead I used reflection and createRfcommSocket() to get my issue resolved.