Android Bluetooth IOException:connection refused

Question

Alright here's the deal. I got two Galaxy Nexus phones both with bluetooth enabled.

I've written a bluetooth connection management app that I use for device discovery and connectivity. It also outputs all the available UUIDs the devices can support.

Looking from http://www.bluetooth.org/Technical/AssignedNumbers/service_discovery.htm the following standard UUIDs are exposed from Galaxy Nexus devices.

• 0x1116 - NAP
• 0x112f - PBAP (Phonebook Access Profile)
• 0x111f - HFP (Hands free)
• 0x1105 - OPP (Object Push Profile)
• 0x1112 - HSP (Headset Profile)
• 0x110c - AVRCP
• 0x110a - A2DP

I am trying to connect via the OPP profile (UUID 00001105-0000-1000-8000-00805F9B34FB) and push objects (files) between the devices. I've gone though the entire Android API documentation on how to discover, pair/bond (threading etc.) and manage all bluetooth connections. I've managed to successfully connect and talk to a legacy board device via the SPP (0x1101) profile.

However, when I try to use socket.connect() between the two galaxy nexus phones, the pairing dialog shows up and I click Pair button on both devices. After that, I immediately get a Connection Refused IOException. Note that after pairing has occurred once I never get asked again which makes sense since the secure link is cached.

If I can't connect to these standard profiles using these standard UUIDs why are they exposed? How can I connect from my app to any of these profiles and interact with them? Is it because my app is not somehow trusted? What's weird is that even the Share functionality on Android does not work at all either. Is this something completely broken on Android?

Please avoid giving me hints to use the "well known UUID SPP one 0x1101" like the docs say. This is not what I want. I have a fairly good understanding of how this stuff works and I am looking for a real solution or explanation of the problem.

I've seen the typical "reflection" solution but I do not understand why is this still a problem on Android? Why do people use reflection to make this work? Can we file a bug on Android to fix this?

If those UUIDs are standard any app should be able to connect and interact with them. Why is this an issue and why do I get this exception?

Thanks in advance.

UPDATE

So for some reason the object push in the Android system started working. I actually attempted to connect via my app and it was not working. Then, I went to the Contacts app and tried to share a contact which magically worked. Then, I went back to my app and it now it works...wow. That is very weird and there must be an explanation to this.

Waistcloth

you set up the right permissions? developer.android.com/guide/topics/connectivity/… – Candescent

@Candescent Of course he did. dnkoutso: How exactly are you openning the socket? Could you try re-pairing, that is - unpair then pair again. Btw, is it 2 tier? – Stefansson

@iccthedral, what do you mean by 2 tier? I often go into the real Settings app on both devices and remove the pairing. Once I call socket.connect() again then it prompts me with the pairing dialog and the passkey number filled in. Unfortunately, right after I get the "Connection Refused" IOException. – Waistcloth

thanks for the update! I have found with my two Bluetooth sharing apps that the first pairing is always tricky. I'm glad to know it's not just me. Also please accept or up-vote if you find answers helpful :) – Vilma

Answer 1

I ran into this same issue and managed to find a solution that worked for me.

In my case I using three different test devices (Nexus 5, Galaxy S4, Note 2) and for some reason, the Note 2 wouldn't connect to my Bluetooth module yet the other two would.

The reasoning I've found is that Bluetooth drivers vary, and slightly different connection methods are needed to create a connection between different devices.

The three methods I use are called 'Secure', 'Insecure' and 'Reflection method'/'hax'.

            switch(connType)
            {
            case Secure:
                tmpSocket = device.createRfcommSocketToServiceRecord(_uuid);
                break;

            case Insecure:
                tmpSocket = device.createInsecureRfcommSocketToServiceRecord(_uuid);
                break;

            case Hax:
                Method createSocket = device.getClass().getMethod("createRfcommSocket", new Class[] {int.class});
                tmpSocket = (BluetoothSocket)createSocket.invoke(device, Integer.valueOf(1));   
                break;
            } 

In my case, the Secure mode worked for both the Nexus 5 and Galaxy S4 however it didn't work for the Note 2.

After some testing I discovered the Note 2 only works using 'Insecure' mode, so to cater to this, I basically attempt a connection and cycle through the different modes if necessary. When attempting a different connection mode I simply prompt 'retrying connection'. So, if the connection fails using secure, then I will attempt using Insecure and then using the reflection method.

I haven't run into the case where one of these three methods haven't worked.

Annelieseannelise

Answer 2

Have you tried using a nonstandard profile? i.e. a custom UUID just for your app. This will also help you know your are (most likely) only connecting to your own app rather than some other app that is registered with the same profile.

From my experience, Bluetooth pairing is very buggy for the first pair attempt. However, using a custom UUID helps this somewhat.

The reflection method (I think) was originally an attempt to fix a bug with a specific device, however I think some people found success in using it elsewhere as well. The device was called the Spica or something similar.

As one of the comments also posted, I would also try connecting again after failing.

Basically write code that plans to fail the first attempt, but then the code tries to connect again in 5 seconds if there was a failure.

These are imperfect solutions but Bluetooth implementation on Android is also imperfect (IMHO). Hope that helps

EDIT

Based on the question update and comments:

I agree something is definitely buggy. Part of the problem I think is the BT drivers vary and each has a different BT stack with different quirks. I also found a question that makes use of both the reflection method AND custom UUID, AND other standard methods. This seems extreme to me but it does cover the most ground. Unfortunately as app developers we have no control over the low level stack/code/drivers.

I have found with my two Bluetooth sharing apps that the first pairing is always tricky.

I'm glad to know it's not just me.

Vilma

I have managed to make a connection with my own custom UUID. I just don't understand how these publicly Bluetooth STANDARD UUIDs are not working. They are also not working on the normal system "Sharing" on Android which is also a hint thats something is buggy in the Android code. – Waistcloth

I agree something is definitely buggy. Part of the problem I think is the BT drivers vary and each has a different BT stack with different quirks. I also found a question that makes use of both the reflection method AND custom, AND other standard methods. This seems extreme to me but it does cover the most ground. Unfortunately as app developers we have no control over the low level stack/code/drivers. – Vilma