[Q&A] Lollipop BMW E46 Carkit Bluetooth Problem (patching bluetooth.default.so))

[shimodax]

Hello Bimmers/BMWers and others who are suffering from old cars vs. new Android!

IMPORTANT EDIT: Since this solution no longer applies to current Android versions, consider Replacing the ULF/Bluetooth Module or see this thread which has pre-built Google-Pixel binaries.


Background: With Android 4.2 Google introduced a new Bluetooth stack which broke bluetooth connections with some older car kits (see the comment in https://code.google.com/p/android/issues/detail?id=41625 ... it is for the BMW E46 , but this also affects other BMW series with the same old Bluetooth ULF, like E39, older X3, X5 (E83) and Z4 and probably also some Audi and VW). The problem this addresses, is a bluetooth disconnect within 5 seconds after pairing.

I'm the original submitter of that patch to Google AOSP which was ignored by Google but subsequently included into CyanogenMod (https://android-review.googlesource.com/#/c/48164/ ) and with purchasing a new new phone (a Moto X 2 2014 with Lollipop) I had to revisit the issue (my car is still the same BMW E46).

This binary patch applies to the Moto X 2 (2014) Lollipop 5.0 bluetooth library, but probably the same will work for Android 4.2.2, 4.3, 4.4 and other phones too (the bluetooth C source code in that location is still unchanged since android v4.2, see the posts linked in step 4 below)

Essentially I found that it is possible to patch the bluetooth lib on the phone directly without a complete android build environment (I had tried a full rebuild too, but was unable to get my self-compiled bluetooth library in the Moto X ... if you have a Nexus phone or if you can compile Android yourself, using the source patch is probably easier)

Here are the steps (I'm keeping them somewhat vague to deter noobs from trying to tinker with the files):

To make Android work with those older BMW car kits, it is necessary to modify a behavior of bluetooth in some minor way. This obviously requires a rooted device.

The file in question is /system/lib/hw/bluetooth.default.so

Step 1 (make a backup):
run adb shell and copy /system/lib/hw/bluetooth.default.so to /sdcard/bluetooth.default.so.orig
A backup of the whole system (TWRP or similar) will be a good idea too.

Step 2 (disable bluetooth and download the file to patch to your computer):
On the phone go to settings and turn bluetooth off
Issue: adb pull /system/lib/hw/bluetooth.default.so bluetooth.default.so

Step 3 (generate a hex version of the file, linux):
xxd bluetooth.default.so >bds.txt

Step 4 (edit the hex version):
Find the byte sequence b8ed a8b1 b4f8 6032 93b9 b0f8 08e0 0de0 (it should be around offset 00a1000)
Change it to b8ed a8b1 b4f8 6032 93b9 4ff0 000e 0de0

(edit: in a post below, a user reports a slightly different byte series for a Samsung S4, so if you can't find the above sequence, try ignoring the initial b8ed and start your searching with a8b1 ... or follow suit with another post about earlier Android versions or a post about a LG G3).

Step 5 (create a binary version of the patched file):
xxd -reverse bds.txt > bluetooth.default.so.patched

Step 6 (upload patched binary to phone):
Issue adb push bluetooth.default.so.patched /sdcard/
Remount the /system partition as rw
Use adb shell, then su and cp /sdcard/bluetooth.default.so.patched /system/lib/hw/bluetooth.default.so
Then (still in the shell as su): chmod 644 /system/lib/hw/bluetooth.default.so
Verify that only those four bytes changed: cmp -l /system/lib/hw/bluetooth.default.so.orig /system/lib/hw/bluetooth.default.so
Verify permisssions (ls -l /system/lib/hw and check if the new file has same flags as the rest (rw--r---r---)).

Step 7 (enable bluetooth again):
on the phone set Settings > Bluetooth : on
Make sure it stays on (and doesn't give an error, otherwise make sure the file has correct permissions and/or copy the original file back from bluetooth.default.so.orig)

Step 8 (check with car):
Take phone to the car, pair the device to the car-kit.
It should stay paired and making calls and access to the phone address register should work.

Done.


EDIT: In a later post a user says there is also a file named /etc/bluetooth/auto_pair_devlist.conf which has a number of devices blacklisted and to make it work, some entries need to cleaned (commented out or deleted).

 

[kaputme]

QUOTE=Firespit;75072426]I'm going to try to eliminate the ulf and mount a tcu ....

[/QUOTE]

Did you install a TCU?? Is it working??

Sent from my SM-G970F using Tapatalk

 

[Orphee]

I suggest all of you to look at bluebus.dev

 

[kaputme]

Ah, its so expensive and i don't need audio streaming, just want Bluetooth Handsfree.
However i don't think getting it shipped to Germany will help.

Sent from my SM-G970F using Tapatalk

 

[Orphee]

I live in France and ordered 2.

 

[kaputme]

What did it cost you altogether??

If you don't want to reveal here can you PM me?

Sent from my SM-G970F using Tapatalk

 

[Orphee]

You can simulate price with shipping yourself directly on the website, aroud 260$ for one with shipping.
Some more if you need/want plug and play adaptor depending of your car.

 

[kaputme]

Thanks

Sent from my SM-G970F using Tapatalk

 

[Cavechild]

That's a fantastic bit of work in tracking that one down :good:
Do you know if the patch you submitted for CM11 could be integrated into the CM12 branch?

Andy.

 

[dontpannic]

You are an absolute legend.

I was looking for ways on how to decompile the bluetooth.default.so from an 'off the shelf' ROM (I'm not too hot on compiling from source yet!) and this post was enough. My phone now connects to my BMW E46's bluetooth ULF and works absolutely perfectly. Thankyou!

EDIT 1: Just for further info - I'm using a Galaxy S4 LTE (I9505) and the byte sequence was slightly different.
Find the byte sequence 9aeb a8b1 b4f8 6032 93b9 b0f8 08e0 0de0 (starting around offset 00a2490)
Change it to 9aeb a8b1 b4f8 6032 93b9 4ff0 000e 0de0

EDIT 2: In fact, it seems like you can probably start from a8b1 b4f8...

 

[shimodax]

That's a fantastic bit of work in tracking that one down :good:
do you know if the patch you submitted for CM11 could be integrated into the CM12 branch?

Technically there should be no problem using the same source patch for CM12 because the original source in Android is still the same. But I don't know if they will carry it forward or how long.

 

[shimodax]

You are an absolute legend.

I was looking for ways on how to decompile the bluetooth.default.so from an 'off the shelf' ROM (I'm not too hot on compiling from source yet!) and this post was enough. My phone now connects to my BMW E46's bluetooth ULF and works absolutely perfectly. Thankyou!

EDIT 1: Just for further info - I'm using a Galaxy S4 LTE (I9505) and the byte sequence was slightly different.
Find the byte sequence 9aeb a8b1 b4f8 6032 93b9 b0f8 08e0 0de0 (starting around offset 00a2490)
Change it to 9aeb a8b1 b4f8 6032 93b9 4ff0 000e 0de0

EDIT 2: In fact, it seems like you can probably start from a8b1 b4f8...

Cool ... I didn't expect anyone else (besides me) to to tinker with the issue in that depth.

You're right, you can probably ignore the first two bytes (I made an edit to my original post). Starting there was a rather arbitrary decision on my side, it's just important that sequence around the modified bytes exists in the library only once.

Enjoy!

 

[shimodax]

I had a bit of free time and tinkered a bit with builds of the library in earlier versions of Android (4.4. and 4.3. Nexus builds).

Note: this is experimental, I don't have a Android 4.x device anymore, so this may or may not work.

This is a diff of a bluetooth.default.so file (hex dump via linux xxd command as described above) for an Android 4.4. Nexus 5 build:

007b8b0: 5a22 27f0 e4ff 2846 57b1 40f2 1131 27f0
007b8c0: 1bfe 00b9 14e0 b4f8 5812 89b9 0389 0de0 (original)
007b8c0: 1bfe 00b9 14e0 b4f8 5812 89b9 0023 0de0 (modified)
007b8d0: 40f2 0231 27f0 10fe 50b1 007a b4f8 58e2


So, the following would lead with reasonable certainty to the location that needs to be changed (I had a look at an old Nexus i9250 build with Android 4.3 from my previous phone and it matched):

Find: 00b9 14e0 b4f8 5812 89b9 0389 0de0 40f2 0231
Change: 00b9 14e0 b4f8 5812 89b9 0023 0de0 40f2 0231

Probably even the following will do (assuming the find-sequence appears only once in the file)

Find: 5812 89b9 0389 0de0
Change: 5812 89b9 0023 0de0

Again this is speculative, but if someone does try it, let us know the results.

EDIT: one user reports here that the short sequence worked.

 

[Cavechild]

Hi,
I had a go at patching the bluetooth.default.so on my LG G3.
Here's the closest match I could find to your original byte sequence along with what I patched it to:

A8B1 B4F8 6[COLOR="Red"]4[/COLOR]32 93B9 [COLOR="lime"]B0F8 08E0[/COLOR] 0DE0
A8B1 B4F8 6[COLOR="red"]4[/COLOR]32 93B9 [COLOR="Lime"]4FF0 000E[/COLOR] 0DE0

The numbers in green are the matching sequence from your original patch, there was however a difference with your byte sequence that I highlighted in red (6032 > 6432).
I don't know how important that is, but the patch as I made it didn't seem to make any difference to the phone/car behaviour.
They still connect ok and the address book transfers fine, everything is hunky dory until I make a call at which point the bluetooth disconnects and the audio reverts to the phone.

The file is in the original place with the original file permissions too.

Any ideas?

Andy.

 

[shimodax]

I don't know how important that is, but the patch as I made it didn't seem to make any difference to the phone/car behaviour.
They still connect ok and the address book transfers fine, everything is hunky dory until I make a call at which point the bluetooth disconnects and the audio reverts to the phone.

This is probably simply a different problem. The problem the original patch adresses, happens only at bluetooth-paring (... a disconnect within 3-5 seconds). Your patch probably fixed that behavior, but I guess your car/phone combo suffers from a different one.

 

[Cavechild]

This is probably simply a different problem. The problem the original patch adresses, happens only at bluetooth-paring (... a disconnect within 3-5 seconds). Your patch probably fixed that behavior, but I guess your car/phone combo suffers from a different one.

Bugger, I have a 2005 E46 With Business Radio (the one that plays MP3s) and a ULF that I don't know the model number of. Worked perfectly with my Galaxy S3 running JellyBean.

How did you go about debugging the issue as I'm tempted to have a pop at recompiling the .so.

 

[shimodax]

Bugger, I have a 2005 E46 With Business Radio (the one that plays MP3s) and a ULF that I don't know the model number of. Worked perfectly with my Galaxy S3 running JellyBean. How did you go about debugging the issue as I'm tempted to have a pop at recompiling the .so.

Almost 99.9% a different problem, because this problem was introduced to Android with 4.2 (i.e. stock 4.3 Jelly Bean would not have worked either).

Initially (when researching the problem the very first time in 2012 with Navi-Professional), I started looking at the system log (adb logcat or via catlog app) and was looking for bluetooth related output.

 

[Cavechild]

Almost 99.9% a different problem, because this problem was introduced to Android with 4.2 (i.e. stock 4.3 Jelly Bean would not have worked either).

Initially (when researching the problem the very first time in 2012 with Navi-Professional), I started looking at the system log (adb logcat or via catlog app) and was looking for bluetooth related output.

Thanks, I'll give the catlog app a try and see what pops out :good:

 

[xrwz]

I had a bit of free time and dug around a bit more with earlier versions of Android (4.4. and 4.3. Nexus builds).

Note: this is experimental, I don't have a Android 4.x device anymore, so this may or may not work.

This is a diff of a bluetooth.default.so file (hex dump via linux xxd command as described above) for an Android 4.4. Nexus 5 build:

007b8b0: 5a22 27f0 e4ff 2846 57b1 40f2 1131 27f0
007b8c0: 1bfe 00b9 14e0 b4f8 5812 89b9 0389 0de0 (original)
007b8c0: 1bfe 00b9 14e0 b4f8 5812 89b9 0023 0de0 (modified)
007b8d0: 40f2 0231 27f0 10fe 50b1 007a b4f8 58e2


So, the following would lead with reasonable certainty to the location that needs to be changed (I had a look at an old Nexus i9250 build with Android 4.3 from my previous phone and it matched):

Find: 00b9 14e0 b4f8 5812 89b9 0389 0de0 40f2 0231
Change: 00b9 14e0 b4f8 5812 89b9 0023 0de0 40f2 0231

Probably even the following will do (assuming the find-sequence appears only once in the file)

Find: 5812 89b9 0389 0de0
Change: 5812 89b9 0023 0de0

Again this is speculative, but if someone does try it, let us know the results.

Thanks shimodax, I've done the patching for Galaxy S4 Android 4.3 Omega v19 custom rom (searched for just 5812 89b9 0389 0de0 as the previous bytes were different in my file, bplus.default.so - I suspect the same file will be there in an original Samsung rom as Omega is based on that) and tested it and IT WORKS so here is the confirmation. Now my E83 with 4th gen ULF happily stays connected to the phone and I can do pretty much everything I used to be able to do with previous versions of Android. Thank you again for all the info, I can now avoid getting a ticket .

 

[dontpannic]

Interestingly - although this was integrated into CM sources - my phone running on CM based ROM's still exhibits exactly the same behaviour. Obviously the bluetooth stack is different so modifying it in the same way as above is not the same procedure.

 

[sratxp]

I have similar problem as Cavechild on my e46. with Moto G (2013)

Everything is hunkydory until I try to make a call. The phone simply drops the connection once audio has to be transfered. Interesting is that the first time I paired it everything worked flawlessly I could even make a call. I tried rebooting, repairing but I could never do a call again.

I had similar problems with stock 4.4. Then I noticed that I only had problems if I turned on my car while my phone was still connected to my bluetooth headset. Once I ensured that my phone is not connected to any bluetooth devices when I turn on my car everything worked normaly. Unfortunately that doesn't help with CM 12.


Update:
I found a workaround. Let your phone connect to your car. Then go in the Bluetooth menu of your phone, open the properties of the BMW Bluetooth device and remove the checkbox for Audio - Telephone. This disconnects your phone. Go out of the properties, then open them again and enabled the profile you deactivated. Your phone should connect to your car again. Now Bluetooth should work.

 

[Cavechild]

I have similar problem as Cavechild on my e46. with Moto G (2013)

Everything is hunkydory until I try to make a call. The phone simply drops the connection once audio has to be transfered. Interesting is that the first time I paired it everything worked flawlessly I could even make a call. I tried rebooting, repairing but I could never do a call again.

I had similar problems with stock 4.4. Then I noticed that I only had problems if I turned on my car while my phone was still connected to my bluetooth headset. Once I ensured that my phone is not connected to any bluetooth devices when I turn on my car everything worked normaly. Unfortunately that doesn't help with CM 12.


Update:
I found a workaround. Let your phone connect to your car. Then go in the Bluetooth menu of your phone, open the properties of the BMW Bluetooth device and remove the checkbox for Audio - Telephone. This disconnects your phone. Go out of the properties, then open them again and enabled the profile you deactivated. Your phone should connect to your car again. Now Bluetooth should work.

Nicely done, that's fixed it for me too. My current solution is a combination of "Tasker" & "Bluetooth Autoconnect".

Here's roughly what I have setup in Tasker:

EVENT: Bluetooth Connection PBAP - (Phonebook).
TASK:

• wait 1 second
• disconnect call audio
• wait 1 second
• connect call audio
• beep

This works pretty well but I'm sure it could be improved upon. I specify the car's bluetooth device for all the operations and hook off the phonebook connection because I wasn't sure if hooking off any other connections would result in getting stuck in an endless loop. The only downside with this is that the phone makes two PBAP transfers, one for the phonebook and one for any contacts on the sim card (even if there aren't any).

I tried to do the same in Macrodroid, but the bluetooth call audio support doesn't seem to work with my setup. Which is a shame as Macrodroid is much nicer to use than Tasker.

 

[sratxp]

@Cavechild
Thanks, I was thinking about trying to do this more or less automatically but I simply had no time to look at it so far. I never installed tasker as I had never use for it so far but I'll give it a try. I though about using the CM profiles for automisation but they are not powerfull enough to do this. What about having a profile CAR and use this as a trigger for tasker?

Anyway, it would be nice if somebody would fix this problem in the code directly.

 

[Cavechild]

@Cavechild
Thanks, I was thinking about trying to do this more or less automatically but I simply had no time to look at it so far. I never installed tasker as I had never use for it so far but I'll give it a try. I though about using the CM profiles for automisation but they are not powerfull enough to do this. What about having a profile CAR and use this as a trigger for tasker?

Anyway, it would be nice if somebody would fix this problem in the code directly.

If the powers that be are unwilling to add this behaviour as the default then it would make sense to add it as a compatibility option on each specific connection?

To be honest I still believe this issue is a bug relating to part of the initial bluetooth connection flow as we have a work-around that bypasses the problem.

Andy.

 

[LibertyPrime]

I'm currently using a Z3, and for those who are unaware, unlocking the boot-loader makes the camera and some other features take a nosedive, so I've had to stick to rooted stock. This fix worked for me, so that was great, but I've got the same issue as above with having to cycle Bluetooth on and off for it to handle calls properly. Anyone know of a solution outside of setting up a toggle?

 

[Psychoticus]

So I've been unable to replicate this using a OnePlus One running CM OS 12 (CM12 basically). I can not find the hex sequence in any iteration.

I noticed that december last year the patch no longer merges with AOSP, could this be an issue?

Deckard Autoverifier
Dec 31 2:14 PM

Patch Set 1: Verified-1
This is an automated message from the Deckard Autoverifier.
Patchset merges but does not build in AOSP.
The following snippet of `make` output may point you in the right direction:
find: `phone/java': No such file or directory
find: `phone/java': No such file or directory
find: `dummy': No such file or directory
external/bluetooth/bluedroid/bta/./ag/bta_ag_sdp.c: In function 'bta_ag_sdp_find_attr':
external/bluetooth/bluedroid/bta/./ag/bta_ag_sdp.c:374:17: error: implicit declaration of function 'APPL_TRACE_DEBUG1' [-Werror=implicit-function-declaration]
APPL_TRACE_DEBUG1("bta_ag_sdp_find_attr: peer_attr 0x%x", p_attr->attr_value.v.u16);
^
external/bluetooth/bluedroid/bta/./ag/bta_ag_sdp.c:375:17: error: implicit declaration of function 'APPL_TRACE_WARNING0' [-Werror=implicit-function-declaration]
APPL_TRACE_WARNING0("bta_ag_sdp_find_attr not using value as p_scb->peer_features");
...

If your patchset has a dependency in a separate project, please ensure that
both changes are uploaded with the same Change-Id.

EDIT: Turns out the file was corrupted as I copied the file again and found the sequence. Modified as per instructions and am able to make calls etc. I have to use the workaround stated earlier about toggling the bmw bt mic.

 

[shimodax]

I noticed that december last year the patch no longer merges with AOSP, could this be an issue?

Not sure if that affects CM, but in any case, the patch still merges if the APPL_TRACE_XXXX commands are removed (they are just entries to the syslog and don't affect the working of the patch)..