Request For Comment: Bluetooth Socket API (RFCOMM, SPP, L2CAP, SCO)

[Nick Pelly]

Hi,

There has been a lot of demand for an API to Bluetooth RFCOMM sockets (also known as Serial Port Profile).

Here is an API proposal open for comment. It also covers SCO and L2CAP sockets.

Background
BluetoothSocket and BluetoothServerSocket are modeled on java.net.Socket and java.net.ServerSocket respectively. However we cannot use Socket and ServerSocket directly because they are tightly bound to TCP sockets.

This design currently uses factory methods to create the socket objects. We are likely to switch to a Builder pattern if any more construction time options are required (L2CAP MTU?). The same builder could be used for both BluetoothSocket and BluetoothServerSocket.

InputStream and OutputStream are used for the data path.

This API is for blocking IO. Also interested to hear feedback on whether a non-blocking implementation would also be useful and why.

Are there other socket options that may be useful? L2CAP MTU for example. If so please explain the use case.

android.bluetooth.BluetoothSocket
/* Represents a connected or connecting Bluetooth socket */

public final class BluetoothSocket implements Closeable {

  /* Factory methods create a socket ready to call connect()
   * insecure variants do not require authentication or encryption,
   * and can be used with unpaired devices */
  public static BluetoothSocket createRfcommSocket(String address, int channel) throws IOException;
  public static BluetoothSocket createInsecureRfcommSocket(String address, int channel) throws IOException;

  public static BluetoothSocket createScoSocket(String address) throws IOException;
  public static BluetoothSocket createL2capSocket(String address, int psm) throws IOException;
  public static BluetoothSocket createInsecureL2capSocket(String address, int psm) throws IOException;

  /* Initiate connection and block until connected or connection
   * fails. Throws IOException on any error, including connection
   * failure. Connect() can be called repeatedly if connection
   * failed */
  public void connect() throws IOException;

  /* Close socket, and force any blocked I/O on this socket in
   * other threads to immediately throw IOException. Socket cannot
   * be reused after calling close() */

  public void close() throws IOException;

  public String getAddress();
  public InputStream getInputStream() throws IOException;

  public OutputStream getOutputStream() throws IOException;
}

android.bluetooth.BluetoothServerSocket
/* Represents a listening Bluetooth server socket */

public final class BluetoothServerSocket implements Closeable {

  /* Factory methods create a bound, listening socket.
   * Use accept() to obtain an incoming connection.
   * Insecure variants do not require authentication or encryption,
   * and can be used with unpaired devices */
  public static BluetoothServerSocket listenUsingRfcommOn(int channel) throws IOException;
  public static BluetoothServerSocket listenUsingInsecureRfcommOn(int channel) throws IOException;
  public static BluetoothServerSocket listenUsingL2capOn(int psm) throws IOException;
  public static BluetoothServerSocket listenUsingInsecureL2capOn(int psm) throws IOException;
  public static BluetoothServerSocket listenUsingSco() throws IOException;

  /* Obtain the last unaccepted incoming connection to this
   * listening socket, or block until there is an incoming
   * connection. Can be called repeatedly */
  public BluetoothSocket accept() throws IOException;
  public BluetoothSocket accept(int timeout) throws IOException;

  /* Close this socket. If accept() on this sokcet is blocked
   * in another thread it will immediately throw IOException */
  public void close() throws IOException;
}

An implementation of the above API for RFCOMM will be in the next master branch push for you to try out.

Nick

[Sumanth]

Hi Nick,

When would this be merged to the master branch?

Regards,
Sumanth

[Mike Hearn]

I appreciate this API isn't meant to be a Bluetooth tutorial, but it
looks unusable to me until I find/read/take one. If all I want to do
is make, say, a multiplayer bluetooth game, the jargon in this API
would be intimidating. What is the difference between rfcomm and
l2cap? What is a Sco socket or a psm? How do I know what address and
channel should be? If I'm really limited to 60 channels as Wikipedia
tells me, how do I know which one to pick?

For my game, how do I enumerate available devices to play with?

I can't think of why I'd want a non-blocking API off hand. However,
some developers (especially beginner level) might appreciate a higher
level wrapper around raw sockets that removes the need to use threads,
and for instance, automates the process of setting up a socket to
another device based on the name of the package. It could also do Java/
parcel serialization of objects to and from the UI thread in each
process. Thus using it would look like

