When does android show a pairing dialog when using insecure RFCOMM bluetooth sockets?

Question

I am trying to connect two unpaired android devices via Bluetooth for P2P networking purposes. MitM protection is not required. Android has the createInsecureRfcommSocketToServiceRecord and listenUsingInsecureRfcommWithServiceRecord for this (since API level 10), which works perfectly on modern devices. However, on a Galaxy Ace (Android 2.3.3 = API level 10, connecting with a Galaxy Nexus), it creates a pairing dialog. This happens both on incoming and outgoing connections. (Update: Updating the Galaxy Ace to Android 2.3.6 apparently fixes the problem. Is there a specific Android version that always/never does this?)

After the pairing is accepted, the connection works. For this reason, I think this is not related to Issue 40101: createInsecureRfcommSocketToServiceRecord causes pairing dialog on Android 4.2 which should only happen if the service record does not exist.

I assume this dialog cannot be avoided on devices where it comes up (if it can, explaining how to do this is a valid answer). For this reason, I would like to know when such a dialog is brought up. I did not find anything in the Android Java source (it goes native pretty quickly). I doubt it has anything to do with the Bluetooth version, since the Ace has Bluetooth 2.1 which is supposed to support the required "just works" connections.

If there is anything that would allow me to detect whether a device will support connections without popping the dialog, or if it was clearly fixed to a certain android version, that would immensely help me.

Also, I am looking for a way to easily exclude such devices.

Smitherman

For insecure connection i.e., if you use createInsecureRfcommSocketToServiceRecord and listenUsingInsecureRfcommWithServiceRecord, what UUID did you use? – Spiers

@krisDrOid: A randomly generated custom one. – Smitherman

Answer 1

Currently I have the same problem as you. I've developed an application to exchange messages between BT terminals and I'm testing it on different phones ( I have S3, S2, S plus, Nexus One and Galaxy Y) to analize the behaviour. Phones have this specs:

• Samsung S2 : Custom ROM (Android v4.2.1) - Rooted
• Samsung S3 : Stock ROM (Android v4.1.2)
• Samsung S+ : Custom ROM (Android v4.1.2) - Rooted
• Samsung GY : Custom ROM (Android v2.3.6) - Rooted
• Nexus One : Stock ROM (Android v2.3.6) - Rooted

As far i can tell you from my experience, S2 and S3 after some time start to show the pairing dialog even if they are already paired and exchanging data. This happens all the time I include one of this two phones in my testbed, others are working fine and never ask for pairing ( expecially Nexus One that has a flawless behaviour).

I have made long running tests (from 4 to 6 hours) and I still can't figure out why this phones ask for pairing sometimes after 3 hours.. sometimes after 10 minutes.

The only thing that i would like to point you out is that even if u are using insecure connection you could still be asked for human interaction for pairing. Give a look at that (taken from http://en.wikipedia.org/wiki/Bluetooth) :

Just works: As implied by the name, this method just works. No user interaction is required; however, a device may prompt the user to confirm the pairing process. This method is typically used by headsets with very limited IO capabilities, and is more secure than the fixed PIN mechanism which is typically used for legacy pairing by this set of limited devices. This method provides no man in the middle (MITM) protection.

Polygynous

Thanks. Certain Android 4.x versions are said to have a bug that will trigger such a dialog if the other device doesn't have the appropriate service running/listening - see this report. You may want to check if your listener is staying active. – Smitherman

Thanks for the information but yes, my service is always running :). Maybe I found where the problem lies, now I'm working on it. I'll update my post if my solution works. – Polygynous

Any update on this? I'm assuming it's just a bug in Lollipop, but if you've found a workaround or a source of the issue in your app, I'd be very interested to hear about it. – Gavage