Posts tagged Development

I’ve been tinkering around with the Android SDK for a while and I find myself liking it more and more, despite the fact that the visual editor for views is still somewhat lacking. I even have an update ready for DroidPartridge! That is still being tested and the UI being ‘jazzed up’ a little more.

Anyway I was asked to write some code for Android to communicate with a bluetooth device that sends data via OBEX Push. Now the problem was despite Android apparently having the bluetooth profiles to support this, the device always signaled failure when trying to push a file over to the phone. The device has no user interface bar a set of LEDs and a machanism to cause vibrations (Wanted to say vibrator, but I couldn’t stop giggling)

Anyway, in Android you have to register a listening BluetoothServerSocket with the UUID (The Java GUID for you Microsoft people) of the service that you are listening for and an arbitrary name that is then put in to the local SDP database and used to compare with incoming connections. This is similar but slightly different to J2ME where you specify the address, what mode it will be operating in and it if times out, which is all taken care of by Android to avoid conflicts and instead, you just tell Android what to listen out for and pass you a BluetoothSocket back once a matching connection has been found.

mBluetoothAdapter.listenUsingRfcommWithServiceRecord(serviceName, uuidofService);

Now whilst the Android documentation is very good and in depth, it didn’t inform me or even point to a resource that specified which UUID I should use for listening for a particular protocol, so in this instance I was going to emulate OBEX over SPP (Serial Port Protocol/Profile) which meant listening for an incoming SPP connection.

I spent hours and hours running around in circles in Google’s search results reading the same thing mirrored over several sites (which was increasing the profanity by an order of magnitude each time I encountered a mirror site) until I eventually stumbled across the answer which would return a BluetoothSocket when a connection was attempted. I almost wept.

So to listen for incoming SPP connections on Android you need to specify the following UUID;

00001101-0000-1000-8000-00805F9B34FB

and the example snippet:

mBluetoothAdapter.listenUsingRfcommWithServiceRecord(serviceName, UUID.fromString("00001101-0000-1000-8000-00805F9B34FB");

So when you call the blocking method:

BluetoothSocket connection = mBluetoothServerSocket.accept();

you get a BluetoothSocket back and the thread continues! Awesome eh ? Time to break out the victory smoke ?

Sadly my troubles had only begun.

The BluetoothSocket provides a standard InputStream and OutputStream for IO operations with the device, the problem was that I could read the first x bytes, formulate a response and flush it through the OutputStream and then the device would stop sending data and abort the connection. Again, profanity increased by a large amount. I spent quite a significant amount of time stepping through the code watching variables, ensuring that the response was correct and I was specifying the correct length in the headers and skipping the appropriate number of bytes. (Whilst trying to make sure that the bluetooth connection didn’t time out from the remote device’s perspective, which I can say is no mean feat.) Still no joy.

The answer it seems was simple. For some really odd reason, my responses were not being formatted correctly as I was writing variables of types short and byte to the OutputStream which for some reason were causing problems for the device to continue sending data after the initial connect op codes were sent. Wrapping the input and output streams with their respective DataInputStream and DataOutputStream classes allowed me to use the writeByte() and writeShort() methods which seemed to have corrected the problem. The device would now no longer disconnect after sending my response back.

So anyway, those were my Android bluetooth woes in a nutshell, the UUID problem was the most heartbreaking as it would had been fairly simple if there was some documentation on which UUID was for a particular profile. Part of this post is for reference for this UUID in the event that someone else needs the information and doesn’t have to spend a long time looking for it. Enjoy!

Note: The mBluetoothAdapter is an instance of the BluetoothAdapter class which can be instantised by Android using the following documentation.