BLUETOOTH CODE ORGANISATION IN CUPCAKE RELEASE

[kaushik.siso]

Hi
I needed some info regarding the Bluetooth module in the cupcake
release. I wanted to know how BT is structured in Android cupcake and
what profiles will be supported post cupcake release .

I visited http://android.git.kernel.org/
and I have downloaded the source codes (from the Code drop from //
branches/cupcake/... fields) for these modules

platform/external/bluez.git
platform/system/bluetooth.git
platform/packages/apps/Settings.git

I am not finding the files that deal with files supporting Java
framework classes like ex BluetoothDevice
(BluetoothDevice.java),Headset (BluetoothHeadset.java), Rfcomm related
(RfcommSocket.java) etc which were supposed to change post SDK1.

regards
KS@SIS

[Nick Pelly]

Hi Kaushik,

Please don't use ALL CAPS subjects. It is bad list etiquette.

Anyway to answer your questions...

Right now these are included in framework.jar, so they are part of the project
platform/frameworks/base.git
in locations such as
frameworks/base/core/java/android/bluetooth/BluetoothDevice.java
frameworks/base/core/java/android/bluetooth/BluetoothHeadset.java

Often these API (well-not-quite-yet) classes are just proxies for the
real service that executes in the System Server. For example
frameworks/base/core/java/android/server/BluetoothDeviceService.java
frameworks/base/core/java/android/server/BluetoothEventLoop.java

The JNI that backs the system server implementations is in
libandroid_runtime.so, and part of the same project, and can be found
in locations such as
frameworks/base/core/jni/android_server_BluetoothDeviceService.cpp
frameworks/base/core/jni/android_server_BluetoothEventLoop.cpp

You didn't ask, but the HFP and HSP profile implementations are
actually included in the Phone application right now. For example
packages/apps/Phone/src/com/android/phone/BluetoothHeadsetService.java
packages/apps/Phone/src/com/android/phone/BluetoothHandsfree.java

I really recommend checking out the entire Android codebase using
repo. Then you can quickly use
find . -name FILENAME
to find the locations of these files.

Nick

[dec...@shanaghy.com]

Thanks for the info.
I am interested in jumping in on some bluetooth development also.

I'd like to add support for the HID profile.
I'd like some more info on the feasibility of this making it into a
release.

What im wondering is do the releases stick to an approved roadmap or
can unscheduled/unexpected contributions make it into a release fairly
easily.

Also can i make my own branch for this feature or would it be assigned
to a specifi branch by someone?

On Jan 8, 10:31 am, Nick Pelly <npe...@google.com> wrote:
> Hi Kaushik,
>
> Please don't use ALL CAPS subjects. It is bad list etiquette.
>
> Anyway to answer your questions...
>
>
>
> On Thu, Jan 8, 2009 at 10:10 AM, kaushik.siso <kaushik....@gmail.com> wrote:
> > Hi
> > I needed some info regarding the Bluetooth module in the cupcake
> > release. I wanted to know how BT is structured in Android cupcake and
> > what profiles will be supported post cupcake release .
>

> > I visitedhttp://android.git.kernel.org/

[Nick Pelly]

Hi,

On Thu, Jan 8, 2009 at 11:46 AM, dec...@shanaghy.com
<dec...@shanaghy.com> wrote:
>
> Thanks for the info.
> I am interested in jumping in on some bluetooth development also.

Great!

> I'd like to add support for the HID profile.

There's actually not far to go. I've already set up the Android
Makefile for the bluez HID plugin
external/bluez/utils/input/Android.mk
so the module is already compiled. You can even use HID support right
now by talking directly to the bluez HID plugin with dbus. Try
dbus-send and dbus-monitor etc.

Whats needed is to plumb through this API up in the Android Java
framework. Also the Android framework needs better support for
alternative input methods such as mice and keyboards with different
keymaps. I haven't really investigated this side of things yet,
hopefully it is easier now in cupcake with the Input Method Framework.