public class MyActivity extends Activity implements
BluetoothObjectReceiver {
private BluetoothSocket otherPlayer;
public Object sendReceive(BluetoothSocket socket, Object input) {
// Called in UI thread.
if (socket != otherPlayer) return new
GameAlreadyInProgressMessage();
// Automatically [de]serializes input/return value
if (input instanceof PlayerMovedRequest) { .... return new
PlayerMovedResponse(); }
}

public void onDeviceDiscovered(BluetoothSocket socket) {
otherPlayer = socket;
startGame();
}

BluetoothObjectExchanger bluetooth;
public void onMultiplayerGameClick() {
bluetooth = new BluetoothObjectExchanger(this)

}
}

On May 28, 8:18 am, Nick Pelly <npe...@google.com> wrote:
> This API is for blocking IO. Also interested to hear feedback on whether a
> non-blocking implementation would also be useful and why.
>
> Are there other socket options that may be useful? L2CAP MTU for example. If
> so please explain the use case.
>

> *android.bluetooth.BluetoothSocket
> */* Represents a connected or connecting Bluetooth socket* */
> * public final class BluetoothSocket implements Closeable {

> *android.bluetooth.BluetoothServerSocket*

[Nick Pelly]

Hi Mike,

RFCOMM is a streaming protocol that is like the TCP of the Bluetooth world. This API is not meant to cover device or service discovery, it only covers Bluetooth Socket Connections.

In order to serlialize objects you would use something like
new ObjectInputStream(socket.getInputStream()).readObject()
new ObjectOutputStream(socket.getOutputStream()).writeObject(obj)

Your comments re: threads and a higher level interface are noted. We may choose to expose both a low level interface such as this one and some higher level helper interfaces.

Nick

[Nick Pelly]

On Thu, May 28, 2009 at 2:43 AM, Sumanth <suman...@gmail.com> wrote:

Hi Nick,

When would this be merged to the master branch?

Done.

http://android.git.kernel.org/?p=platform/frameworks/base.git;a=blob;f=core/java/android/bluetooth/BluetoothSocket.java;h=fd8885ece9935e2f4909940c582bfa6a803afd41;hb=master

Nick

[Anders Nilsson Plymoth]

Perfect! Just what I need. Thank you.
Anders

On May 29, 2009 5:46 PM, "Nick Pelly" <npe...@google.com> wrote:

On Thu, May 28, 2009 at 2:43 AM, Sumanth <suman...@gmail.com> wrote: > > > Hi Nick, > > When woul...

Done.

http://android.git.kernel.org/?p=platform/frameworks/base.git;a=blob;f=core/java/android/bluetooth/BluetoothSocket.java;h=fd8885ece9935e2f4909940c582bfa6a803afd41;hb=master

Nick --~--~---------~--~----~------------~-------~--~----~ You received this message because you ar...

[Mike Hearn]

> In order to serlialize objects you would use something like
> new ObjectInputStream(socket.getInputStream()).readObject()
> new ObjectOutputStream(socket.getOutputStream()).writeObject(obj)

Yep, understood, I was just trying to imagine the simplest API
possible.

> Your comments re: threads and a higher level interface are noted. We may
> choose to expose both a low level interface such as this one and some higher
> level helper interfaces.

OK, great.

My question about establishing a connection holds though ... in the
TCP world you need a very clear idea of which end is the server, and
which is the client. Then the server uses a "well known" domain name
and port which is agreed ahead of time, and there are ad-hoc lists
used to try and avoid port conflicts. How does this port over to the
Bluetooth world? How many ports are available, 60? If I pick a number
arbitrarily, say 25, do I need to add some kind of custom handshake
protocol to ensure I didn't end up connecting to some random app
running on a random nearby phone?

[xiaoming gu]

Hi, Nick. Does this mean two previous classes RfcommSocket and ScoSocket both obsolete with the two new classes? Thanks.

Xiaoming

[Luis]

Yep, I also think it will be better to include both choices, low level
and high level API. Even a class oriented to serialize objects through
bluetooth will be great ;)

If you need something for a "game" for instance, you can always go low
level if you need that, but imagine the simple that can be sending a
picture or a note or any kind of object from your app :D

[Martin Nielsen]

Hi Nick

> InputStream and OutputStream are used for the data path.

In the current implementation of BluetoothInputStream and
BluetoothOutputStream only reading and writing of a single byte is
supported which seems like an inefficient API. Why isn't there a read/
write function supporting large chunks of data?

If the Bluetooth stack complies with the Bluetooth 3.0 HS
specification it would properly be hard to utilize its potential due
to the high number of jni/system calls required for reading and
writing.

> Are there other socket options that may be useful? L2CAP MTU for example. If
> so please explain the use case.

