This was haunting me since the release of the first Motorola Moto G and the firmware update of the Nexus 5: The Qualcomm baseband software returns QMI_ERR_ACCESS_DENIED for every request. Recent 64 bit phones seem to all suffer from this. I had no idea what I could do about that.
The problem is simply a missing setting in the baseband's NV storage!
This sounds easy to fix but it is not, at least currently. The change has to be made via the Qualcomm diagnostic interface, usually over USB. The first problem is that this port is not available in every firmware, since some manufacturers remove it from the kernel configuration. The probably best known example is the Nexus 5. The next problem is to find out how to switch the USB port on the phone to the Qualcomm diagnostic mode. This seems to be different for every phone and of course every phone needs a different Windows driver which is usually hard to find.
The last problem is that you will need proprietary Qualcomm tools. Luckily the files are available in the Internet. Be cautious not to pick one with malware! I hope I can do the communication with the installer app, but that will need a considerable amount of time.
The good news: I verified functionality with the Nexus 5 and the Moto G (1st gen). As far as I understand the change is stored in the EFS partition, i.e. you have to do the whole procedure only once and it seems to survive flashing a new firmware.
Stay tuned for detailed installation instructions for the Moto G and the Nexus 5. I have two 64 bit phones (ZTE Nubia Z9 Mini and OnePlus Two) which I will try next, I'll let you know the results.
I'm always surprised at the quality of the Bluetooth software in some phones. Some recent examples:
OnePlus 2: Phone Book Transfer
A few weeks ago I noticed that sales of my phone book app rose sharply. It wasn't too hard to find the reason: the PBAP implementation in the OnePlus 2 firmware is a total mess. I did not yet check the basic cause of the malfunction, my PC program which I use to test my app reports some low level problem. I cannot understand how this can happen. The PBAP implementation is available in source in the AOSP tree, and it already did work better! How could it get worse?
Google Nexus 5X: rSAP
Good news: the Nexus 5X supports rSAP! The bad news: it works only once, then you have to reboot your phone... To be fair, this is the first implementation of rSAP in a Google phone. But I cannot understand how a new feature could be added obviously untested.
Samsung Galaxy S6: rSAP
I finally switched to an S6 Edge because it is simply the most beautiful phone available today. Since the S6 already supports rSAP with it's stock ROM and there are no custom ROMs available, I didn't see much sense in porting my app to it.
Of course I immediately paired the S6 with my VW Premium phone and it worked. So far so good. Soon I found out that the connection takes really long (more than a minute) which I didn't remember from my Sony Xperia Z3. So I checked what would be necessary to run my app on the S6 and luckily it wasn't much. Guess what? With my app the phone connects in a few seconds. I checked the HCI logs with the Samsung rSAP and it looks like large packages get corrupted. It is very nice of the VW phone that it handles the invalid data gracefully. I remember I saw similar problems in the phone book transfer of earlier Samsung phones. Did nobody at Samsung ever notice it?
No wonder that Bluetooth has such a bad reputation...
P.S. The rSAP installer app with Samsung Galaxy S6 support will be available soon.
I also released a test version for the rSAP installer app which supports 64 bit MediaTek phones.
I released a test version for the rSAP installer app which supports 64 bit Qualcomm phones.
The MediaTek version still doesn't work. I have some strange problems with it...