We have an IoT device that has an onboard BLE chip (Anaren A20737A) that the user can control from their mobile phone. At times, the phone will pair with the device (or at least report that it is paired), but will not receive any data, and all commands appear to be ignored by the device. Connecting the logger to the device, we can see that it believes that it is sending out messages correctly, and that it is paired with the phone. The solution appears to be forgetting the BLE pairing from the Bluetooth settings on the phone, and sometimes restarting the phone as well. No changes to the IoT device appear to have any impact, the only thing that works is forgetting the pairing from the phone's settings. This problem has occurred on both iPhone and Android (separate code bases).
EDIT
The problem is seen on iOS 7.0 and multiple versions of android from at least 4.4 onward.
Logging the data out from the chip we see it drop the connection and start advertising. About 1 in 10 times, the phone seems to believe that it has a connection with the device, but the logs on the device show that it is still in advertising mode.
Has anyone else ever seen this issue?
I am developing an Android app (API 23+) that communicates via BLE with a device. There is no pairing / bonding involved.
The happy path of the interaction is that the app connects then sends a message to the device, and the device in turn sends a reply back, then they both disconnect.
While characterizing strange behavior I asked in Android BLE unexpectedly reconnects potentially from PBAP / MAP Bluetooth profiles, I created a simple service to monitor low-level bluetooth connections; it listens for broadcasts of BluetoothDevice.ACTION_ACL_CONNECTED and BluetoothDevice.ACTION_ACL_DISCONNECTED.
While most of the time the connect / disconnect corresponds well between app and device, sometimes the app receives a disconnect notification that can be ~5-20 seconds after both the app and device have closed the connection. I have verified that the device actually closed, and the app logs all show the system properly shutting down the connection.
In these instances, if the app tries to connect again with the device before ACL_DISCONNECTED is broadcast, it will either receive an error or the subsequent connect request is queued and kicked off after the ACL_DISCONNECTED broadcast.
This does not seem to be specific to devices --- I test with a variety of makes and models --- nor the API version (23-25).
Is this known (expected) behavior?
Are there ways to mitigate this issue?...to ensure the disconnect indeed happens in a timely manner?
Is there a more direct way --- e.g., through an API call --- to tell if the connection is still up, as opposed to receiving ACL-related broadcasts?
If the BLE devices stops broadcasting instead of sending disconnect signal this issue happens. If the BLE device didn't send the disconnect signal Android device thinks the that the connection is open and it waits for sometime (5-20 sec) and then calls onconnectionstatechange() with time out status code. If you can make the BLE device send the disconnect signal instead of stop broadcasting it should fix the issues. Hope this helps
I am using pusher-java-client (https://github.com/pusher/pusher-java-client) for receiving notification on my android devices - Android Version 4.1.1 and Android Version 4.0.4.
I leave the app running on the device which is connected through wifi to the web (no 3G connection).
The app gets notification but after a day or so, if I have left the app running, it stops to get the notification (also no other interaction with the device during that time).
I have set the device such that the its connected to wifi always. The app may go to the background.
I tried to do a reconnection if I get the Disconnected state in the onConnectionStateChange call back (but that doesn't seem to re-connect).
Any other suggestions on how to restore and keep the connection without closing the app?
Thanks!
I'm currently working on an Android Realtime Multicast Video Streaming application using Wifi connection and it works perfectly fine on most android devices, but when it comes to this particular S4 device (with Android 4.2.2), we experience frequent packet losses. From our experiments, it happens when the device tries to scan for Wifi connections every minute (even though it is already connected to a Wifi connection). I tried disabling the option of scanning for Wifi connections on the wifi settings but it doesn't seem to do the trick (the device still tries to look for wifi connections even with the option turned off).
Follows the lines that show up on log cat:
12-10 15:04:08.348: I/wpa_supplicant(1851): Scan requested (ret=0) - scan timeout 30 seconds
12-10 15:04:13.262: I/wpa_supplicant(1851): nl80211: Received scan results (46 BSSes)
From 15:04:08.348 to 15:04:13.262, our app can't receive any packets, they just never arrive the device.
When searching for process id number 1851 (from our log cat) on the device, here's what we get:
/system/bin/wpa_supplicant-iwlan0-Dnl80211 -c /data/misc/wifi/wpa_supplicant.conf -e /data/misc/wifi/entropy.bin
Is there a way to either shut down wpa_supplicant scans programatically from our application or to set up our app in a mode where it would receive these packets even though a Wifi scan is being run by the OS? (By the way, both WIFI and Multicast Locks are being acquired on our app, but it doesn't seem to be helping with this issue).
Please follow up as any information would be very helpful on resolving this issue, we've been loosing our hairs here for a few days trying to figure this out.
thanks in advance!
I am currently developing an application that will use Bluetooth Low Energy (testing on the Nexus 4). After getting started with the official BLE APIs in Android 4.3, I have noticed that after I connect a device for the first time I am rarely able to successfully connect to / communicate with that device or any other device again.
Following the guide here, I can successfully connect to a device, scan services and characteristics, and read/write/receive notifications without any issues. However, after disconnecting and re-connecting, I am often unable to either scan services/characteristics or unable to complete a read/write. I can't find anything in the logs to indicate why this is happening.
Once this happens I have to uninstall the application, disable Bluetooth, and restart the phone before it will start working again.
Whenever a device is disconnected I make sure to call close() on the BluetoothGatt object and set it to null. Any insights?
EDIT:
Log dumps: For these logs I rooted my phone and upped the trace levels of related items in /etc/bluetooth/bt_stack.conf
Successful connection - First attempt after rebooting the phone and installing the app. I am able to connect, discover all services/characteristics, and read/write.
Failed Attempt 1 - This is the next attempt after disconnecting from the successful connection above. It seems I was able to discover characteristics, but the first attempt to read returned a null value and disconnected soon thereafter.
Failed Attempt 2 - An example where I am not even able to discover services/characteristics.
EDIT 2:
The device to which I am trying to connect is based on TI's CC2541 chip. I obtained a TI SensorTag (also based on the CC2541) to play around with and discovered that TI released an android app for the SensorTag yesterday. However, this app has the same problem. I tested this on two other Nexus 4s with the same result: Connection to the SensorTag is successful the first or second time, but (according to the logs) fails to discover services thereafter, causing all sorts of crashes. I'm starting to wonder if it's an issue with this specific chip?
Important implementation hints
(Perhaps some of those hints aren't necessary anymore due to Android OS updates.)
Some devices like Nexus 4 with Android 4.3 take 45+ seconds to connect using an existing gatt instance. Work around: Always close gatt instances on disconnect and create a fresh instance of gatt on each connect.
Don't forget to call android.bluetooth.BluetoothGatt#close()
Start a new thread inside onLeScan(..) and then connect. Reason: BluetoothDevice#connectGatt(Context context, boolean autoConnect, BluetoothGattCallback callback) always fails, if called inside LeScanCallback() {...}.onLeScan(BluetoothDevice device, int rssi, byte[] scanRecord) in the same thread on Samsung Galaxy S3 with Android 4.3 (at least for build JSS15J.I9300XXUGMK6)
Most devices filter advertising
Better not use android.bluetooth.BluetoothAdapter#startLeScan(UUID[] serviceUuids, LeScanCallback callback) with the parameter to filter for certain service UUIDs because this is broken completely in Samsung Galaxy S3 with Android 4.3 and doesn't work for 128bit UUIDs in general.
Gatt always can process one command at a time. If several commands get called short after another, the first one gets cancelled due to the synchronous nature of the gatt implementation.
I often see even on modern devices with Android 5, that Wifi interferes withs bluetooth and vice versa. As a last resort, turn off wifi to stabilize bluetooth.
Tutorial for beginners
A pretty OK entry point for newcomers could be this video tutorial: Developing Bluetooth Smart Applications for Android http://youtu.be/x1y4tEHDwk0
The issue and work around described below is probably fixed now by OS updates
Work around: I could "stabilize" my app doing that...
I provide the user a setting "Restart Bluetooth". If that setting is enabled, I restart Bluetooth at some points that indicate the begin of BLE stack becoming unstable. E.g. if startScan returns false. A good point may also be if serviceDiscovery failes. I just turn Bluetooth off and on.
I provide another setting "Turn off WiFi". If that setting is enabled, my app turns off Wifi when the app is running (and turns it back on afterwards)
This work around is based on follwoing experiences...
Restarting Bluetooth helps to fix problems with BLE in most cases
If you turn off Wifi, the BLE stack gets much more stable. However, it also works fine on most devices with wifi turned on.
If you turn off Wifi, restarting Bluetooth fully recovers the BLE stack without the need to reboot the device in most cases.
Turning WIFI OFF:
I can confirm too, that turning WIFI OFF makes Bluetooth 4.0 more stable especially on Google Nexus (I have a Nexus 7).
The problem
is that the application I am developing needs both WIFI and continous Bluetooth LE scanning. So turning WIFI OFF was no option for me.
Moreover I have realised is that continous Bluetooth LE scanning can actually kill WIFI connection and make the WIFI adapter unable to re-connect to any WIFI network until BLE scan is ON. (I'm not sure about mobile networks and mobile internet).
This definitely happened on the following devices:
Nexus 7
Motorola Moto G
However BLE scanning with WIFI on seemed pretty stable on:
Samsung S4
HTC One
My workaround
I scan BLE for a short period of time 3-4 seconds then I turn scan OFF for 3-4 seconds. Then ON again.
Obviously I always turn BLE scan OFF when I'm connecting to a BLE device.
When I disconnect from a device I restart BLE (turn adapter OFF and then ON) to reset the stack before starting scan again.
I also reset BLE when discovering services or characteristics fails.
When I get advertisement data from a device that the app should connect to (lets say 500 times without being able to connect - thats about 5-10 seconds of advertising) I reset BLE again.
Make sure your Nexus is paired to the device. I can't verify whether or not the communication works properly, but you will be able to connect more than once without a reboot. It seems the first connect is not requiring pairing but all subsequent attempts do.
I will update this answer in a couple of days when I test service discovery and gatt read and write requests without a reboot.
EDIT:
It turns out I was testing on a development firmware version (our sensor) that was causing issues if not paired. Our latest production firmware build works fine on the 2540s and 2541s.
EDIT:
I did notice that on the Nexus 7 2013, connections are more stable when WiFi is turned off. I'd like to know if this helps anyone else.
EDIT:
I seem to have had it backwards with pairing. Everything works fine when not paired. After pairing, I am experiencing the exact same symptoms as the OP. It's just not known yet if this is related to our firmware or the Android BLE API. Be careful if testing this because once paired, you may not be able to unpair due to a bug explained in 3b of this post.
In some models there is a defect:
https://code.google.com/p/android/issues/detail?id=180440
On the other hand in my case the problem was, that my connection was not properly closed in onDestroy method. After correct closing, problem for me is not existing, not matter that wifi is turned on or off.
btGatt.disconnect();
btGatt.close();
I was facing a similar issue. My fix was
if (Build.VERSION.SDK_INT >= 23) {
mBluetoothGatt = device.connectGatt(this, false, mGattCallback, BluetoothDevice.TRANSPORT_LE);
} else {
mBluetoothGatt = device.connectGatt(this, false, mGattCallback);
}
& calling close after disconnect.