Other Bluetooth API doesn't really expose MTU settings since the
optimal settings for this depends on the actual Bluetooth chip and the
capabilites of remote peer. It might be difficult for the user to set
an optimal value and even so there isn't any guarantee that it would
be honored.

[Nick Pelly]

On Wed, Jun 24, 2009 at 8:12 AM, Martin Nielsen <martin....@csr.com> wrote:

Hi Nick

> InputStream and OutputStream are used for the data path.

In the current implementation of BluetoothInputStream and
BluetoothOutputStream only reading and writing of a single byte is
supported which seems like an inefficient API. Why isn't there a read/
write function supporting large chunks of data?

If the Bluetooth stack complies with the Bluetooth 3.0 HS
specification it would properly be hard to utilize its potential due
to the high number of jni/system calls required for reading and
writing.

Yes writing 1 byte at a time is horribly inefficient :)

This was a temporary measure and has been fixed internally - we can now pass byte arrays - should get pushed out to public soon.

 

> Are there other socket options that may be useful? L2CAP MTU for example. If
> so please explain the use case.

Other Bluetooth API doesn't really expose MTU settings since the
optimal settings for this depends on the actual Bluetooth chip and the
capabilites of remote peer. It might be difficult for the user to set
an optimal value and even so there isn't any guarantee that it would
be honored.

Thanks for the feedback.

Nick

[Jonas Petersson]

Nick Pelly wrote:

> On Wed, Jun 24, 2009 at 8:12 AM, Martin Nielsen <martin....@csr.com <mailto:martin....@csr.com>> wrote:
> > InputStream and OutputStream are used for the data path.
>
> In the current implementation of BluetoothInputStream and
> BluetoothOutputStream only reading and writing of a single byte is
> supported which seems like an inefficient API. Why isn't there a read/
> write function supporting large chunks of data?

> [...]

> Yes writing 1 byte at a time is horribly inefficient :)
>
> This was a temporary measure and has been fixed internally - we can now pass byte arrays - should get pushed out to public soon.

Speaking of efficiency: Has anyone on this list built a firmware+sdk
and used it to create a working RFCOMM Bluetooth application yet?
(Never mind performance of the app.)

I made a quick stab about a week ago, but after about 6 hours of
compilation realized that I had too new JRE and since then I've been
too busy with other things. With a bit of "luck" it will rain all
through my upcoming holidays - that should give me the time I need...
;-)

Best / Jonas

[Martin Nielsen]

Hi Nick

Given the discussion about simplifying the API I thought about the
parameters for the functions above. One idea could be to change the
API to something like this:

public static BluetoothSocket createRfcommSocket(String address,

String serviceUuid) throws IOException;
public static BluetoothSocket createInsecureRfcommSocket(String
address, String serviceUuid) throws IOException;

public static BluetoothSocket createScoSocket(String address) throws
IOException;

public static BluetoothSocket createL2capSocket(String address, String
serviceUuid) throws IOException;
public static BluetoothSocket createInsecureL2capSocket(String
address, String serviceUuid) throws IOException;

The channel and psm is basically changed to a uuid 128 bit hiding the
operations required to perform the SDP lookup.

Something similar could also be done with the server APIs like:

public static BluetoothServerSocket listenUsingRfcommOn(String
serviceUuid) throws IOException;
public static BluetoothServerSocket listenUsingInsecureRfcommOn(String
serviceUuid) throws IOException;
public static BluetoothServerSocket listenUsingL2capOn(String
serviceUuid) throws IOException;
public static BluetoothServerSocket listenUsingInsecureL2capOn(String
serviceUuid) throws IOException;

public static BluetoothServerSocket listenUsingSco() throws
IOException;

I'm not sure if this would work since it would require the class to
register an SDP record exposing the service. Need to have a look at
the spec to see if it is possible. The downside of the change on the
server side is that you can't register a complex SDP record.

This could also be made as an abstraction on top of the
BluetoothSocket layer.

Regards
Martin

[Martin Nielsen]

Hi Nick

I can see two different usages of this API:

* Implementing a proprietary communication channel for use in games as
an example. To that end a simpler API to hide all the nasty stuff with
SDP record might be a way to speeding of the application development
without requiring the developer to know much about the Bluetooth
details
* Implementing one of the official Bluetooth profiles in Java. This
could require some more features to control SDP records and the
searching.

Your suggested API will be very natural for a Bluetooth developer to
use but might prove difficult for others to use.

The main difference between TCP/IP communication and Bluetooth is the
identification of the services. In the TCP/IP world services is
identified by the port number you are trying to connect too but in
Bluetooth SDP record using uuid are used to identify the service. As
such the channel number you are using in RFCOMM are irrelevant. In you
suggested API for the BluetoothServerSocket you have to specify the
channel number you want to use when creating a listing socket:

