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

Search This thread

shimodax

Member
Mar 3, 2015
24
23
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).
 
Last edited:

kaputme

Member
Jul 29, 2015
6
0
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
 

kaputme

Member
Jul 29, 2015
6
0
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
 

kaputme

Member
Jul 29, 2015
6
0
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

Senior Member
Jan 31, 2008
1,726
791
Google Pixel 8
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.
 

Cavechild

Member
Mar 10, 2015
6
0
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

Senior Member
May 14, 2008
530
367
35
South East London
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...
 
Last edited:
  • Like
Reactions: Bimmer_TR

shimodax

Member
Mar 3, 2015
24
23
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

Member
Mar 3, 2015
24
23
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. :D

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

Member
Mar 3, 2015
24
23
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.
 
Last edited:

Cavechild

Member
Mar 10, 2015
6
0
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:
Code:
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

Member
Mar 3, 2015
24
23
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

Member
Mar 10, 2015
6
0
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

Member
Mar 3, 2015
24
23
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.
 
Last edited:
  • Like
Reactions: Cavechild

Cavechild

Member
Mar 10, 2015
6
0
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

Member
Apr 25, 2006
7
0
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 :D.
 

dontpannic

Senior Member
May 14, 2008
530
367
35
South East London
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

Member
Sep 23, 2010
5
2
Google Pixel 3
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.
 
Last edited:
  • Like
Reactions: Cavechild

Cavechild

Member
Mar 10, 2015
6
0
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

Member
Sep 23, 2010
5
2
Google Pixel 3
@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

Member
Mar 10, 2015
6
0
@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

New member
Nov 20, 2011
2
0
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

Senior Member
Apr 20, 2010
156
16
Sydney
www.utterancesofageek.com
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.
 
Last edited:

