EDIT: See this for v2.0.12: http://forum.xda-developers.com/show...&postcount=225
... A new version (not as wonderful as thought): v2.0.11. Not on the Market; only at the link below: (Now my focus is back to the audio issues.)
Please try this version and let me know how it works for you. If you just install the package file and not the other 2 binaries, it should work as before, except: you must turn Bluetooth on manually before starting the app.
Major features of this version:
- Requires root: Improved HCI UART support to work around the proprietary Broadcom BT stack and provide much better speed and CPU efficiency. Now uses network sockets to avoid/fix permissions issues.
- Requires root: Direct HCI access via HCI sockets as a faster and more efficient method than using hciitool. Supported by same daemon (bcprp) as for HCI UART support.
- No longer writes constantly to SD Card (or worse internal storage). If used, the hcitool output now goes straight to a pipe in memory only.
- Service and app are much better behaved and can be completely terminated without crashing. App and service now completely terminate when power is switched off. This allows changing the HCI access mode between the 3 methods without rebooting.
- RDS and other event processing now pause when the screen is turned off or the app otherwise becomes non-visible. This should improve battery life.
The daemon modes (Direct HCI and HCI UART) require installing bcprp and bcfm to the /system/bin directory. They also both require SU root and an installed SDCard (for now at least). Direct HCI mode works on Broadcom or TI chips, but HCI UART mode is for Broadcom only at this time. Note that the first time you use these modes you will be prompted by SuperUser.apk to allow access. This will often create timing issues that should be solved by a reboot at worst.
For Direct HCI mode, the bcfm file can be used as is for either TI or Broadcom. For HCI UART mode the bcfm file must be edited. Check your /init.?.rc file where ? is name of your device. For example on my device it's /init.thunderg.rc. Look at the line starting with "service hciattach". On mine its:
service hciattach /system/bin/brcm_patchram_plus -d --baudrate 3000000 --patchram /system/bin/BCM4325D1_004.002.004.0218.0248.hcd --enable_hci /dev/ttyHS0
If yours actually runs the real hciattach, this approach might still work. Please let me know. Take those parameters and edt them into the bcfm file, but be SURE to remove the "--enable_hci" option. If you leave it in, the bcprp acts exactly like the original brcm_patchram_plus (more or less) and will try to start bluetooth.
adb push bcprp /system/bin/bcprp
adb push bcfm /system/bin/bcfm
adb shell chmod 777 /system/bin/bcprp
adb shell chmod 777 /system/bin/bcfm
Install the app:
adb install -r FMRadio_v2011.apk
Start the app, and hopefully after 5-20 seconds it should start and work. You will be prompted for SU to start the daemon as root. If it doesn't work the first time, try re-booting. Check adb logcat for clues if it doesn't work.
One possible issue is permissions, although the new network socket API shouldn't have the issues that Unix sockets have.in /dev/socket. My CM port doesn't seem to have this issue, but I've seen it before. Possible solution:
adb shell chmod 777 /dev
adb shell chmod 777 /dev/socket
In order to use the Direct HCI access mode, you must rename hcitool, assuming it works for you. I use:
adb shell mv system/xbin/hcitool system/xbin/hcit
Direct HCI access likely won't work unless hcitool also works, so it's not a solution for bad BT stacks.
I am able to switch back and forth between modes. To do so, turn the radio power off, then enable or disable bluetooth as desired. Restart the app and if BT is off it should go into HCI UART mode. Turn power off again, turn BT on and Direct HCI mode should be enabled.
Which mode is best ?
- The original HciTool mode is slowest/least efficient, requires BT on and works without root.
- Direct HCI access is much better, but requires BT on and a stack that supports HCI via bluetooth sockets.
- HCI UART mode is the fastest, and I think least prone to bogus data. It should be most CPU and battery efficient. Hopefully it should work on all Broadcom devices, even those with the proprietary BT stack. BUT it requires BT off.