I’ve been doing some work with Bluetooth on Android, specifically using RFCOMM to send data between an Android phone and another Bluetooth device. The mechanics of using RFCOMM on Android are pretty straightforward, and there weren’t any big surprises. But there were a couple of things that I bumped into that are worth pointing out. These aren’t defects. These are just things that, if you miss them or do them wrong, will cause you problems.
Remember to Close the Server Socket
Early on, I ran into a problem where I could make one reliable connection between the devices, and then any subsequent connections would never occur (they waited basically forever for an accept that never finished). What I found out was that it is necessary to call close on the BluetoothServerSocket after you’ve closed the BluetoothSocket used for the actual communications. Once I did this, I could reliably get another connection.
UUID’s Aren’t Always Fun
One of the issues that I was running into is that the other device doesn’t have a way to provide 128-bit UUID’s. It can only provide 16-bit UUID’s. I also couldn’t find a way in Android to provide a 16-bit UUID: the only acceptable UUID size is 128-bit. What I did find, though, was that if I used the standard Bluetooth UUID and substituted the “16-bit” part in the right location, then the other device would connect with no problem.
The standard UUID for the Serial Port Profile is 00001101-0000-1000-8000-00805F9B34FB. When you specify the 16-bit UUID for SPP, then you specify 1101. Notice how that sequence appears in the first part of the full 128-bit UUID? Well, if you put your own 4 hex digits in place of 1101, it appears that a device that only supports 16-bit UUID’s will find the service (it looks like Android up-converts the 16-bit UUID to a 128-bit UUID and assumes the rest is part of the standard Bluetooth UUID form). So, if you wanted to use 9999 as your UUID on the 16-bit only device, then you would use 00009999-0000-1000-8000-00805F9B34FB on the Android side.
Is this “good form”? So far, it isn’t clear. If you stick to numbers that aren’t reserved by Bluetooth, then you are probably okay, but as with anything, caveat emptor, your mileage may vary, batteries not included, see dealer for details. My only claim here is that it works for me.
Watch Your Power Usage
When an app is waiting on an accept, it burns up a lot of power. A battery that should normally last a few days on standby can be emptied in a matter of a couple of hours if you leave the app running (or a service running) actively waiting on an accept. When you are designing your app, you will want to be very careful and be aware that active accepts can be fairly expensive power-wise. An actual connection doesn’t seem to be too onerous (since SPP underlies a lot of other services like Headset, it appears that once a connection is set up, the power levels on the radio are more closely controlled). But waiting on accept appears to use a lot of juice.