> I'd like some more info on the feasibility of this making it into a
> release.

To actually release this in a product like the T-Mobile G1 we need to
pass Bluetooth qualification. But first step is to get the support
into the platform.

>
> What im wondering is do the releases stick to an approved roadmap or
> can unscheduled/unexpected contributions make it into a release fairly
> easily.

Unscheduled / unexpected contributions to the platform are very
welcome! We cannot guarantee they will make it into a device release
since thats up to the OEM's and carriers, and specifically in the case
of Bluetooth we need to pass qualification. But we should always
include as many profiles as possible in the open source codebase.

> Also can i make my own branch for this feature or would it be assigned
> to a specifi branch by someone?

This would go into our master branch.

Nick

[kaushik.siso]

Hi

First of all I am sorry to violate the list ettiquette by writing
subject in caps.
Anyhow, i would like to know is there any support to the DNP-dial up
netoworking profile in BT currently in Android.

Regards
Kaushik

[Nick Pelly]

On Thu, Jan 8, 2009 at 10:06 PM, kaushik.siso <kaush...@gmail.com> wrote:
>
> Hi
>
> First of all I am sorry to violate the list ettiquette by writing
> subject in caps.
> Anyhow, i would like to know is there any support to the DNP-dial up
> netoworking profile in BT currently in Android.

DUN and PAN are a similar situation to HID, except they run as there
own daemons. Bluez already has these daemons, and these are already
compiled and installed in the cupcake codebase.

There is some work required to plumb Java API's to the dbus interfaces
of these daemons, and automatically set up the network path via pppd
and iptables.

And of course qualification before it could be officially released in a product.

[coolio]

Hi Nick,

As you may remember that I have build release-1.0 based code running
on G1. I managed to have a green check mark on enabling BT. However,
the scanning comes up empty.

It is nice that hci command is build in with adb so that I have played
with it a little bit.

hcitool devices will return the BT address, that is good. However,
hcitool scan or hcitool inq always come up empty. I put some message
in hci_inquiry which scan or inq use. The following are the parameters
that were passed into the function,
dev_id = -1, len = 8, nrsp = 0, flags = 0 and the three bytes of lap
are 0x33, 0x8b and 0x9e, which are all normal.

The file descriptor returned by socket() is 3.
ioctl() returns 0, no error.

However, hci_inquiry still returns 0.

I suspect that the RF of BT on G1 is not on. Set BT to discoverable,
other BT devices can not find G1 either.

WiFi can not turn on either.

Any quick pointers?

Thanks


On Jan 8, 10:26 pm, Nick Pelly <npe...@google.com> wrote:

> >> Nick- Hide quoted text -
>
> - Show quoted text -

[Nick Pelly]

Hi,

On Thu, Jan 8, 2009 at 11:34 PM, coolio <justi...@gmail.com> wrote:
>
> Hi Nick,
>
> As you may remember that I have build release-1.0 based code running
> on G1. I managed to have a green check mark on enabling BT. However,
> the scanning comes up empty.
>
> It is nice that hci command is build in with adb so that I have played
> with it a little bit.
>
> hcitool devices will return the BT address, that is good. However,
> hcitool scan or hcitool inq always come up empty. I put some message
> in hci_inquiry which scan or inq use. The following are the parameters
> that were passed into the function,
> dev_id = -1, len = 8, nrsp = 0, flags = 0 and the three bytes of lap
> are 0x33, 0x8b and 0x9e, which are all normal.
>
> The file descriptor returned by socket() is 3.
> ioctl() returns 0, no error.
>
> However, hci_inquiry still returns 0.
>
> I suspect that the RF of BT on G1 is not on. Set BT to discoverable,
> other BT devices can not find G1 either.
>
> WiFi can not turn on either.
>
> Any quick pointers?

Some random hints...