public static BluetoothServerSocket listenUsingRfcommOn(int channel)
throws IOException;

If the application must specify the actual RFCOMM channel number
multiple application might have difficulties in opening the socket
unless you continue to create BluetoothServerSocket with different
channel value until one succeeds. I might be help full if the API
could help with this assigning task.

The same could to some extend apply to L2CAP, but since PSMs work a
bit differently than RFCOMM channel a direct value might be useful if
you are trying to implement an official Bluetooth profile in java.
Still I believe this could still be identified by UUID's instead.

Specific value could also be used to identify automatically assignment
such as:

BLUETOOTH_RFCOMM_CHANNEL_AUTOASSIGN = -1;
BLUETOOTH_L2CAP_PSM_AUTOASSIGN = -1;

Some interface for extracting the assigned value would be required for
the registering the SDP record.

Too fully evalute the suggested API might require some more details on
how you are planning to handle SDP since it is such a vital part of
connection establishment.

One feature I'm missing from either this API of the BluetoothDevice
implementation is the controlling of the low power mode. I'm unsure if
BlueZ is capable of handling low power mode without external control.

Regards
Martin

[Nick Pelly]

Hi Martin,

Thanks for your comments,

Agreed on all the above points.

Regular apps should not be hardcoding RFCOMM channel numbers. We are working on an SDP API that can return a BluetoothSocket with the appriopriate channel already set (so the channel selection is invisible to the app developer). Servers and Clients will just specify a UUID to register / request.
 
Consider BluetoothSocket.java a basic building block.

The same could to some extend apply to L2CAP, but since PSMs work a
bit differently than RFCOMM channel a direct value might be useful if
you are trying to implement an official Bluetooth profile in java.
Still I believe this could still be identified by UUID's instead.

Specific value could also be used to identify automatically assignment
such as:

BLUETOOTH_RFCOMM_CHANNEL_AUTOASSIGN = -1;
BLUETOOTH_L2CAP_PSM_AUTOASSIGN = -1;

Some interface for extracting the assigned value would be required for
the registering the SDP record.

Too fully evalute the suggested API might require some more details on
how you are planning to handle SDP since it is such a vital part of
connection establishment.

One feature I'm missing from either this API of the BluetoothDevice
implementation is the controlling of the low power mode. I'm unsure if
BlueZ is capable of handling low power mode without external control.

Both link state (sniff mode etc) and chipset power mode (deep sleep etc) are handled within the kernel. They are not exposed to userspace, and we don't have plans to expose this.

Bluez enters sniff mode on a link after a short period of inactivity.

Nick

[Nick Pelly]

On Wed, Jun 24, 2009 at 3:11 PM, Martin Nielsen <martin....@csr.com> wrote:

Hi Nick

Given the discussion about simplifying the API I thought about the
parameters for the functions above. One idea could be to change the
API to something like this:

public static BluetoothSocket createRfcommSocket(String address,

String serviceUuid) throws IOException;

public static BluetoothSocket createInsecureRfcommSocket(String

address, String serviceUuid) throws IOException;

public static BluetoothSocket createScoSocket(String address) throws
IOException;

public static BluetoothSocket createL2capSocket(String address, String
serviceUuid) throws IOException;

public static BluetoothSocket createInsecureL2capSocket(String

address, String serviceUuid) throws IOException;

Neat idea (although prefer java.util.UUID not String),

We would have to perform the SDP lookup during connect(). It does have the slight disadvantage of making it hard to disambiguate 'SDP lookup successful but RFCOMM connection failed' from 'SDP failed'.

[Eric F]

I have a Bluetooth question. For the ADC, before Bluetooth was
removed, I was interested in making an application that works by
discovering other phones that have the same app running and then
notifying the user. Without getting into the details. Just imagine
like a simple two player Pong game, where when you run into someone
else who also has the Pong game, your phone vibrates and you have a
notification telling you that the other player can be challenged to a
game, etc.

I have a few questions about Bluetooth for a use like this. First I
don't think GPS can really provide this functionality. Because it
doesn't work well indoors, and that's where I think a lot of people
are going to end up like 20 feet from each other, where they can
actually go head-to-head in person. Also it seems like using GPS, both
phones would have to check so frequently AND use an internet
connection to send coordinates to a server to find out that they are
near each other the battery would never last.

So my questions are:

