I'm trying to implement a BLE feature in my Android application and I'm facing some trouble using the BluetoothGatt
api.
The actual problem is the dreading status 129 (GATT_INTERNAL_ERROR)
every time I call mGatt.discoverServices()
. After debugging this, I noticed that the service discovery packets doesn't even leave the Android phone (By looking at the hci snoop log).
I also noticed that when calling mGatt = mPeripheral.connectGatt(mContext, false, mGattCallback)
, a lot more is happening than the actual connect. When I call this method, the API also asks my peripheral for it's services and characteristics after connecting.
I guess it's the expected behaviour, despite that it is not documented. However, I think that it causes a problem in my case, because the 128 bit Service UUID I want to access on my peripheral doesn't seem to fit into the standard MTU.
In my own code, I request an MTU change before calling mGatt.discoverServices()
, but if it's happening automatically I don't know how to control it.
My current theory is that the implicit service discovery fails because the desired Service doesn't fit into the packets and it's somehow messing up the BluetoothGatt
instance so that it cannot start a new discovery afterwards.
Any input on this matter is appreciated, but some actual questions are:
- Can I prevent
mGatt = mPeripheral.connectGatt(mContext, false, mGattCallback)
from also discovering Services? - Can I change the MTU Size before it's automatically discovering the services? I have tried to request an mtu change (
mGatt.requestMtu(256)
) immediately after getting theBluetoothGatt
instance, but it doesn't change anything. - Can I "repair" the
BluetoothGatt
instance before my own call todiscoverServices()
, so that it will actually be performed?
Some notes:
- I have full access to the Peripheral and can see all the communication between them.
- I have implemented the feature in my corresponding iOS app already using Core Bluetooth and everything works as expected (against the same peripheral of course).