You can run
adb shell hcidump -XVt
In one window to monitor all HCI traffic with the Bluetooth chip. If
you see data going both ways '<' and '>' then you know the HCI UART
link is good,

I usually run
adb shell hciconfig -a
To check if we can talk to the BT chip, because it will always send an
HCI command or two and needs a response. It does not do anything over
RF. Sounds like you've found a few other commands like hcitool that
will also confirm this.

It sounds like you do have HCI communication if you can get hold of
the local BT address. Yes hcitool scan or inq would be the next things
i'd try. I know its stupid but make absolutely sure your other devices
really are in discoverable mode. You could also try l2ping.

Are hciattach and hcid running?
Try running hciattach and hcid under logwrapper (edit init.rc and
init.trout.rc) so that you can view there STDOUT through logcat. Maybe
there is some error.

It is very strange if you can talk HCI to the BT chip but you cannot
do anything that involves RF. This should just work.

I wonder if you have a bad firmware file? This could affect RF but not
HCI. hciattach loads the firmware, would be good to view its logs.
Looks like the firmware file brf6300.bin is not in the open source
codebase, you would have to pull it from a stock G1.

Nick

[coolio]

Thanks for your quick response!
There is no firmware directory from the build. I will try to place
everything in that directory in the open source and build image and
let you know the result.

[coolio]

Hi Nick,

Simply make a "firmware" directory in /system/etc and push brf6300.bin
can have BT scan to find other BT devices.
make clean and make won't have brf6300.bin build in with system.img
Touch one .c file and make will have brf6300.bin build with
system.img. BT scan can find other BT device.
Maybe before the make install the system.img, it can place brf6300.bin
file in place needed to be and then make the system.img?

Thank you very much!

Justin

> > - Show quoted text -- Hide quoted text -

[Nick Pelly]

On Fri, Jan 9, 2009 at 3:46 PM, coolio <justi...@gmail.com> wrote:
>
> Hi Nick,
>
> Simply make a "firmware" directory in /system/etc and push brf6300.bin
> can have BT scan to find other BT devices.
> make clean and make won't have brf6300.bin build in with system.img
> Touch one .c file and make will have brf6300.bin build with
> system.img. BT scan can find other BT device.
> Maybe before the make install the system.img, it can place brf6300.bin
> file in place needed to be and then make the system.img?

Glad that fixed your issue.

Yes, Ideally a system.img for a G1 contains the firmware file. I'll
look into getting brf6300.bin into the open source codebase. Hopefully
it is not there for some technical issue.

[dec...@shanaghy.com]

Are there some special build options that have to be provided to
enable the radio functionality when building for dream on a dev phone?
I built the source but there is no support for wifi or BT in there.

[Declan Shanaghy]

OK well i managed to get the BT binaries to build by setting
BOARD_HAVE_BLUETOOTH:=true in mydroid/buildspec.mk
I pushed up brf6300.bin to /system/etc/firmware but
bluetooth still wont start from the setting dialog.

I am using the DP1 with lastest code from main branch


Any more suggestions on how to get BT up and running?

[Declan Shanaghy]

Just saw your suggestion to hun the services thru logwrapper and did so.

Seems that libril.so is crashing.
I saw a post elsewhere that the HTC proprietary binaries (primarily for ril) are out of date with respect to the latest code on the main branch, is this really so?

I have attached a bugreport.

[Nick Pelly]

Hi Declan,

On Sat, Jan 10, 2009 at 4:50 PM, Declan Shanaghy <dec...@shanaghy.com> wrote:
> Just saw your suggestion to hun the services thru logwrapper and did so.
>
> Seems that libril.so is crashing.

This should not prevent Bluetooth from working.

> I saw a post elsewhere that the HTC proprietary binaries (primarily for ril)
> are out of date with respect to the latest code on the main branch, is this
> really so?
>
> I have attached a bugreport.

Your bugreport does not show you starting Bluetooth. What do the logs
shows when you do this?

