I have an issue with the current 2019 Samsung Galaxy devices (S10). I can make a write to a Bluetooth Characteristic once. Then, if I try the call again, the onConnectionStateChange override method returns a status of "8". According to Google this means GATT_CONNECTION_CONGESTED. I can validate the first call works too. Also, soon after the congested errors returns, the phone disconnects from the app.
After pulling Samsung's bluetooth logs using adb shell dumpsys bluetooth_manager, I can see this error:
BluetoothRemoteDevices -- ACTION_ACL_DISCONNECTED, device is 30AEA4,
reason is 8, linktype is 2
Weirdly, I can use just about any other Android device, Pixel, Essential, older Samsungs, and not one of them returns this error message after a second call and work as expected. All of the current line of Samsung Galaxy devices all seems throw this error. Does anyone know what this error message means exactly and how to avoid it?
Related
I am facing one issue related to BLE’s behavior in our application. In Android 11 and below, On Ble disconnection, we used to get different status codes in onConnectionStateChange callback like status 8 is for out range, 19 is peripheral disconnection etc and For programmatic disconnection, it was returning 0.
However starting from Android 12 the BLE API is always returning 0 regardless of it is programmatic disconnection or due to any other reason.
In our application, we are performing some operations based on if the disconnection was unexpected(Out of range, peripheral initiated, etc) or it was programmatic. Now there is no way to distinguish the difference for BLE disconnection reason on Android 12 devices. And this creates issues in our application.
Has anyone faced this issue with BLE’s behavior in your application running on an android 12 devices and found any solution for it?
Also, This change in android 12 is not mentioned anywhere in the android developer’s documentation.
Here is the callback which i am using to get connection status change : https://developer.android.com/reference/android/bluetooth/BluetoothGattCallback#onConnectionStateChange(android.bluetooth.BluetoothGatt,%20int,%20int)
I also find it very annoying.
The question is also asked here (Android 12 BLE always returning status 0 on disconnect) and gives a little more context.
I have implemented successfully the pires/obd-java-api OBD Interface in an Android app and everything works as expected, expect that after about 1.000 - 1.500 API calls, the API stops responding.
Did anyone come across the same problem?
Is it maybe necessary to send a reset command to the OBD dongle after some time?
I thought it might be that the API is collecting data and a memory problem occurs, but onTrimMemory is never called.
I assume API means Standard Pids(mode 1)then OBD will not response in following case
1: TimeoutCommand is too low, set 255
2: may be not proper power supply
Note: ResetCommand is used as initial command once before fetching real time data.
you can refer android-obd-reader sample app:
https://github.com/md-sohrab-alam/android-obd-reader
I have implemented a receiver within my app that continually searches using Bluetooth and updates the server every 10 seconds with the available devices. One piece of information it returns is the RSSI value of the device. The code I use to get this value is:
node.Rssi = intent.getShortExtra(BluetoothDevice.EXTRA_RSSI, Short.MIN_VALUE);
So this seemed to work fine at first, using my test phone (Galaxy S4) I got expected values such as -75 or -88. However I have now tried a different phone shown in the link below:
http://www.amazon.co.uk/Waterproof-smartphone-Dustproof-Shockproof-Capacitive/dp/B00EZNSUPU/ref=pd_sim_sbs_ce_3?ie=UTF8&refRID=0YYHYTW6J2AVZK7DJJDJ
(Sorry if I'm not allowed to post this here, I'm not 100% on the rules, if there's a problem I'll happily remove it)
When using this phone with the same build of my app, the values for the RSSI range from 150-200.
Does anyone have any idea why this might be happening? Another problem I'm having with the phone is that when Bluetooth is on my Wi-Fi connection will eventually disappear, again this doesn't happen with my Galaxy S4. Is this test phone really that bad? Or am I missing something..
I am facing quite a peculiar problem.
I am programming on Android to get a reading from a BLE Blood pressure monitor(A&D UA 651). I am able to get the reading from the device on certain devices(galaxy S6, Note 2, Droid Turbo), but on other devices(like the Oneplus One, HTC Desire 810) etc, I am able to connect to the BP monitor, but cannot get a reading from it.
I followed the tutorial posted by Android here.
Write now, I am using setCharacteristicNotification() to alert me of any changes in characteristics. I am also writing the correct descriptor using:
descriptor.setValue(BluetoothGattDescriptor.ENABLE_INDICATION_VALUE);
mBluetoothGatt.writeDescriptor(descriptor);`
Here's the kicker. I've noticed that on the devices where I am not alerted of a change in the characteristic value, if I put a breakpoint inside the callback
onDescriptorWrite(), I am able to get the reading.
The status value in the callback is always 0 (irrespective of whether I can read the value on the characteristic or not.)
This lead me to thinking that I should induce a delay in this callback, but this seldom works.
If anyone has faced this issue before, please let me know. I've been stuck on this issue for quite some time now.
Thanks!
using the android 4.4 BLE APIs on my Nexus7, i'm able to successfully interact with a peripheral BLE device -- connect, disconnect, read, write....
if however an active connection breaks for whatever reason (in this case, the peripheral is reset), i observe the following behavior....
my peripheral (by design) begins advertising after any active connection is terminated (for whatever reason); i can see this via my bluetooth packet sniffer....
i receive the onConnectionStateChanged callback as expected in my android app, at which point i invoke close() on my active BluetoothGatt instance; this is the same procedure i follow during a "normal" disconnect initiated from the client...
shortly after this, the android BLE stack tries to re-connect to the same peripheral; through the packet sniffer i can see the BLE connection request going out over the air...
my app, however, did not initiate this re-connection; indeed, i see no information from any bluetooth log suggesting this even happened!!!!
is there some "mode" in the BLE stack where it attempts to re-establish busted connections automatically???
thanks....
This happens on various Android phones whether the autoConnect flag is set to false or true.
Couldn't yet find a complete solution, it seems as the android BLE stack is spontaneously re-initiating the connection once it is getting the advertising signal again, just ignoring that it was the app that disconnected on purpose...
A partial solution may involve not using the BluetoothGatt.connect() method as explained here:
https://stackoverflow.com/a/23749770/4144487
So, a sample connect method can look like:
void connect(Context context) {
if (mGatt != null) {
mGatt.close();
}
mGatt = mDevice.connectGatt(context, false, callback);
}
To explain the importance of this issue, when it happens the peripheral thinks it is connected and my "real" app can't find it any more. At some phones like Galaxy S3 and Redmi note 3 I found that closing the bluetooth switch from the notification bar is "releasing" the peripheral and allowing me to discover the device. At others like Nexus 5x only a phone reboot will do the trick.
I've observed this happening if you use autoConnect=true when calling BluetoothGatt#connectGatt(). Generally I've found that it is best to use autoConnect=false, but with some devices you simply cannot connect unless you use true, so I usually do both. I try false first and if that fails then use true and then the behavior you're describing is something you simply have to work around.