Help with bluetooth! hci_get_route returns ERNODEV
- Thread starter pikipirs
- Start date
I have 2.2 and tried to get it working with simplewiicontroler und wiicontrollerDemo but both didnt work. Same Problem as usual. Any Developers here who had a deeper look at the new 2.2 Bluetooth Drivers?
I also contacted HTC Support in Germany they told me
"SPP is now supported on Android 2.2 on the Desire"
Does that mean the App-Developers can fix the Problem now?
I also contacted HTC Support in Germany they told me
"SPP is now supported on Android 2.2 on the Desire"
Does that mean the App-Developers can fix the Problem now?
I also have a Desire HD, and get the error, Damn HTC. Would really love to have the wiimote connected. My motoracer2 requires constant use of the r2 button which is really awkward.
I'm having these issues on my stock Thunderbolt... not hoppin on the initial root bandwagon yet, keepin an eye on this thread
I"m just going to guess nothing is actually being worked on I would be perfectly ok with moding my bluetooth library anything that would allow me to keep my current stock rom would be awesome.
I have looked into this problem a bit and this is what I have found.
The common thing I found between the Samsung and HTC phones where hci_get_route fails is that they all use a Broadcom BCM4329 for bluetooth.
In the source code for the Samsung Galaxy Tab it appears the reason that hci_get_route fails is that Samsung has heavily modified the Bluez stack to use code from Broadcom. They modified hci_devid to always return 0 to just name 1 change.
I tried compiling bluetooth from the Samsung source with the BT_ALT_STACK compile flag removed but that didn't work. I may try and see if I can get hci_get_route to work but the Bluez code has about zero comments so its hard to figure out whats going on.
The common thing I found between the Samsung and HTC phones where hci_get_route fails is that they all use a Broadcom BCM4329 for bluetooth.
In the source code for the Samsung Galaxy Tab it appears the reason that hci_get_route fails is that Samsung has heavily modified the Bluez stack to use code from Broadcom. They modified hci_devid to always return 0 to just name 1 change.
I tried compiling bluetooth from the Samsung source with the BT_ALT_STACK compile flag removed but that didn't work. I may try and see if I can get hci_get_route to work but the Bluez code has about zero comments so its hard to figure out whats going on.
Samsung left out a lot of the Broadcom proprietary code from the source code distribution, so you can't really see what's going on, and you can't compile a debug version. Compare the phone version of libandroid_runtime.so with the version you get if you build from source to see how much is missing (more than 200k compiled).
Even if you bypass hci_get_route and use devid=0 (which Android assumes anyway), the hci_open_dev call fails. I think it's missing some init somewhere, especially adapter_start in adapter.c. Possibly the Bluez interface is completely inactive and all the live code uses Broadcom's dtun API.
I did try using reflection to get at the raw BluetoothSocket from Java as described here but they have fenced that off too, preventing you from opening an L2CAP socket:
ERROR/BLZ20_WRAPPER(20643): ##### ERROR : blz20_wrp_close: protocol BTPROTO_L2CAP not yet supported#####
where BLZ20_WRAPPER is part of Broadcom's proprietary stack.
Even if you bypass hci_get_route and use devid=0 (which Android assumes anyway), the hci_open_dev call fails. I think it's missing some init somewhere, especially adapter_start in adapter.c. Possibly the Bluez interface is completely inactive and all the live code uses Broadcom's dtun API.
I did try using reflection to get at the raw BluetoothSocket from Java as described here but they have fenced that off too, preventing you from opening an L2CAP socket:
ERROR/BLZ20_WRAPPER(20643): ##### ERROR : blz20_wrp_close: protocol BTPROTO_L2CAP not yet supported#####
where BLZ20_WRAPPER is part of Broadcom's proprietary stack.
Last edited:
Oh, goodie... a thread on the problem that's been plaguing me for months.
I wrote an FM Radio app that speaks to the TI and Broadcom combo chip FM portions via HCI. Works well on Bluez based ROMs like CyanogenMod, but no go on MANY stock ROMs with the TI or BC proprietary BT stacks.
I searched for a LONG time, combed through code and tried everything on this thread and then some. On at least one phone and ROM combo I was able to execute the HCI Get Version command (4 1), but not proprietary commands (0x3f).
I've now resorted to taking over the HCI UART and sending commands that way. It works nice but requires root and prevents normal BT.
Despite these bad stacks, there MUST be some way to do this with root at least. I'd have to presume the kernel code can send any HCI commands.
I've even thought of a serial port shim, but BT is not strictly userspace; it's in the kernel too, to support such stuff as BT sockets. I haven't looked too closely at the kernel yet, but there is surely good stuff there, possibly wrapped up in the Android security model.
I ran an hcidump tonight and it "hit me". Perhaps TI and Broadcom don't want us to have easy HCI access so that tools like hcidump can't be used to reverse engineer their precious trade secrets. They certainly don't publish their FM APIs nor I think their BT APIs.
I wrote an FM Radio app that speaks to the TI and Broadcom combo chip FM portions via HCI. Works well on Bluez based ROMs like CyanogenMod, but no go on MANY stock ROMs with the TI or BC proprietary BT stacks.
I searched for a LONG time, combed through code and tried everything on this thread and then some. On at least one phone and ROM combo I was able to execute the HCI Get Version command (4 1), but not proprietary commands (0x3f).
I've now resorted to taking over the HCI UART and sending commands that way. It works nice but requires root and prevents normal BT.
Despite these bad stacks, there MUST be some way to do this with root at least. I'd have to presume the kernel code can send any HCI commands.
I've even thought of a serial port shim, but BT is not strictly userspace; it's in the kernel too, to support such stuff as BT sockets. I haven't looked too closely at the kernel yet, but there is surely good stuff there, possibly wrapped up in the Android security model.
I ran an hcidump tonight and it "hit me". Perhaps TI and Broadcom don't want us to have easy HCI access so that tools like hcidump can't be used to reverse engineer their precious trade secrets. They certainly don't publish their FM APIs nor I think their BT APIs.
Last edited:
So any more news on this? I would love to see code to allow hid devices on sense based roms.
Sent from my ADR6400L using XDA App
Sent from my ADR6400L using XDA App
Similar threads