>
> On Sat, Jan 10, 2009 at 3:37 PM, Declan Shanaghy <dec...@shanaghy.com>
> wrote:
>>
>> OK well i managed to get the BT binaries to build by setting
>> BOARD_HAVE_BLUETOOTH:=true in mydroid/buildspec.mk

This is correct.

>> I pushed up brf6300.bin to /system/etc/firmware but
>> bluetooth still wont start from the setting dialog.

Nick

[Declan Shanaghy]

When i click on the checkmark to start bluetooth nothing happens.
Nothing is printed to the log either.

[Brighton, Mark]

I had the same trouble after flashing new image, but it resolved after restarting the phone.
________________________________________
From: android-...@googlegroups.com [android-...@googlegroups.com] On Behalf Of Declan Shanaghy [dec...@shanaghy.com]
Sent: Tuesday, January 13, 2009 12:36 AM
To: android-...@googlegroups.com
Subject: Re: BLUETOOTH CODE ORGANISATION IN CUPCAKE RELEASE

[Nick Pelly]

This is strange. I would suggest adding some logging to
BluetoothDeviceService.java:enable(), or breakpointing, to see what is
going on.

BTW, I have started a Bluetooth FAQ that covers a lot of the answers I
have already given, and some other useful information. It will get
fleshed out as time goes on.

http://source.android.com/projects/bluetooth-faq

Nick

[syam.si...@wipro.com]

Try hciconfig -a and check the hci device is up.
The device_id should not be -1, most probably its 0, which means hci0 interface.
Also Number of responses(nrsp) should be greater than 0. Ignore the COD (class of device)
Eg: hcitool hci0 inq

Regards,
Syam Sidhardhan

-----Original Message-----
From: android-...@googlegroups.com [mailto:android-...@googlegroups.com] On Behalf Of coolio
Sent: Friday, January 09, 2009 1:05 PM
To: android-platform
Subject: Re: BLUETOOTH CODE ORGANISATION IN CUPCAKE RELEASE

[Thias]

I'm running into this issue, but it seems that error does not exactly
come at the same time.
I've compiled the master branch, and installed it on a G1.
The bluetooth system can't start, because of a
"I//system/bin/hciattach( 253): Initialization timed out."
error in the "read_hci_event" function in hciattach.

I'm trying to initialize the device with the following:
/system/bin/logwrapper /system/bin/hciattach -n -s 115200 /dev/ttyMSM0
texas 115200 flow

and have the brf6300.bin file in /system/etc/firmware.

ls -l /dev/ gives the following:
crw------- bluetooth bluetooth 250, 0 2009-01-15 15:44 ttyHS0
crw------- bluetooth bluetooth 251, 0 2009-01-15 15:44 ttyMSM0

Anyone has an idea why "device" isn't readable?

[Nick Pelly]

On Thu, Jan 15, 2009 at 6:49 AM, Thias <thias....@gmail.com> wrote:
>
> I'm running into this issue, but it seems that error does not exactly
> come at the same time.
> I've compiled the master branch, and installed it on a G1.
> The bluetooth system can't start, because of a
> "I//system/bin/hciattach( 253): Initialization timed out."
> error in the "read_hci_event" function in hciattach.
>
> I'm trying to initialize the device with the following:
> /system/bin/logwrapper /system/bin/hciattach -n -s 115200 /dev/ttyMSM0
> texas 115200 flow

Thats using the low speed uart driver. Should work though.

>
> and have the brf6300.bin file in /system/etc/firmware.
>
> ls -l /dev/ gives the following:
> crw------- bluetooth bluetooth 250, 0 2009-01-15 15:44 ttyHS0
> crw------- bluetooth bluetooth 251, 0 2009-01-15 15:44 ttyMSM0

Ok so you have a kernel with the old uart driver and the new high
speed uart driver - good.

>
> Anyone has an idea why "device" isn't readable?
>