1. What would be the battery cost of leaving bluetooth on and looking
for phones that accept certain application specific sockets.
2. Would an API that would support this kind of use case, where your
app gets notified when another phone comes into range that also has
that app.
3. Do you think this is the right way to go about this? Or is there
some alternative I am unaware of that might be superior?

Thanks, I really feel like near-range phone detection could lead to
some really innovative and unseen applications.

-E

On May 27, 11:18 pm, Nick Pelly <npe...@google.com> wrote:
> Hi,
>
> There has been a lot of demand for an API to Bluetooth RFCOMM sockets (also
> known as Serial Port Profile).
>
> Here is an API proposal open for comment. It also covers SCO and L2CAP
> sockets.
>

> *Background*

> BluetoothSocket and BluetoothServerSocket are modeled on java.net.Socket and
> java.net.ServerSocket respectively. However we cannot use Socket and
> ServerSocket directly because they are tightly bound to TCP sockets.
>
> This design currently uses factory methods to create the socket objects. We
> are likely to switch to a Builder pattern if any more construction time
> options are required (L2CAP MTU?). The same builder could be used for both
> BluetoothSocket and BluetoothServerSocket.
>
> InputStream and OutputStream are used for the data path.
>
> This API is for blocking IO. Also interested to hear feedback on whether a
> non-blocking implementation would also be useful and why.
>
> Are there other socket options that may be useful? L2CAP MTU for example. If
> so please explain the use case.
>

> *android.bluetooth.BluetoothSocket
> */* Represents a connected or connecting Bluetooth socket* */
> * public final class BluetoothSocket implements Closeable {

> *android.bluetooth.BluetoothServerSocket*

[Thiago Rafael Becker]

Will it be available in an OTA update for the G1 phone?

Thanks :)

--
Thiago Rafael Becker
http://www.monstros.org/trbecker

[Shanjaq]

Very Much interested in seeing Bluetooth API of any kind for
Android. !

On Jun 26, 2:37 pm, Nick Pelly <npe...@google.com> wrote:
> Hi Martin,
>
> Thanks for your comments,
>

[Arun]

Hi Nick,


I am trying to implement hidd in android.
Any pointers for the same.
My understanding about the same is
I need to write couple API's referencing native code
thst can handle hidd enabled devices. and need to register same in
Android / services.

any pointers or help is Highly appreciated

Regards,
Arun

[Nick Pelly]

Yeah these are neat ideas - and been developed by many people before.
See Bluedating etc.

Leaving a phone in Bluetooth discoverable mode is not a big issue for
power consumption. BT is very power friendly, and discoverable is a
passive mode.

But it does raise questions of privacy. We would need to make the user
aware that by being always discoverable people can detect they are in
the area - even for example several rooms away. So it is unlikely we
would make the Android platform discoverable by default.

We will have two levels of Bluetooth permission for applications.
BLUETOOTH and BLUETOOTH_ADMIN. At this stage we will probably make
turning discoverability on/off a BLUETOOTH_ADMIN permission.

Nick

[Nick Pelly]

On Wed, Jul 29, 2009 at 3:21 AM, Arun<achoudh...@gmail.com> wrote:
>
> Hi Nick,
>
>
> I am trying to implement hidd in android.
> Any pointers for the same.
> My understanding about the same is
> I need to write couple API's referencing native code
> thst can handle hidd enabled devices. and need to register same in
> Android / services.
>
> any pointers or help is Highly appreciated

See http://source.android.com/projects/bluetooth-faq and next time
please keep your questions on topic to the thread.

Nick

[Eric F]

On Aug 5, 9:04 am, Nick Pelly <npe...@google.com> wrote:
> Yeah these are neat ideas - and been developed by many people before.
> See Bluedating etc.
>
> Leaving a phone in Bluetooth discoverable mode is not a big issue for
> power consumption. BT is very power friendly, and discoverable is a
> passive mode.
>
> But it does raise questions of privacy. We would need to make the user
> aware that by being always discoverable people can detect they are in
> the area - even for example several rooms away. So it is unlikely we
> would make the Android platform discoverable by default.
>
> We will have two levels of Bluetooth permission for applications.
> BLUETOOTH and BLUETOOTH_ADMIN. At this stage we will probably make
> turning discoverability on/off a BLUETOOTH_ADMIN permission.
>
> Nick

Thank you for the response Nick,

I am aware of the Bluetooth privacy issues and I am glad to hear that
the battery isn't going to be a completely limiting factor. What I
would hope to see is an API similar to LocationManager's proximity
alert functionality but expanded into the BlueTooth environment.
Because if a lot of apps doing this kind of thing get popular, people
aren't going to want each one fighting each other on Bluetooth
control. The way I see the design would be.