Top Liked Posts

  • There are no posts matching your filters.
  • 7
    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).
    3
    Android 7.0 on Nexus 5X

    Alright Nexus 5X Android 7.0 owners, I've figured this out.

    So, between Android 6.0 and Android 7.0, as mentioned in my last post, the libraries were moved around. The offending Broadcom code is now compiled into libbt-bta.a, which is in turn compiled statically into bluetooth.default.so. Unfortunately, in the process, all of the symbols from the code are lost and it's difficult to follow.

    Also in the process of static linking, the way the elf section with the static library is included makes it difficult to view in objdump, as noted in my previous comment. The magic lies in forcing thumb mode:

    Code:
    objdump -d --disassembler-options=force-thumb bluetooth.default.so

    Without symbol names, it's still hard to follow, so I compiled my own AOSP and ran objdump on the raw libbt-bta.a with the symbol names to follow the code.

    After all that, I found the two offending bytes to replace with a no-op:

    Code:
    000191E0   B0 B1 B4 F8  44 12 99 B9  [COLOR="Red"]00 89[/COLOR] 0F E0  00 27 10 E0

    becomes:

    Code:
    000191E0   B0 B1 B4 F8  44 12 99 B9  [COLOR="Green"]00 BF[/COLOR] 0F E0  00 27 10 E0

    So, there you have it. I put up my copy of the binary as well, here.

    In the end, the solution is the same as comment #37.

    The Android 6.0 fix worked with the same bluetooth.default.so being used throughout the update builds, hopefully the same will be true for Android 7.0.

    Cheers,
    --Pat
    2
    Nexus 5X and Android 6.0 Stock.

    Hello,

    After some analysis and then consultation with shimodax, I've found a recipe that works with stock Android 6.0 on my Nexus 5X.

    I need to preface this by saying that the hard part with getting this working was:
    1. The need to get a USB Type-C cable
    2. Waiting for a relatively safe rooting method for Android M

    Without further ado, here are the magic bytes that work for me (hexedit is a good tool to apply this change):

    Original:
    Code:
    00073CA0   B4 F8 64 12  89 B9 [COLOR=Red]03 89[/COLOR]  0D E0 40 F2  02 31 61 F0
    Modified:
    Code:
    00073CA0   B4 F8 64 12  89 B9 [COLOR=Green]00 BF[/COLOR]  0D E0 40 F2  02 31 61 F0
    Here are the details of the methodology:

    The patch to work around the issue includes commenting out an assignment made in a function called bta_ag_sdp_find_attr() (highlighted):

    Code:
    (...)
            /* get features if HFP */
            if (service & BTA_HFP_SERVICE_MASK)
            {
                if ((p_attr = SDP_FindAttributeInRec(p_rec, ATTR_ID_SUPPORTED_FEATURES)) != NULL)
                {
                    /* Found attribute. Get value. */
                    /* There might be race condition between SDP and BRSF.  */
                    /* Do not update if we already received BRSF.           */
    [COLOR=Red]                if (p_scb->peer_features == 0)
                        p_scb->peer_features = p_attr->attr_value.v.u16;[/COLOR]
                }
            }
            else    /* HSP */
            {
                if ((p_attr = SDP_FindAttributeInRec(p_rec, ATTR_ID_REMOTE_AUDIO_VOLUME_CONTROL)) != NULL)
                {
    (...)
    Obviously, code can't be commented out in an object that's already compiled. Therefore, the instructions themselves need to be counteracted.

    I found the code point by using ARM gcc tools to decompile bluetooth.default.so, using the following command:

    Code:
    objdump -d bluetooth.default.so
    I could then find the function and the offending line (highlighted):

    Code:
    00076c00 <bta_ag_sdp_find_attr>:
       76c00:       e92d 41f3       stmdb   sp!, {r0, r1, r4, r5, r6, r7, r8, lr}
       76c04:       f011 0740       ands.w  r7, r1, #64     ; 0x40
       76c08:       4604            mov     r4, r0
    (...)
       76c9a:       f061 fd48       bl      d872e <SDP_FindAttributeInRec>
       76c9e:       b1a0            cbz     r0, 76cca <bta_ag_sdp_find_attr+0xca>
       76ca0:       f8b4 1264       ldrh.w  r1, [r4, #612]
       76ca4:       b989            cbnz    r1, 76cca <bta_ag_sdp_find_attr+0xca>
    [COLOR=Red]   76ca6:       8903            ldrh    r3, [r0, #8][/COLOR]
       76ca8:       e00d            b.n     76cc6 <bta_ag_sdp_find_attr+0xc6>
       76caa:       f240 3102       movw    r1, #770        ; 0x302
       76cae:       f061 fd3e       bl      d872e <SDP_FindAttributeInRec>
    The 0x8903 instruction was then replaced with 0xbf00, a no-op, making the if statement good as commented out.

    For some reason the addresses in the objdump do not match the offsets of the actual binary file, I'm not sure why. But finding the byte sequence was trivial.

    Hope this helps others.
    1
    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...
    1
    I'm the original poster of this solution. With a new phone and Android 8 I decided to not try to patch the library again, but instead fix this once and for all on the hardware level.

    You can change the so called ULF in the car (in an E46 facelift model this is about 20-30 minutes work), it had just been unclear, which ULFs work.

    Buying a new latest-gen from BMW sets you short north of 400 dollars. There's also a post on the internet that says a 13th gen ULF is required.

    However, I found one post in a German forum from someone who said, that an ULF with BMW part number 6955522 (or 84-21-9-6955522) would work (this is HW.Rev.10, SW-Rev.71). These can occasionally be found on Ebay for less than $100.

    I can't confirm the above first hand althouth the poster sounded credible. However, when shopping for an ULF on Ebay I found a later model (6969268, Hw-Rev.10, Sw-Rev.72) and can confirm it works with stock Android 8. Mine is a 2004 E46 with Navi-Pro.

    For comparison, my earlier ULF 945387 Hw-Rev.09, Sw-Rev.66) did not work.