Samsung Android 10 BLE Connectivity Regression

Hi there,

We are connecting over BLE our mobile application to a remote device we make (not running Android).
It used to work just fine but we now have problems when using Samsung devices with Android 10.

It appears that we can connect to the device and send few small-ish messages, but when trying to send something a bit bigger (around 40 bytes), writing to the BLE characterisics fails. It also results in the BLE connection to be dropped, and impossible to reconnect without killing the app.

Out of curiosity we tried to set the MTU to 23 (instead of the usual 185 we are using normally) and sending the same messages now works again (we have a custom message splitting happening depending on the MTU). No disconnection neither.

The device that we have this problem is Galaxy S10e, the model is SM-G970U1, Android Version is 10.

We have reported this issue to Google, but they suggested us to ask in Samsung developer community as you have your own customized version of the AOSP source code. The issue from Google is

We are using requestMtu in BluetoothGatt to change the MTU to 185, and then onMtuChanged return mtu value is 185 and status Is GATT_SUCCESS.

When we sending the longer message which is about 40 bytes, the return value of writeCharacteristic of BluetoothGatt is true, but the onCharacteristicWrite callback will give us a 133 status code, which is not GATT_SUCCESS. Then the devices will disconnect.

What we expect is to be able to use a bigger MTU so that we can have a higher bandwidth.

If you need more information please let us know, and we are looking forward to hearing from you.


This is common issue in google. I have found lot of queries regarding this issue, but did not find any satisfactory answer. You may try with Transport BLE, some developers solved this issue using transport BLE.

We are experiencing the same problem with Galaxy S10+ (SM-G9750, Android 10, OneUI 2.0) other Galaxy S10 devices, while connecting to ESP32 chip. Requesting MTU causes 100% disconnect (Reason 0x8 - Timeout), while sending large data blocks over BLE. Only workaround we have found for now - is not to request MTU at all, but it makes data uploading too slow.


Thanks for your suggestion. Unfortunately, passing BluetoothDevice.TRANSPORT_LE to connectGatt does not solve the issue.

The problem you have is exactly the same, we are connecting ESP32 chip as well.

More information about it:

We tried the some other phones like XiaoMi with Android 10, and it can’t be reproduced, so looks like the problem is only from the Samsung devices.

And we think this is only regression when updating Android version from 9 to 10 only on Samsung devices, because from our customer support, some of users said they can’t connect with the devices only after the Android version is updated on their Samsung devices.


Try your suggestion, I tried in our app but it doesn’t work and the problem is the same.

And notice that the issue in the link looks different to mine, as we have problem in writing data to BLE not connection status.

Anyway, thank you for your advice, if there are more related workaround, we would like to have a try.

Very good.
Although I don’t speak English very well, I’m really enjoying following this community.

1 Like

Hi. We are having exactly the same problem on a Samsung S10 with Android 10 (API29).

Our app negotiates an MTU > 23 and the result is successful. As soon as we send a large packet, though, our smart device immediately disconnects.

We are having a number of complaining customers and are rolling out a fix where MTU negotiation is disabled for Samsung devices with API28 and API29. However, small MTUs require us to disable some advanced features in the app, which will still make customers unhappy.

Can we please expect an official reply from Samsung on this issue? You are currently non Bluetooth-compliant because of this issue and require ad-hoc workarounds from all developers.


Thank you for this Helpful post sir

I contacted our support describing the problem they need a dumpstate/btsnoop log to send them
Would you please share the log with us so that we can escalate to them?

N.B: Please find the guide to get dumpstate log shared by development team as below.

How to get dumpstate/btsnoop log

  1. Settings > About device > click ‘Build number’ several times
  2. Settings > Developer options > check the box for ‘Bluetooth HCI snoop log’
  3. And then reproduce the issue
  4. Right after reproduced > *#9900# on dialpad > run dumpstate/logcat > copy to sdcard
  5. Please transfer the all files in Log directory

Thank you for your cooperation,

Samsung Developer Program

Thanks for the reply. You can find the whole log folder here:

Thanks I’ve past the link to our support team.

Samsung Developer Program

Thanks for this usefull info.

Hi Ron,

Thank you for your reply.

I submitted another support ticket in Dashboard, and it contained all the dumped log.

Any update please let us know.



Hi Ron,

Thank you for response. Attaching logs that were captured by NRF sniffer and NRFConnect (on smartphone) which could be useful as well: BLE logs

We are experiencing exactly the same issue. @dan1580253621 Thanks for opening this thread!

With iOS Devices and other Android devices (Android 9 and 10) everything works well.

The request to change the MTU returns GATT_SUCCESS but the higher MTU is not usable…


Any news regarding this?

@r.liechty_SDP Same question

A solution for his problem is really important for us because we and the most of our customers are Samsung users… The problem occurs on Note 10 devices too…

Please submit the logs mentioned as a support request the support team and Samsung Engineers can analyze those and determine the exact problem. The more data Samsung engineers have the more likely they will find a common denominator if there is one. If there isn’t one they can work with you to solve your individual problem.

Samsung Developer Program

Experiencing similar / the same problem with Samsung Galaxy S10 & Note 10 i.e. abrupt disconnection:
The phone successfully establishes BLE connection followed by MTU negotiation of 512 bytes.
The first small write command works fine. However, the next write we fire triggers disconnection:
Disconnected from MAC=’…’ with status 8 (GATT_INSUF_AUTHORIZATION or GATT_CONN_TIMEOUT)

The write size of around 39 seems to be the cut-off.

We cannot reproduce the above on other device.