[Spirit FM] mikereidis:
Hi. This thread might give you some clues: http://xdaforums.com/showthread.php?t=676212

My understanding is also limited, and I only know a little bit about btld because I've looked at the strings inside and I've attempted to use the FM features, with no success yet.

Are your problems with HTC Bluetooth limited to stock or stock derived ROMs with the proprietary Broadcom BT stack ? IE, does your code work OK on CM ROMs on HTC devices, or any other ROMs using the open source Bluez stack (as opposed to proprietary btld etc) ?

For Broadcom, my app either uses the open source Bluez Bluetooth stack HCI apis via the Bluetooth socket (if it's present and BT is on or if present and UART won't work), or it goes straight to the UART and does everything itself.

In the former case, it just uses the standard Android APIs to detect if Bluetooth is on, and if need be uses the standard Android APIs to turn it on. So it doesn't directly do anything with rfkill, or patchram or hciconfig or hciattach. Android does that automatically.

In the latter case of UART mode, my app writes 1 to rfkill (to turn the UART etc. on), does the same things that patchram does pretty much, and then uses the available HCI interface by writing/reading the UART, without any need for hciconfig or hciattach. Of course this means that BT APIs are not available to other apps.

So our apps approach things differently; mine doesn't really "bring up the HCI interface" for use by other apps.

If I recall correctly, for TI chips, hciattach is used for both the open source Bluez stack, as well as the proprietary TI stack.

For Broadcom chips, brcm_patchram_plus is used as an alternative to hciattach. The code comments for patchram indicate an intended move to using hciattach, but those comments are rather old now, and it doesn't appear Broadcom will ever add the needed code to hciattach.

And BTW, the patchram *.HCD file is sort of like a firmware file. Apparently, it just "patches the RAM" of the absolutely read-only firmware in Broadcom chips, and this is similar to a firmware update.

I know btld is a rather large daemon, but I'm not entirely sure just what it replaces in the Bluez stack, and I've found relatively little documentation for the Bluez stack, so even what it does is a bit of a mystery to me. But there is certainly an FM API in btld, and TI's equivalent btipsd, and Bluez does not have that. The extra features in the proprietary stacks are why they are used instead of Bluez I would guess.

My impression is that manufacturers get at least part of the source code for the Broadcom proprietary BT stack. So if they wish, they can customise it, although most may change very little if anything. Since the method of instantiating the proprietary FmReceiver class is different on HTC devices, than LG and Samsung, my guess is that HTC has customised the code more than others.

One of the places that customisation happens is in system/lib/libbluedroid.so . I don't have any HTC device with Broadcom, but I do have some files. If I run:

strings desirehd/cm/system/lib/libbluedroid.so | wc

strings desirehd/stock/system/lib/libbluedroid.so | wc

I see 104 lines for the CyanogenMod / Bluez version and 197 for the Stock / Broadcom proprietary version. Examining the strings might give you some ideas. And if you can call a function in this, or some other library, instead of doing your own HCIDEVUP ioctl, perhaps that would work.