Sounds like you are trying to start Bluetooth manually. The first step
is to turn on power to the BT chip.
adb shell "echo 1 > /sys/class/rfkill/rfkill0/state"

I think this will fix your issue. If not it is probably permissions
related. Try running hciattach via an init.rc for so that it gets the
right user and groups. For example:

service hciattach /system/bin/hciattach \
-n -s 115200 /dev/ttyHS0 texas 4000000 flow
user bluetooth
group bluetooth net_bt_admin
disabled

Let me know how it goes.

Nick

[coolio]

Hi Nick,

So have you tried running this at 4Mbps successfully? I ask because
I found at least one problem that the hciattach does not use CBAUDEX
in the termios option and even after I fixed this, it did not work for
me.

Thanks

On Jan 15, 10:49 am, Nick Pelly <npe...@google.com> wrote:

[Nick Pelly]

On Thu, Jan 15, 2009 at 5:19 PM, coolio <justi...@gmail.com> wrote:
>
> Hi Nick,
>
> So have you tried running this at 4Mbps successfully? I ask because
> I found at least one problem that the hciattach does not use CBAUDEX
> in the termios option and even after I fixed this, it did not work for
> me.

Yes. We've been running 4Mbps in cupcake for many weeks now.

[coolio]

I am running from the latest master repository, is it awaiting any
merges from you?
Can you please compare hciattach and msm_serial_hs.c code-base on
master repository with what you have

Thanks,
Justin

On Jan 15, 5:26 pm, Nick Pelly <npe...@google.com> wrote:

[Thias]

Nick,

This was it... turning power on to the chip did the trick.
Never the less, I'm still fighting to have it running when turning
bluetooth on from the interface.
I'll investigate this a little more ;-)
--
Thias
http://blog.mc-thias.org

On Jan 15, 7:49 pm, Nick Pelly <npe...@google.com> wrote:

[Thias]

Well... I've removed the start of the hciattach service from the ./
system/bluetooth/bluedroid/bluetooth.c.
If the device is manually powered on, and hciattach is manually run
(with "-n -s 115200 /dev/ttyHS0 texas 4000000 flow" parameters) , then
the bluetooth system can be started from the user interface. At this
point, the device can scan for other devices, even pair with them, ...

If hciattach is started within the bt_enable function (property_set
("ctl.start", get_hciattach_script())), then the device looks once
more not readable... leading to a timeout error.


I//system/bin/hciattach( 255): [thias] options: /dev/ttyHS0
I//system/bin/hciattach( 255): [thias] options: texas
I//system/bin/hciattach( 255): [thias] options: 4000000
I//system/bin/hciattach( 255): [thias] options: onrestart
I//system/bin/hciattach( 255): [thias] options: ؞
I//system/bin/hciattach( 255): [thias] options: ؞
I//system/bin/hciattach( 255): [thias] init_speed
I//system/bin/hciattach( 255): [thias] init_uart
I//system/bin/hciattach( 255): [thias] open device
I//system/bin/hciattach( 255): [thias] in texas alt init
I//system/bin/hciattach( 255): [thias] in texas alt init while loop
cmd:1 1 10 0
I//system/bin/hciattach( 255): [thias] in texas alt init
read_hci_event
I//system/bin/hciattach( 255): [thias] read_hci_event
I//system/bin/hciattach( 255): Initialization timed out.
I/logwrapper( 255): /system/bin/hciattach terminated by exit(1)


The init.trout.rc file contains the following:
service hciattach /system/bin/logwrapper /system/bin/hciattach \

-n -s 115200 /dev/ttyHS0 texas 4000000 flow
user bluetooth
group bluetooth net_bt_admin
disabled

[Thias]

My mistake... or should I say "the way services are started"
mistake ;-)
Having logwrapper defined in the rc file to debug the service ended
with hciattach started with the wrong parameters:
"flow" was no longer considered an arg....
Well, everything is now back to normal on a BT point of view!