Android 2.0 bluetooth sockets question

[Chen Ganir]

Hi.

I've read about Bluetooth Sockets and Bluetooth Server Sockets here :
http://developer.android.com/reference/android/bluetooth/BluetoothServerSocket.html
http://developer.android.com/reference/android/bluetooth/BluetoothSocket.html

I understand the relationships between the classes, and i know how to
create them.

however, there seem to be some unresolved issues, which are :
1. When creating a BluetoothServerSocket - is it ready for
connections? What happens to an incoming connection before accept is
executed?
2. Can multiple incoming connections exist on the same
BluetoothServerSocket?
3. Is there a limit for BluetoothSockets and BluetoothServerSocket
instances?
4. Can the RFCOMM created for a listening BluetoothServerSocket
receive more than one connection?
5. What happens to incoming connections after returning from accept()
and calling it back again?
6. How ia the SDPrecord database mainained by Android/Bluez?
7. Is there a Queue for incoming connections? What happens to the
second incoming connection?
8. after incoking accept - what happens to the server socket? Does it
create a new RFCOMM channel? Or is it using the same RFCOMM channel
for all connections to the same UUID?
9.the SDK states that consecutive accept calls will get all incoming
connections - does this mean that the BluetoothSocket in server mode
supports multiple connections? How about multiple connections from the
same host? (This is a problem due to the RFCOM DLC).

Thanks,
Chen Ganir

[Nick Pelly]

On Thu, Nov 12, 2009 at 1:17 PM, Chen Ganir <chen....@gmail.com> wrote:
> Hi.
>
> I've read about Bluetooth Sockets and Bluetooth Server Sockets here :
> http://developer.android.com/reference/android/bluetooth/BluetoothServerSocket.html
> http://developer.android.com/reference/android/bluetooth/BluetoothSocket.html
>
> I understand the relationships between the classes, and i know how to
> create them.
>
> however, there seem to be some unresolved issues, which are :
> 1. When creating a BluetoothServerSocket - is it ready for
> connections?

Yes, it is listening.

> What happens to an incoming connection before accept is
> executed?

It will probably timeout if accept() is not called quickly enough. Try it out.

> 2. Can multiple incoming connections exist on the same
> BluetoothServerSocket?

No. RFCOMM only allows once connection per channel at a time. However
you can accept() a second connection after the first has closed.

> 3. Is there a limit for BluetoothSockets and BluetoothServerSocket
> instances?

No, but there are only 30 RFCOMM channels.

> 4. Can the RFCOMM created for a listening BluetoothServerSocket
> receive more than one connection?

See (3).

> 5. What happens to incoming connections after returning from accept()
> and calling it back again?

calling accept() again? It should block until a second incoming
connection (which can only happen after the first connection is
closed).

> 6. How ia the SDPrecord database mainained by Android/Bluez?

It's maintained by Bluez's bluetoothd daemon.

> 7. Is there a Queue for incoming connections? What happens to the
> second incoming connection?

See (3).

> 8. after incoking accept - what happens to the server socket? Does it
> create a new RFCOMM channel? Or is it using the same RFCOMM channel
> for all connections to the same UUID?

Same RFCOMM channel.

> 9.the SDK states that consecutive accept calls will get all incoming
> connections - does this mean that the BluetoothSocket in server mode
> supports multiple connections? How about multiple connections from the
> same host? (This is a problem due to the RFCOM DLC).

See (3).

>
> Thanks,
> Chen Ganir
>
> --
>
> You received this message because you are subscribed to the Google Groups "android-platform" group.
> To post to this group, send email to android-...@googlegroups.com.
> To unsubscribe from this group, send email to android-platfo...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/android-platform?hl=.
>
>
>

[Chen Ganir]

Hi Nick.

thank you very much for your response. This solved the unclarity of
the API. Will it be possible to modify the current API documentation
to reflect these important notes ?

Thanks,
Chen Ganir.


On Nov 14, 2:30 am, Nick Pelly <npe...@google.com> wrote:

> On Thu, Nov 12, 2009 at 1:17 PM, Chen Ganir <chen.ga...@gmail.com> wrote:
> > Hi.
>
> > I've read about Bluetooth Sockets and Bluetooth Server Sockets here :

> >http://developer.android.com/reference/android/bluetooth/BluetoothSer...
> >http://developer.android.com/reference/android/bluetooth/BluetoothSoc...

[Nick Pelly]

Sure, send a patch

[Chen Ganir]

Hey Nick.

What do you mean a patch? I talked about changing the documentation on
the Android dev site. There is no code change involved here.

I have another question.

I saw a lot of "hidden" API related Bluetooth, in BluetoothDevice,
BluetoothAdapter, BluetoothSocket and BluetoothServerSocket.
SCO and L2CAP Channels are also available and can be created - is
there a reason for that? Does Android provide any use cases for this
kind of channels? Does Android currently have any implementation
depending on this API for L2CAP or SCO channels?

In BluetoothAdapter - create a listening Server socket using a user
defined RFCOMM channel - isn't this API dangerous? RFCOMM channels
should be managed, and you can not guarantee that a user will use the
RFCommChannelPicker.

BluetoothSocket can be created by utilizing an existing file
descriptor (obtained from the new connected socket) which is then used
to create a new socket (Native Bluetooth code). Why is this done? Is
this API used elsewhere?

Is there any other part of Android currently using the BluetoothSocket
in it's RFCOMM scnario or L2CAP/SCO? Are there any plans for adding
such usage?

Any general thoughts and comments on current and future Android/Bluez
combination and roadmap will be appreciated.

Thanks,
Chen Ganir.

On Nov 15, 5:59 pm, Nick Pelly <npe...@google.com> wrote:
> Sure, send a patch
>

[Nick Pelly]

On Sun, Nov 15, 2009 at 10:33 AM, Chen Ganir <chen....@gmail.com> wrote:
> Hey Nick.
>
> What do you mean a patch? I talked about changing the documentation on
> the Android dev site. There is no code change involved here.

The documentation is generated from javadoc, which is in the code.

>
> I have another question.
>
> I saw a lot of "hidden" API related Bluetooth, in BluetoothDevice,
> BluetoothAdapter, BluetoothSocket and BluetoothServerSocket.
> SCO and L2CAP Channels are also available and can be created - is
> there a reason for that? Does Android provide any use cases for this
> kind of channels? Does Android currently have any implementation
> depending on this API for L2CAP or SCO channels?

Exposing a function in the API means that we have committed to that
interface and implementation and we can never change it. So its not a
decision we take lightly. SCO and L2CAP were not exposed in the SDK
because for most use cases they are not necessary, and they can more
easily disrupt other Bluetooth links, so we would have to expose them
carefully.

You can see which @hide API's are in use by searching our codebase -
it's open source after all.

>
> In BluetoothAdapter - create a listening Server socket using a user
> defined RFCOMM channel - isn't this API dangerous?

Yes, that's why its marked @hide.

> RFCOMM channels
> should be managed, and you can not guarantee that a user will use the
> RFCommChannelPicker.
>
> BluetoothSocket can be created by utilizing an existing file
> descriptor (obtained from the new connected socket) which is then used
> to create a new socket (Native Bluetooth code). Why is this done? Is
> this API used elsewhere?

This is used internally in the accept() code path. You can search our
codebase to answer questions like these.