Example use case:
- User installs a peer to peer pong like game that allows them to
play other players locally over bluetooth.
- Application manifest lists a permission
BLUETOOTH_ADVERTISE_SERVICE, so user is prompted to authorize the app
for the permission. The user is warned "With this application
installed, whenever bluetooth is enabled and set to discoverable
anyone will be able to tell that your phone is running this
application and will be able to communicate with this application"
- User accepts the security warning
- User runs the app
- The app registers its bluetooth service with the Bluetooth Service
Proximity service or whatever the new framework is. The app requests
three things: That the phone advertise over bluetooth that it supports
the PONG_GAME_PLAY, it registers an intent receiver to catch an intent
that fires whenever someone connects to this service, and lastly it
registers to receive notifications when a phone is discovered that
supports this service.
- The user is then at the home screen of the game. The game queries
bluetooth status and determines that bluetooth is not discoverable.
The game displays a warning message to the user that while bluetooth
is not discoverable, they will not be challengable by other players,
nor will they be notified of other players to play.
- The user then clicks a button in the game to "enable bluetooth
discoverability"
- The game launches an intent to enable bluetooth discoverability
which is handled by a system application with BLUETOOTH_ADMIN
permission, where the user can confirm that they actually want to turn
it on.
- User walks around in the real world. Their phone vibrates they look
at the notification bar and see there is a pong notification, they
pull down the notification bar and see that user "pong_gurl" is in the
area with a button to challenge them.

This still puts the user in control of their bluetooth
discoverability. And allows multiple applications to play nicely with
each other when it comes to Bluetooth. I don't think it's in the users
best interest to install a ton of apps with BLUETOOTH_ADMIN
capabilities.

What do you think? Thanks,

-E

[Jonas Petersson]

Hi Nick (mostly),

Now that 1.6 is more or less done. Any chance of spilling the beans on
the current state of the Bluetooth Socket API in Donut?

There are many of us eagerly waiting for any way at all to transfer
data over bluetooth. Ideally using an official API, but if that is not
an option then going over the NDK or using a reflection or similar
would be better than nothing. At best the result could be contributed.

Best / Jonas

[Nick Pelly]

As you've probably seen its not in Donut SDK,

I cannot comment on schedule, but releasing a solid, stable Bluetooth API is still a priority of the Android Bluetooth team.

Nick

[windstorm]

Hi Nick:

I tried this api and met problem like this

Starting activity: Intent { action=cn.forwind.bluetooth.COMMUNICATION
comp={cn.forwind.bluetooth/cn.forwind.bluetooth.BluetoothCom} }
E/dalvikvm( 1501): Could not find method
android.bluetooth.BluetoothSocket.createRfcommSocket, referenced from
method cn.forwind.bluetooth.BluetoothCom.run1
W/dalvikvm( 1501): VFY: unable to resolve static method 9: Landroid/
bluetooth/BluetoothSocket;.createRfcommSocket (Ljava/lang/String;I)
Landroid/bluetooth/BluetoothSocket;
W/dalvikvm( 1501): VFY: rejecting opcode 0x71 at 0x0003
W/dalvikvm( 1501): VFY: rejected Lcn/forwind/bluetooth/
BluetoothCom;.run1 ()V
W/dalvikvm( 1501): Verifier rejected class Lcn/forwind/bluetooth/
BluetoothCom;
W/dalvikvm( 1501): Class init failed in newInstance call (Lcn/forwind/
bluetooth/BluetoothCom;)
D/AndroidRuntime( 1501): Shutting down VM
W/dalvikvm( 1501): threadid=3: thread exiting with uncaught exception
(group=0x4000fe70)
E/AndroidRuntime( 1501): Uncaught handler: thread main exiting due to
uncaught exception
E/AndroidRuntime( 1501): java.lang.VerifyError:
cn.forwind.bluetooth.BluetoothCom

My code is pretty simple:

BluetoothSocket socket = BluetoothSocket.createRfcommSocket
(address_kkli, 1);
connection.setText(socket.getAddress());
socket.close();

What I have done with the sdk:

1 Get rid of all @hide symbol in files about bluetooth
2 make sdk
3 copy the new android.jar to replace the original one under sdk
directory

Is there anything I missed like corresponding libs or whatever? No
question with compiling.

This is the last way for me to possibly use bluetooth in my project
with Android phone, so any suggestion would be greatly appreciated.

On Sep 16, 7:06 pm, Nick Pelly <npe...@google.com> wrote:
> As you've probably seen its not in Donut SDK,
> I cannot comment on schedule, but releasing a solid, stable Bluetooth API is
> still a priority of the Android Bluetooth team.
>
> Nick
>

