[Galaxy S 4 i9505 Original Android Development] Inksu:
[MENTION=986763]peppeson[/MENTION] [MENTION=3679487]lipps[/MENTION] [MENTION=4483204]kwert[/MENTION]

This is going to be a slightly long post. :) I started digging in to the Bluetooth problem, because it's been bothering me since, well, forever, both on Galaxy S4 (I9505) and S2 (I9100). Turns out its quite a mess with multiple moving parts, so to speak.

First thing I found is that the Broadcom vendor library for Bluetooth is missing an implementation for a function called "ssr_cleanup". Our S4 uses Broadcom, so this is definitely an issue. The implementation is missing all the way upstream in AOSP sources.

File in question: https://github.com/CyanogenMod/android_hardware_broadcom_libbt/blob/cm-12.1/src/bt_vendor_brcm.c (Google: https://android.googlesource.com/pl...libbt/+/android-5.1.1_r4/src/bt_vendor_brcm.c)

This missing function causes the following error in the log:

E/bt-hci ( 3577): Num consecutive HCI Cmd tout =2 Restarting BT process
E/bt-btif ( 3577): bte_ssr_cleanup
F/libc ( 3577): Fatal signal 11 (SIGSEGV), code 1, fault addr 0x0 in tid 9919 (bluedroid wake/)

I did my own implementation for this, mimicking the ssr_cleanup in Qualcom BT vendor lib. Compiled, replaced /system/vendor/lib/libbt-vendor.so and "Fatal signal 11" disappeared from the logs. Just as expected.

However, this is NOT what causes the random BT disconnects. ssr_cleanup is just what happens after BTU HCI commands timeout twice consecutively.

When BTU HCI commands time out twice consecutively, the following takes place:

ssr_cleanup is called

wait 20 milliseconds

"Killing the process to force a restart as part of fault tolerance" (i.e. the Bluetooth process is killed)

So, just to test, I removed killing of the Bluetooth process from the code. Compiled, replaced system bluetooth.default.so, and ssr_cleanup/killing the process no longer happens.

Of course, this didn't help, because things have already gone wrong when the HCI commands are timing out.

As a note: at this point, the Bluetooth connection was stable for a random length of time (first test 3 hours, this morning a few minutes). Once the HCI commands start timing out, the connection will become unstable, possibly disconnect from my computer/car's handsfree, and it will remain so until Bluetooth is restarted. Of course, with the modifications I had implemented, the BT process was not automatically killed/restarted.

I googled for "BTU HCI command timeout", and found that it's a common problem for at least Samsung Galaxy S3, Nexus 5, and HTC One. On StackOverflow, somebody commented that: "Of note, with specific code, the Galaxy S4 will automatically reconnect when this occurs, leading us to believe there is an issue in the BLE stack that Samsung identified and developed custom handling for." So Samsung may have implemented a way of quickly restarting the BT process without interfering with the ongoing connections. I have noticed when using I9505 GPE 5.0.1 that sometimes the BT connection becomes unresponsive for a second or two, but then just resumes without disconnecting.

So what this boils down to is:

We need to find out why BTU HCI commands are timing out, and can we avoid it?

Figure out how to recover from this situation without breaking the Bluetooth connections

Or at least quickly connect/disconnect when faults occur

Before these problems are figured out, I doubt that CM or AOSP will have reliable Bluetooth on Galaxy S4.

Bluetooth works just fine for me on stock TW or GPE roms, but I really like CM much more because of its smoothness and functionalities...

I have thought of replacing the CM Bluetooth with GPE implementation. However, I do not have the skills for that. Simply replacing the BT-related .so and .apk files ended up in loads of FCs.

[MENTION=5464206]AntaresOne[/MENTION] Any idea how to start fixing this BT?