I am developing an app that needs to connect to a ble peripheral automatically.
I have a sticky service that does the following:
looks for the required device in bonded devices
if it doesn't fine the device (first time), scans for it and bonds to it by using device.createBond(), waits for the bond to finish by listening to the ACTION_BOND_STATE_CHANGED broadcast
connects to it using device.connectGatt(ctx,true,callback)
waits for onConnectionStateChange callback with connected state
starts service discovery by using gatt.discoverServices()
waits for onServicesDiscoverd callback
enables notifications on a characteristic by writing a descriptor using gatt.writeDescriptor
waits for onDescriptorWrite callback with success status BluetoothGatt.GATT_SUCCESS (0)
does stuff with the notifications it receives
This all works fine for the first time. When the device disconnects (becomes out of range for instance, or turned off) the sticky service callbacks gatt.disconnect() and gatt.close(), restarts and does all this again, this time it uses the bonded device to connect.
Everything works fine until step 7, meaning I get a callback to onDescriptorWrite with status 133 sometimes followed by a connection state change callback with state 0 and status 22.
I could not find any info online for what status 133 or 22 mean.
Any idea why this is happening?
I am sort of working around it now by reacting to the bad onDescriptorWrite callback by removing the bond (reflection) an doing everything again with the freshly scanned device.
So basically I am using the bond just to wait for the device connection and then restart the whole thing.
This means a gatt connection for a bonded device is useless for writing the descriptor I need.
It feels like I am missing something, would love to know what.
EDIT:
some relavant logcat output
08-18 16:06:31.363 12765-12835/? W/bt-att﹕ gatt_rsp_timeout disconnecting...
08-18 16:06:31.363 12765-12835/? W/bt-btif﹕ bta_gattc_conn_cback() - cif=3 connected=0 conn_id=3 reason=0x0016
08-18 16:06:31.363 12765-12835/? W/bt-btif﹕ bta_gattc_conn_cback() - cif=4 connected=0 conn_id=4 reason=0x0016
08-18 16:06:31.363 12765-12835/? W/bt-btif﹕ bta_gattc_conn_cback() - cif=5 connected=0 conn_id=5 reason=0x0016
08-18 16:06:31.366 12765-12807/? D/BtGatt.GattService﹕ onDisconnected() - clientIf=5, connId=5, address=C1:D1:22:BA:F5:13
here im getting onDescriptorWrite with status 133
D/BluetoothGatt﹕ onClientConnectionState() - status=22 clientIf=5 device=C1:D1:22:BA:F5:13
by the looks of this:
https://android.googlesource.com/platform/external/bluetooth/bluedroid/+/idea133/bta/include/bta_gatt_api.h#169
16 means BTA_GATT_CONN_TERMINATE_LOCAL_HOST
22 means BTA_GATT_CONN_LMP_TIMEOUT
asked this on nordics github:https://github.com/NordicSemiconductor/Android-nRF-Toolbox/issues/9#issuecomment-132191406
asked this on nordics github:
https://github.com/NordicSemiconductor/Android-nRF-Toolbox/issues/9#issuecomment-132191406
following their recommendation added a 2 second delay after calling connectGatt and now it works.
Related
In my app I have tried everything to connec my BLE device and receive calls to onCharacteristicChanged. I have had success with initial connection where my console reads like this:
BluetoothGatt: onConnectionUpdated() - Device=B4:E6:2D:B3:D0:DB interval=6 latency=0 timeout=500 status=0
BluetoothGatt: setCharacteristicNotification() - uuid: 0a990c1f-0000-441c-8f7d-f775b6ff9400 enable: true
BluetoothGatt: setCharacteristicNotification() - uuid: f7c21d1c-0000-4b9b-ab7e-e1d8e7a51724 enable: true
Although I have no calls to onCharacteristicChanged?
I am not sure this is the proper way to check but I have used nRF Connect app to test if there is any activity between the BLE device and the Android phone. Using that app, it recoded no activity after connecting to the device. Just to be sure, I tested other BLE devices and saw the expected activity.
The BLE device has 8 characteristics that I read/get notified from, and another 8 that I write to (16 total). I have read that Android may only support 15, I could be wrong on how this works.
Does any of this seem like an issue? I can post code too.
I am developing an Android App that communicates with a BLE Peripheral. I am able to enable the notifications and receive data from the BLE Peripheral. However, a few seconds later, I receive the following message on my Android Terminal in Android Studio and the Notifications stop.
I noticed that Android phone is still connected to the BLE Peripheral as Status = 0, but after the BLE Connection Interval Change = 156, the Notifications stop.
Has anyone encountered a similar problem? I am using the BluetoothLEGatt example from Android Studio.
Thanks
Hani Abidi
D/BluetoothGatt: onClientConnParamsChanged() - Device=80:EA:CA:00:A8:77 interval=156 status=0enter code here
So I ran into this issue as well and although I don't 100% know the exact cause, I can at least relay how I "fixed" the problem and my experiences.
So I'm using a Samsung Galaxy Note 4 running 6.0.1 and using RxAndroidBle to ease the pain of having to deal with BLE on Android. My application connects to a PSoC4 BLE microprocessor and immediately does a back and forth data transfer with said microprocessor. What I was seeing was similar to the OP: more often than not the back and forth transmission would just stop dead in its tracks with the following messages:
03-15 16:06:39.989 27793-28784/application D/BluetoothGatt: onClientConnParamsChanged() - Device=00:A0:50:65:24:91 interval=6 status=0
03-15 16:06:40.289 6292-6754/? D/BtGatt.GattService: onClientConnParamsChanged() - clientIf=7 address=00:A0:50:65:24:91, interval=39status=0
03-15 16:06:40.289 27793-28561/application D/BluetoothGatt: onClientConnParamsChanged() - Device=00:A0:50:65:24:91 interval=39 status=0
03-15 16:06:54.989 6292-6754/? D/BtGatt.GattService: onClientConnParamsChanged() - clientIf=7 address=00:A0:50:65:24:91, interval=6status=0
03-15 16:06:54.989 27793-27823/application D/BluetoothGatt: onClientConnParamsChanged() - Device=00:A0:50:65:24:91 interval=6 status=0
03-15 16:06:55.259 6292-6754/? D/BtGatt.GattService: onClientConnParamsChanged() - clientIf=7 address=00:A0:50:65:24:91, interval=39status=0
03-15 16:06:55.259 27793-28784/application D/BluetoothGatt: onClientConnParamsChanged() - Device=00:A0:50:65:24:91 interval=39 status=0
It appeared to me at first that for some reason the phone was still negotiating the connection interval in the middle of the data transfer and, for some reason, would just completely get screwed up as a result.
Maybe this is what is happening, maybe it isn't, but what I found was the root cause of this was that I am (apparently) connecting and interfacing with my microprocessor over BLE before the BLE device scanner is completely done shutting down.
When the user taps on the table view cell to connect to the device, I was originally calling to stop subscribing to the RxAndroidBle observable that is scanning for devices, which should end the BLE scanning and then immediately launched into showing a new Activity for communicating with the PSoC4 which in turn immediately connects and starts interfacing with the microprocessor:
scanSubscription.unsubscribe();
Intent myIntent = new Intent(MainActivity.this, ConnectedActivity.class);
myIntent.putExtra("address", testdevice.getAddress());
myIntent.putExtra("name", testdevice.getName());
MainActivity.this.startActivityForResult(myIntent, CONNECTED_ACTIVITY);
It appears, however, that simply unsubscribing from the scan subscription does not immediately end the BLE scanning so my current strategy is to wait 500 ms before starting any communications with the other device. This is obviously not ideal - ideally you'd have a method callback when scanning actually was ceased, but I haven't figured out how to do that just yet.
Hopefully this helps someone.
Connection parameter update is unrelated to notification subscription status. Are you saying your onCharacteristicChanged are not being called although you send notifications from the peripheral? You should check your code again. If you think you've done everything correct you should check android's hci snoop log or use a BLE sniffer to see what really happens.
I am developing an Android app that interfaces with a BLE device and recently stumbled across some strange behavior: when the app disconnects from the device, a few seconds later something else seems to establish the connection.
I am in the process of characterizing the issue more fully and have been focused on the Bluetooth MAP and PBAP profiles; they show up in the logs around the point of issue. I am unsure, however, if this is the root cause, nor have I found a workaround.
The app supports API 23-25. To date, I have only experienced the issue in phones with SIM cards present, which points again to PBAP since many phones seem to support this profile only with a SIM card. I haven't yet been able to reproduce on API 23, but for now those test phones do not have SIM cards.
The BLE device has nothing to do with automotive application, nor does it have the ability to deal with Contacts or Messaging. I haven't intentionally enabled any of this within the app. Furthermore, there is no pairing / bonding between my app and the device, nor does the device support pairing / bonding.
In most cases, the attempt to reconnect happens once, a few seconds after device disconnect via the app. Subsequent connect-disconnect sequences in the app have the same behavior. However, I have seen in at least one instance where the reconnects (outside of the app) continue indefinitely every few seconds.
The only thing that seems to resolve the issue short-term is to cycle Bluetooth on the phone, or force-stop the Bluetooth Share process. I don't believe the reconnects come back on their own, but it is common that they do reappear once the user connects-disconnects with the device through my app.
I am not very familiar with PBAP / MAP so am unaware how they get enabled or, if possible, how to disable them. I am not sure if they are the culprit, but they appear in the logs at the moment of reconnect.
Following is the log statements around the point of disconnection and subsequent reconnection. The interface name here is "Foo04" with MAC = B0:B4:48:E8:FA:04.
03-31 14:27:44.305 D/RxBle#Radio(14105): STARTED RxBleRadioOperationDisconnect(186827491)
03-31 14:27:44.319 D/BluetoothManager(14105): getConnectionState()
03-31 14:27:44.320 D/BluetoothManager(14105): getConnectedDevices
03-31 14:27:44.332 D/BluetoothGatt(14105): cancelOpen() - device: B0:B4:48:E8:FA:04
03-31 14:27:44.334 D/BtGatt.GattService(13168): clientDisconnect() - address=B0:B4:48:E8:FA:04, connId=5
03-31 14:27:44.339 E/bt_btif (13168): bta_gattc_mark_bg_conn unable to find the bg connection mask for: b0:b4:48:e8:fa:04
03-31 14:27:44.340 D/BtGatt.GattService(13168): onDisconnected() - clientIf=5, connId=5, address=B0:B4:48:E8:FA:04
03-31 14:27:44.341 D/BluetoothGatt(14105): onClientConnectionState() - status=0 clientIf=5 device=B0:B4:48:E8:FA:04
03-31 14:27:44.342 D/RxBle#BluetoothGatt(14105): onConnectionStateChange newState=0 status=0
03-31 14:27:44.345 D/RxBle#Radio(14105): FINISHED RxBleRadioOperationDisconnect(186827491)
03-31 14:27:44.352 D/BluetoothGatt(14105): close()
03-31 14:27:44.352 D/BluetoothGatt(14105): unregisterApp() - mClientIf=5
03-31 14:27:44.354 D/BtGatt.GattService(13168): unregisterClient() - clientIf=5
03-31 14:27:45.376 W/bt_l2cap(13168): l2cble_process_conn_update_evt: Error status: 22
03-31 14:27:45.377 W/bt_btif (13168): bta_gattc_conn_cback() - cif=3 connected=0 conn_id=3 reason=0x0016
03-31 14:27:45.377 W/bt_btif (13168): bta_gattc_conn_cback() - cif=4 connected=0 conn_id=4 reason=0x0016
03-31 14:27:45.377 I/bt_btm_sec(13168): btm_sec_disconnected clearing pending flag handle:13 reason:22
03-31 14:27:45.381 E/BluetoothRemoteDevices(13168): state12newState1
03-31 14:27:45.393 D/BluetoothMapService(13168): onReceive
03-31 14:27:45.393 D/BluetoothMapService(13168): onReceive: android.bluetooth.device.action.ACL_DISCONNECTED
03-31 14:27:45.402 D/BluetoothPbapReceiver(13168): PbapReceiver onReceive action =
03-31 14:27:45.404 D/BluetoothPbapReceiver(13168): Calling start service with action = null
03-31 14:27:45.405 I/TrustAgent.Tracker(15208): [BluetoothConnectionTracker] Bluetooth disconnect broadast for Foo04 B0:B4:48:E8:FA:04
03-31 14:27:46.407 W/bt_smp (13168): smp_br_connect_callback is called on unexpected transport 2
03-31 14:27:46.408 W/bt_btif (13168): bta_dm_acl_change info: 0x0
03-31 14:27:46.408 I/bt_bta_dm(13168): bta_dm_gatt_disc_result service_id_uuid_len=2
03-31 14:27:46.408 I/bt_bta_dm(13168): bta_dm_gatt_disc_result service_id_uuid_len=2
03-31 14:27:46.408 D/bt_btif_dm(13168): remote version info [b0:b4:48:e8:fa:04]: 0, 0, 0
03-31 14:27:46.408 I/bt_bta_dm(13168): bta_dm_gatt_disc_result service_id_uuid_len=2
03-31 14:27:46.408 I/bt_bta_dm(13168): bta_dm_gatt_disc_result service_id_uuid_len=16
03-31 14:27:46.408 I/bt_bta_dm(13168): bta_dm_gatt_disc_result service_id_uuid_len=2
03-31 14:27:46.412 E/BluetoothRemoteDevices(13168): state12newState0
03-31 14:27:46.457 I/TrustAgent.Tracker(15208): [BluetoothConnectionTracker] Bluetooth connect broadast for Foo04 B0:B4:48:E8:FA:04
03-31 14:27:47.317 I/WCNSS_FILTER(13194): ibs_msm_serial_clock_vote: vote UART CLK OFF using UART driver's ioctl()
03-31 14:27:48.421 I/WCNSS_FILTER(13194): ibs_msm_serial_clock_vote: vote UART CLK ON using UART driver's ioctl()
03-31 14:27:48.483 W/bt_btif (13168): bta_gattc_conn_cback() - cif=3 connected=0 conn_id=3 reason=0x0016
03-31 14:27:48.483 W/bt_btif (13168): bta_gattc_conn_cback() - cif=4 connected=0 conn_id=4 reason=0x0016
03-31 14:27:48.483 I/bt_btm_sec(13168): btm_sec_disconnected clearing pending flag handle:14 reason:22
03-31 14:27:48.488 E/BluetoothRemoteDevices(13168): state12newState1
03-31 14:27:48.506 D/BluetoothMapService(13168): onReceive
03-31 14:27:48.506 D/BluetoothMapService(13168): onReceive: android.bluetooth.device.action.ACL_DISCONNECTED
03-31 14:27:48.524 D/BluetoothPbapReceiver(13168): PbapReceiver onReceive action = android.bluetooth.device.action.ACL_DISCONNECTED
03-31 14:27:48.527 D/BluetoothPbapReceiver(13168): Calling start service with action = null
03-31 14:27:48.530 I/TrustAgent.Tracker(15208): [BluetoothConnectionTracker] Bluetooth disconnect broadast for Foo04 B0:B4:48:E8:FA:04
03-31 14:27:49.430 I/WCNSS_FILTER(13194): ibs_msm_serial_clock_vote: vote UART CLK OFF using UART driver's ioctl()
Further Investigation
I posted a related question in Android BLE ACL_DISCONNECTED sometimes delayed.
One commonality among the devices where I've seen the problem has been the existence of a SIM card, but another one is API 24 or 25. I haven't yet been able to reproduce on an API 23 device or, regardless of version, one without a SIM card physically installed.
After even further investigation, I'm less suspect of the SIM card, and more of the API version. There are several outstanding (or recently fixed) bugs that have related behavior, some of which points to API versions > 23; however, I have subsequently been able to reproduce on API 23.
BLE: Having two pending direct connections and cancelling the second one does not work
BLE: Disconnecting/closing GATT directly after connect sometimes has no effect due to race conditions
BLE: Closing gatt object or app does not remove pending connection since Android N
Race condition in BluetoothGatt when using BluetoothDevice#connectGatt()
I'm feeling this has little to do with PBAP / MAP profiles. Rather, the existence of them in the logs points simply to these profiles being activated with any BLE disconnection. While not manifesting the reconnection behavior, I was able to see similar PBAP / MAP activation when messing with a TI SensorTag: these profiles again logged any disconnect (unrelated to my application).
List of Affected Devices
I've been able to reproduce this issue, to varying degrees, on the following devices:
Samsung S6 - API 23
Samsung S7 - API 23
Samsung S7 Edge - API 24
Sony Xperia Z5 Compact - API 24
Motorola Droid Turbo 2 - API 24
Nexus 5x - API 25
Google Pixel - API 25
After a great deal of investigation, I was able to determine the root cause of my issue: Spotify.
Having Spotify installed on the Android device was enough to manifest this aberrant behavior; the user need not have logged into or ever started the Spotify app. Uninstalling or force-stopping the app in all cases rectified the issue.
It appears that Spotify has a service that registers for disconnects from any bluetooth peripheral. When the system notifies Spotify, the service immediately connects to the just-disconnected peripheral --- I didn't bother to characterize the communication from Spotify. After ~5 seconds the connection is dropped; however, since Spotify is notified of bluetooth disconnection events, the service again tries to connect with the peripheral. This effectively is an infinite loop that can be aborted only by force-stopping Spotify or cycling bluetooth on the Android device.
To investigate, I developed a simple app that is notified of and reports bluetooth connection and disconnection (ACL_CONNECTED, ACL_DISCONNECTED) events. I used a BLE scanner on my Android device and connected / disconnected with a variety of bluetooth peripherals. My test app would show my initial interaction with the peripheral followed by an infinite stream of connect then disconnect events. Again, this would continue until Spotify was force-stopped.
Following is example logging...
04-10 19:56:24.109 D/BluetoothConnectionMoni: onReceive: deviceName=System05 deviceAddr=B0:B4:48:E8:D7:03 action=ACL_CONNECTED
04-10 19:56:32.057 D/BluetoothConnectionMoni: onReceive: deviceName=System05 deviceAddr=B0:B4:48:E8:D7:03 action=ACL_DISCONNECTED
04-10 19:56:34.197 D/BluetoothConnectionMoni: onReceive: deviceName=System05 deviceAddr=B0:B4:48:E8:D7:03 action=ACL_CONNECTED
04-10 19:56:40.396 D/BluetoothConnectionMoni: onReceive: deviceName=System05 deviceAddr=B0:B4:48:E8:D7:03 action=ACL_DISCONNECTED
04-10 19:56:43.857 D/BluetoothConnectionMoni: onReceive: deviceName=System05 deviceAddr=B0:B4:48:E8:D7:03 action=ACL_CONNECTED
04-10 19:56:49.962 D/BluetoothConnectionMoni: onReceive: deviceName=System05 deviceAddr=B0:B4:48:E8:D7:03 action=ACL_DISCONNECTED
04-10 19:56:51.130 D/BluetoothConnectionMoni: onReceive: deviceName=System05 deviceAddr=B0:B4:48:E8:D7:03 action=ACL_CONNECTED
04-10 19:57:17.348 D/BluetoothConnectionMoni: onReceive: deviceName=System05 deviceAddr=B0:B4:48:E8:D7:03 action=ACL_DISCONNECTED
04-10 19:57:17.927 D/BluetoothConnectionMoni: onReceive: deviceName=System05 deviceAddr=B0:B4:48:E8:D7:03 action=ACL_CONNECTED
04-10 19:57:37.621 D/BluetoothConnectionMoni: onReceive: deviceName=System05 deviceAddr=B0:B4:48:E8:D7:03 action=ACL_DISCONNECTED
04-10 19:57:38.157 D/BluetoothConnectionMoni: onReceive: deviceName=System05 deviceAddr=B0:B4:48:E8:D7:03 action=ACL_CONNECTED
04-10 19:57:44.364 D/BluetoothConnectionMoni: onReceive: deviceName=System05 deviceAddr=B0:B4:48:E8:D7:03 action=ACL_DISCONNECTED
...
It was difficult to determine Spotify was the root cause.
My first indication was through looking at Developer Options -> Running Services and noting Spotify regularly popping up correlated with peripheral connection / disconnection.
In the end, though, it came down to process of elimination: Once the aberrant behavior started, I selectively went through the list of installed apps, force-stopping ones that likely had some interest in bluetooth, eventually seeing the issue cease immediately when I stopped Spotify.
I have provided a detailed bug report to Spotify several weeks ago, but I have yet to hear back from them.
This seems to be fixed beginning in Spotify 8.4.19.792 released 2017-09-14.
Here is the list of error which i got while developing BLE App for A&D UA-651BLE model
onClientConnectionState() - status=8 clientIf=5 device=D0:5F:B8:03:79:70
onClientConnectionState() - status=22 clientIf=5 device=5C:31:3E:5E:E2:36
onClientConnectionState() - status=19 clientIf=5 device=5C:31:3E:5E:E2:36
As of now I'm handling this with gatt.disconnect(); ,
Description of above error codes :
22 is 0x16 which means connection terminated by local host.
8 is 0x8 which means connection timeout.
19 is 0x13 which means connection terminate by peer user.
How to handle this in different way?
1.Is there any way to handle this issue other than disconnecting BluetoothGatt? (Just curious to know)
2.Shall I show popup to user that your values are stored in BP device,On next successful connection vital device will push your values automatically?
P.S: If I see from developer's perspective,I know that this is BLE Stack exception,By if i see from user's perspective,they will think something wrong in android app,that is why it is not Showing my BP reading in android Screen.
I have a Android Service which scans for Bluetooth Low Energy devices. This works but if the app is killed the scan dont work. The service is running but I see in the logcat that the binder for bluetooth is dead.
D/BtGatt.GattService(3088): Binder is dead - unregistering client (5)!
D/BtGatt.GattService(3088): stopScan() - queue=1
D/BtGatt.GattService(3088): stopScan() - queue empty; stopping scan
D/BtGatt.btif(3088): btif_gattc_scan
D/BtGatt.btif(3088): btgattc_handle_event: Event 1003
D/BtGatt.GattService(3088): unregisterClient() - clientIf=5
D/BtGatt.btif(3088): btif_gattc_unregister_app
D/BtGatt.btif(3088): btgattc_handle_event: Event 1001
D/BtGatt.btif(3088): btif_gattc_upstreams_evt: Event 1
How can i scan for bluetooth devices with a service? Thank you
Unlike previous versions, in 4.4 swiping app out of recent tasks permanently kills app along with its service (like force-stop) even though it's running background services. Here you can find a "quick and dirty workaround":
In android 4.4, swiping app out of recent tasks permanently kills application with its service . Any idea why?