[Shawn Brown]

> I cannot comment on schedule, but releasing a solid, stable Bluetooth API is
> still a priority of the Android Bluetooth team.

It's just too bad that it's such a closed process. Correct me if I am
wrong, but since there is no access to radio stuff, the community
can't test or develop and just has to wait until you get it done.

I mean you say "solid" but linux itself was developed more openly and
benefited by many people being able to test the code. I am not
suggesting your work won't be solid, but just that the closed nature
of the project seems less than ideal. I concede that may be the
reality working with handset vendors but ... it seems less than ideal.

Shawn

[Qwavel]

I too am dissapointed that the Bluetooth API is not in 1.6, and that
we don't know when it will appear. On the other hand, by the
standards of mobile platforms, this is a pretty open process.

Also, I believe we do have access to the code for testing and
experimentation. You are right that there is some stuff closed, but
the 'radio stuff', for example, has to be closed for regulatory
reasons.

[Qwavel]

Jonas,

I haven't actually looked at the NDK, but I highly doubt that it
allows access to Bluez or any other 'internal' API's of Android. I
don't think that's what it was meant for.

I believe that the Android Java Bluetooth API will be the only way for
you to do what you want.

Qwavel.

[Jonas Petersson]

Hi Qwavel,

On Thu, Sep 17, 2009 at 18:32, Qwavel <qwa...@gmail.com> wrote:
> On Sep 16, 3:23 pm, Jonas Petersson <catel...@gmail.com> wrote:
>> There are many of us eagerly waiting for any way at all to transfer
>> data over bluetooth. Ideally using an official API, but if that is not
>> an option then going over the NDK or using a reflection or similar
>> would be better than nothing. At best the result could be contributed.
>

> I haven't actually looked at the NDK, but I highly doubt that it
> allows access to Bluez or any other 'internal' API's of Android.  I
> don't think that's what it was meant for.

Feel free to doubt, but by requesting the two Bluetooth permissions it
is quite possible to use the system libraries for bluez - it currently
fails on Hero and Galaxy, presumably since their firmwares are not
quite the same. Note: I'm not taking any credit at all for this,
please check the Bluecove project and Mina's Androbex app (on the
Market).

Also, Stefano Sanna has managed to get the hidden APIs working for all
devices except Hero. However, it seems that this route might be closed
in 1.6 due to restructuring of the code, but there may be
alternatives...

True, neither route is perfect, they both prove that the possibility is there.

> I believe that the Android Java Bluetooth API will be the only way for
> you to do what you want.

That will certainly be the BEST way to do it once it exists. In the
mean time we can either patiently wait or impatiently poke around. It
would seem that you belong to the former group while Mina and Stefano
are in the latter and I'd like to do my best to help them out as best
I can. Glory to the brave ;-)

Best / Jonas

[Qwavel]

That's interesting. I'll have to take a closer look. Getting access
at that level would be great.

I take it, however, that you are talking about 'unofficial' API's, and
I'd be concerned about using those for the obvious reasons.

[Jonas Petersson]

Hi again,

On Thu, Sep 17, 2009 at 20:51, Qwavel <qwa...@gmail.com> wrote:
>> > [...]

>> > I believe that the Android Java Bluetooth API will be the only way for
>> > you to do what you want.
>>
>> That will certainly be the BEST way to do it once it exists. In the
>> mean time we can either patiently wait or impatiently poke around. It
>> would seem that you belong to the former group while Mina and Stefano
>> are in the latter and I'd like to do my best to help them out as best
>> I can. Glory to the brave ;-)
>

> That's interesting.  I'll have to take a closer look.  Getting access
> at that level would be great.
>
> I take it, however, that you are talking about 'unofficial' API's, and
> I'd be concerned about using those for the obvious reasons.

You are not alone: Dianne has put multiple, big frowns on this ;-)
Still, some of us are currently more concerned about getting a bit of Bluetooth
working in the short term than worrying about the occassional frown.

Personally, I can see that working around the hidden api deserves a frown
(but it also gives best potential compatiblity on 1.5), but the NDK route is
IMHO not particularly naughty - just trickier... It may very well be that what
has been found IS broken for the nonworking devices and that is part of the
reason for Nick's message about a solid, stable API.

Best / Jonas

[Dianne Hackborn]

On Thu, Sep 17, 2009 at 12:13 PM, Jonas Petersson <cate...@gmail.com> wrote:

