-
Notifications
You must be signed in to change notification settings - Fork 424
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Issue with reading on Android 13 Samsung devices #463
Comments
@peropavlovic Have you tried requesting MTU of size 517? I had a similar issue https://issuetracker.google.com/issues/265343637 and it worked for me. |
@adi-pilav-sn thanks for advice! I have tried and I'm not getting disconnected anymore but now it fails with reason 133. I checked out Device and everything looks good there. On device scenario with MTU lower then 517 was that all chunk was sent, and on last one readCharacteristic fails and BLE get disconnected. Now when I tried with MTU 517, only one chunk sent and readCharacteristic fails with reason 133. Any advice what should I do next? |
Can you try to paste the Android system logs here when 133 error happens? Note: if you are using Android Studio remove any tags (including package name) from the logcat and you will see the Android system logs that may give some more info about what went wrong. |
If you're using write without response you need to split the data into MTU-3 byte long packets on your own. If the size is not known on the receiver side, you need to send the length as well. Each packet can be up to MTU-3 bytes long. If you're using write with response and the data are longer than MTU, Android will automatically use Long Read Procedure. Data will be split automatically if MTU is lower, but again, the longest packet can be 500 bytes, I think (or around that number). For longer packets I recommend write without response, as they are faster. In the BLE library we have |
For example,. the HeaderBasedPacketMerger and splitter add UINT16 length field for every message. When receiving, the other device knowns how long packet to expect, can set up a buffer and collect requests until the fill buffer is full. Splitter adds the length field, merger reads it and collects. We also have an example of flag based splitter-merger pair, where each packet contains an information: full, start, continuation, end, and based on that the merger knows when the data are complete. If the length of the packet is known to the merger you may just use |
If you have some specification to follow, check how that is specified there. |
Hi @philips77, thanks for the info! Our problem is reading data with readCharacteristic, not writing. Data they send to us can be different size and the one we have problem with is when that data is larger then 515 bytes (Usually its around 1000 bytes). And in that scenario, while reading data our readCharacteristic is failing. |
@philips77 Just to explain a little bit better our flow. We have gatt server written in GO. Issue is that, when trying to read first chunk with readCharacteristic() it fails without reading it (We can see on server logs that sending is good) and usually disconnects from BLE connection. This issue was working good on all device and Android versions, except Samsung devices with Android 13. |
I think I may know the issue then. As far as I remember, starting from Android 13 the OS is now correctly handling too long values. For Long Read or Long Write there's a limit for length is 512 bytes:
Core Bluetooth 5.2, Vol 3, Part F, 3.2.9. Before it was "somehow working", but since 13 the limit is checked. Btw, in the BLE library you may set a merger to |
Hi @philips77 I still have this issue and trying to figure it out how to solve it. My users keep pushing me as they cannot use this major feature because of this issue. So we found out it occurs on Samsung devices with Android 13. But not all of them, just some of it, usually on those devices: Samsung s20 - Android 13 Here is some filtered Bluetooth logs if it can helps figuring out the issue.
And here is BLE Manager Logs:
|
@peropavlovic have you solved this issue? I've faced with that as well |
@peropavlovic Just an FYI: while you are trying to figure out what the issue is here, try using the lowest value for the MTU of 27 as a workaround. It worked for me, though it did slow down the BLE communication drastically. If it does not work for you, then it is more likely that the issue is on the peripheral device. |
@adi-pilav-sn thanks, I tried that. |
@peropavlovic please can you share your fix? |
Can you please share the fix |
Hi Android-Ble-Library developers,
we have issue with readCharacteristic request on Samsung devices using Android 13. Issue occurs only when we trying to read data larger then 512. We tried changing MTU sizes but nothing solve this issue. When we try to call readCharacteristic it fails with Fail reason -100 and BLE Connection get disconnected.
Can you help us solve this issue as it's really important as Users with those devices cannot use some of fundamental features of our app.
Thanks!
The text was updated successfully, but these errors were encountered: