[Spirit FM] mikereidis:
Status Report:

The experimental HCI UART package linked above is not on the Market. I decided it should stay out of the Market until it's better tested, fixed etc. It's v2.0.10 and signed normally so you should be able to upgrade to it from any earlier Market version.

If you are successful, I think there's a high probability you will then hit the no audio problem, although tuning, RSSI and RDS should work. See below for my plans for the "No Audio Problem".

You could try this version even if you don't need the new support if you don't mind taking a bit of risk. It should still work on TI and Broadcom devices using hcitool or btipsd_cli as before. The Broadcom seek issue should hopefully be fixed for most phones, but it's possible it may break the seek on phones like the Desire HD where it was working previously.

The app will use the new HCI UART support if, when started, bluetooth is off or inaccessible via hcitool, AND a file named /system/bin/bcfm exists. Otherwise it will try to use the normal hcitool driven code.

The bcfm shell script file starts the bcprp daemon and is started by the app using SU, so some sort of SuperUser.apk type app needs to be installed and working. In future, I am likely to add direct HCI access through Bluez libbluetooth.so to the daemon, as I did in v1 of my app. This should be faster, more efficient and more reliable than using hcitool. Occasionally, if two hcitool instances are running at the same time, bad data is returned.

It should be possible in future to switch between modes more or less on the fly, if you need bluetooth sometimes. Right now it requires a reboot, due to some bug(s) in my service code I haven't got to yet, but am hoping to start fixing right now. But in this "wonderful future" I think it may even be possible to listen to FM while some bluetooth activity is happening.

On my TI chip phone, if WiFi is on (And keeping the combo chip powered), BT can be switched off and the radio stll plays, although most controls (Except speaker/headset) will not work. Just tested on my Broadcom phone and it doesn't seem to work, but there may be a way to enable this.

Audio:

I haven't integrated my planned audio upgrades yet for support of devices with the no audio problem. For now, I need to get the service bug(s) fixed and then I can start.

What I'm planning is customisable extensions using shell scripts (or whatever) that can be created/modified to get different devices working. Currently my code more or less blindly does 3 different things to enable/disable headset or speaker audio and only one needs to be done for any given device, and I hope that they don't interfere with each other. I can't add more methods to the chain, so one needs to be selected.

So scripts or other binaries named fm_audio_disable, fm_audio_speaker and fm_audio_headset could be created and called by my app when needed. The scripts could do things like write to the HTC FM flag file, or run one of many utilities I provide, or that someone else creates, that send an ioctl or whatever to the appropriate device.

On CyanogenMod with an FM app (and some without), the Android sound APIs are used with special values for FM that most ROMs won't support. That is probably best left in the app, and the external scripts used when those Android APIs don't work.

Perhaps in future, I could add these audio switching methods to the app directly. But for now I don't personally have the resources to trouble-shoot every device audio issue, so others could help me out by learning the secrets for their device and writing scripts.

There is a complication when some sound system activities turn of FM audio and don't return it when finished. For example phone calls or notifications or media players. Hopefully though, those reconfigs can be detected, and when FM audio should be returned can be detected.