Personally, I can see that working around the hidden api deserves a frown
(but it also gives best potential compatiblity on 1.5), but the NDK route is
IMHO not particularly naughty - just trickier... It may very well be that what
has been found IS broken for the nonworking devices and that is part of the
reason for Nick's message about a solid, stable API.

Using private APIs from the NDK is just as fragile as using them in the SDK.

I don't care about people hacking around and doing whatever they want with private APIs, I just want it to be clear what this means.

Honestly, I've tried hard not to poke my nose in this thread, because I've assumed this was clear...  but then when I see people being surprised that the private APIs aren't working on some particular device, or other such things, it seems like it still isn't clear so I feel the need to comment again.

So...  don't be surprised if any of this stuff doesn't work or just does something strange in different ways on every different device you try it on, because this is -not- a supported part of the platform, and it can freely change across different vendors and platform releases and even devices from the same vendor.

In fact, those of us working on the platform have no idea at all what any of these private APIs could be like on any of the devices we haven't worked directly with (which is quickly becoming the majority of devices).  Some vendors may have updated the bluez iibrary to a newer version, and fiddled with the Java APIs to do things they wanted for their device, or completely replaced bluez and everything with their own stuff.  It's all valid, because these are private APIs.

This is one of the reasons we have gone to so much trouble to make a delineation between the official SDK/NDK and the sea of private implementation -- we have no control over what happens to the private APIs (unlike the public APIs), and it is safe to assume that most device manufacturers will often change these with no thought to what applications may be using them.

So the basic rule for private APIs in both the SDK and NDK: have fun on the specific device you are working on, and count yourself lucky if your code works on another device or a different version of the platform.

--
Dianne Hackborn
Android framework engineer
hac...@android.com

Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails.  All such questions should be posted on public forums, where I and others can see and answer them.

[Sudheesh J]

Lately running in to this thread.

1. Even though the exporting the MTU as a creation option may not be
required, it is good to provide an API for the application programmer
to know the negotiated MTU. Allocating higher level buffers as an even
multiple of MTU can speed up performance to some extent.

2. Can we expect an API that is conforming with/subset of JSR82?
http://jcp.org/en/jsr/detail?id=82

I see a couple of questions in this line, but not answered.

regards,
Sudheesh

On Sep 17, 6:06 am, Nick Pelly <npe...@google.com> wrote:
> As you've probably seen its not in Donut SDK,
> I cannot comment on schedule, but releasing a solid, stable Bluetooth API is
> still a priority of the Android Bluetooth team.
>
> Nick
>

[Sudheesh J]

Lately running in to this thread.

1. On L2CAP MTU, even though a construction option is omitted, it
would make sense to expose the negotiated MTU value for a socket. This
would help an application to allocate buffers in multiples of MTU,
which would ease the segmentation and reassembly.

2. Can we expect an API aligning to JSR-82?
http://jcp.org/en/jsr/detail?id=82

I saw questions pertaining to JSR82 compliance in a couple of places,
but never answered.

regards,
Sudheesh

On Sep 17, 6:06 am, Nick Pelly <npe...@google.com> wrote:

> As you've probably seen its not in Donut SDK,
> I cannot comment on schedule, but releasing a solid, stable Bluetooth API is
> still a priority of the Android Bluetooth team.
>
> Nick
>

[Qwavel]

About the 'address' string which is used, for example, in these API's:

> public static BluetoothSocket createL2capSocket(String address, int psm)
throws IOException;

> public String getAddress();

I assume that this string is just the bd_addr of the target device,
and that the getAddress() function returns that same bd_addr for a
BluetoothSocket object.

This leads me to wonder, how do I get the bd_addr of my Bluetooth
radio? I couldn't find anything in the framework documentation about
this.

[Qwavel]

On Sep 18, 1:34 am, Sudheesh J <sudheesh....@wipro.com> wrote:
> Lately running in to this thread.
>
> 1. On L2CAP MTU, even though a construction option is omitted, it
> would make sense to expose the negotiated MTU value for a socket. This
> would help an application to allocate buffers in multiples of MTU,
> which would ease the segmentation and reassembly.

I would like to concur with this: that it is useful to be able to read
the MTU's of a socket.

For example, if I am sending L2CAP data from a J2ME device (e.g. a
Blackberry) then I must break my data into chunks of size less then
that connections' MTU. Here is the documentation for the relevant API
on RIM's site so you can see why I say this:
http://www.blackberry.com/developers/docs/4.6.0api/index.html

This means that I will be receiving that data on my Android phone in
chunks of MTU bytes, so I will want to read the MTU of the socket so I
can allocate my buffers accordingly.