[Spirit FM] mikereidis:
v2.0.18:

http://www.mediafire.com/file/p3w4r8dfqi9zzal/FMRadio_v2018.zip

If the app is working well for you, there is no compelling reason to try upgrading to v2.0.18, unless you feel a bit adventurous.

I consider the previous 2.0.17 pretty stable; Time will tell about this version. It's late and I've likely forgotten or missed a few things.

There are quite a few changes here. Audio routing should hopefully be better, although the price paid for better compatibility with different devices is the possibility of an audio glitch while switching on or to or from headset/speaker.

For Idkidk & the Galaxy Tab, the app will put the precise RSSI value in the "adb logcat" logs every 5 seconds. Hopefully we can see if the antenna is connected at least. Values of 30-50 should be seen for strong stations with an antenna. I just tested without an antenna and unfortunately I saw 0 with a strong station. Although placing my finger over the headphone/antenna jack I got 10 and a better signal. Perhaps holding the Tab in various ways will show some signal. I also enabled PCM audio output, but I'm not sure there's an easy way to get that to the speakers.

I recommend that hcitool be renamed to hcitoo (just remove the trailing lower case 'L'). For example:

adb shell mv /system/bin/hcitool /system/bin/hcitoo

AND/OR

adb shell mv /system/xbin/hcitool /system/xbin/hcitoo

This is only needed in the HCI modes, not the UART modes, and most important on CM ROMs where the volume controls run hcitool. The problem is that the HCI events interfere and the result is loss of RDS and RSSI.

The FM chip detection and power up initialisations is almost entirely new. The APP will try the available modes in order of best efficiency. It does this first in whatever state BT power is in initially. If unsuccessful it may then toggle BT on or off as needed to retry with the new BT power state.

If power up is unsuccessful, or when power is eventually turned off, BT is reverted to the state it was in when the app/FM was last powered up..

If power up is unsuccessful you will see debug info in a dialog titled "Sorry ! Compatible FM chip not found... :(".

If power up is successful, you will see the debug info in the area used for RDS RadioText, right below the frequency indicator, at least until RDS RadioText is first processed.

This is the order the modes are attempted in:

0 - If running on an emulator. emulator mode is used.

1 - If a Texas Instruments FM chip exists with the proprietary TI BT stack, and btipsd_cli is available, the "TI BTIPSD mode" is used. Nobody but me uses this... LOL.

2 - If a Broadcom FM chip exists and SU is available and BT is off, the app internal UART mode is attempted.

3a - For Broadcom: If SU and sprtd is in executable path (eg /system/bin/sprtd), the sprtd daemon modes are attempted. If BT is on the BT socket mode is tried, and if BT is off the sprtd UART mode is tried.

3b - For TI: If SU and sprtd is in executable path, the sprtd daemon BT socket mode is attempted.

4 - If all the above is inapplicable, or fails, the hcitool mode is attempted, and this requires BT to be on. The app will work with either "hcitool" or the renamed version "hcitoo" (No L at end). I recommend hcitool be renamed hcitoo, at least for now.

If all the above fails, and if it might succeed by toggling BT power state, then BT is switched on or off and the tests/modes are attempted again.

I'll document the debug info in the next post.