I've developed an Android app for remote controlling some special hardware devices. The communication is done via udp and wifi. The app already runs on ~60k devices without any problems but since the rollout of Android 6 I'm getting more and more reports from users who get some strange errors:
Usually the app searches for the hardware with a broadcast package. The app then requests all data from the hardware to stay in sync (~4000 packages in both directions). This sync process is heavily tested with all wifi conditions possible and does work as intended (also on Android 6).
User with a Samsung device and Android 6 are now having the issue, that the sync is unable to complete (no reply from the hardware within 20 seconds). The odd thing is that the broadcast search does work just fine, as well as the beginning of the sync. Usually the timeout happens when 5-15% of the sync was completed.
As I have no idea what could cause this issue I wanted to ask if there is any known problems with Samsung / Android 6 and udp communication via wifi?
Also were there any other changes on the network stack in Android 6 that could cause this issue? On my test devices (HTC mostly) everything runs fine so I'm currently out of ideas.
Edit:
I narrowed the issue down to the following devices:
Samsung Galaxy 6
Samsung Galaxy 6 Edge
Samsung Galaxy Note 5
Edit 2:
I got a Samsung Galaxy 6 device for testing purposes and of course it does work for me. I also tried all sorts of network setup, power saving, anti virus and general settings combination but it's just working all the time.
Edit 3:
After getting some Galaxy S5 and S6 test devices I was not able to reproduce the problem. Comparing the ROM version I found out that these devices all have a newer rom than the devices which got the issues.
Turns out that Samsung simply broke something in their wifi stack which causes the wifi to stop working properly after some udp packages. So only fix for this issue is to wait and hope they fix it in all countries soon.
Related
We are having a problem with our Android app that scans for beacons with Bluetooth, when user is currently using the app. The app is loading data from API when different views are being loaded. Sometimes, when keep on clicking views one request fails (time-out), with this error:
java.net.SocketTimeoutException: failed to connect to www.examplehost.com/111.222.333.444 (port 80) after 15000ms
at libcore.io.IoBridge.connectErrno(IoBridge.java:169)
at libcore.io.IoBridge.connect(IoBridge.java:122)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:183)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:452)
at java.net.Socket.connect(Socket.java:884)
at com.android.okhttp.internal.Platform.connectSocket(Platform.java:117)
at com.android.okhttp.internal.http.SocketConnector.connectRawSocket(SocketConnector.java:434)
at com.android.okhttp.internal.http.SocketConnector.connectCleartext(SocketConnector.java:105)
at com.android.okhttp.Connection.connect(Connection.java:1331)
at com.android.okhttp.Connection.connectAndSetOwner(Connection.java:1410)
at com.android.okhttp.OkHttpClient$1.connectAndSetOwner(OkHttpClient.java:128)
at com.android.okhttp.internal.http.HttpEngine.nextConnection(HttpEngine.java:466)
at com.android.okhttp.internal.http.HttpEngine.connect(HttpEngine.java:447)
at com.android.okhttp.internal.http.HttpEngine.sendRequest(HttpEngine.java:353)
at com.android.okhttp.internal.huc.HttpURLConnectionImpl.execute(HttpURLConnectionImpl.java:468)
at com.android.okhttp.internal.huc.HttpURLConnectionImpl.getResponse(HttpURLConnectionImpl.java:410)
at com.android.okhttp.internal.huc.HttpURLConnectionImpl.getResponseCode(HttpURLConnectionImpl.java:532)
(It is the IP address of our server, replaced it with 111.222.333.444)
It's a time-out (> 15 seconds), while requests before that are rather fast.
I don't experience this problem with other devices, only on Samsung S6 when updated to Android 6.0.1. Because the app is on the foreground, I don't think it could be Doze or Standby (new in Android 6) because the app is being actively used. But the same problem probably occurs when app is in background (but it's difficult to test).
When turning off Wifi (so device uses 4G network) or Bluetooth (or both) the problem no longer occurs.
On a LG Nexus 5 (also with Android 6.0.1) the problem never occurs.
The beacon library we use: http://altbeacon.github.io/android-beacon-library/ (version 2.7)
Does anybody have an idea where we should look for the problem? Thanks in advance.
While this is the first report I have heard this on the S6, this is a common problem on other devices like the Nexus 4, Nexus 7, Moto G and Moto X. These devices experience interference between the WiFi and Bluetooth radios, which share the same radio frequency bands and in some device models share a chip and antenna. On the Nexus 4 and Moto G, the problem is so bad that streaming music while using a Bluetooth speaker is impossible. So the problem is not specific to beacons.
There is no known workaround, but you can detect the device model, and if it is known to be problematic, prompt the user to turn off WiFi. or even do it for the user (with proper notification, of course.)
It would be interesting to know if the same problem exists on an S6 with an earlier Android version. If so, this suggests a fix may be possible in firmware, for the S6 at least.
Full disclosure: I am the lead developer on the Android Beacon Library open source project.
Are you using setHostnameVerifier(new BrowserCompatHostnameVerifier()) ? If yes, remove it, because Android 6.0 comes with a new host name verifier.
Would a Bluetooth LE Jedi know any trick how to get a reliable BLE scanning mode on cheap Android 4.4 devices ?
Everything works fine from Android 5 to 6, and most of the Android 4.4 phones...
However, on some cheap phones with 4.4 we encounter random issues, some phones do not detect anything, or sometimes just a few beacons among others, depending on environment, daytime, weather, or whatever... It's obviously due to a poor software or hardware on this side, but is there any trick to make it more stable programmatically ? (for example enabling / disabling Bluetooth regularly)
EDIT
To describe a typical behavior:
First, note that it is the exact same behavior with all scanning Apps I could test (Estimote, Kontakt.io, AltBeacon, etc. etc.) - so this is much probably not a matter of App implementation.
It occurs only below Android 5 (4.4.2, 4.4.3, 4.4.4) and on cheap devices, never on phones like a Samsung S5 for example.
The behavior: let's assume we have 5 beacons very close (less than 2 meters, all working fine).
- Once rebooted the phone finds 5 beacons for 1 or 2 minutes.
- Then it finds nothing for 5 minutes.
- After a refresh it finds 2 beacons.
- Another refresh of the scan: only 1 found. Then none... etc.
I could not find any logic, for now it looks erratic.
Enabling / disabling Wifi / Bluetooth, Bluetooth+Wifi, Wifi then Bluetooth, etc. make sometimes the scan find one more beacon, sometimes not... there is probably not much difference if I just wait without changing those params.
The only way to get back a reliable scan is to reboot the device... then it works only for 1 or 2 minutes again...
It occurs on some very different devices (a Wiko Sunset, a Samsung XCover, an Orange Roya).
On more recent devices (Nexus 6, Samsung S5, Samsung A4...), 100% of the beacons are detected, for hours, and never lost.
So, as the complete reboot is actually the best solution to get all beacons detected I was wondering if there is a way to "refresh" the device's Bluetooth module without rebooting it... Or if we just have to become a philosopher about this ;-)
if you are develop your application using node.js then there are many api's avaliable which may work for you.But in case of android it is totally depend on your android version
we are developing an Android app which can connect to multiple heart rate sensors simultaneoulsy via Bluetooth Low Energy.
We have an implementation which is working quite well, so the code is not the problem.
What drives us crazy is the limitation of parallel BLE-connections which seems to be different from device to device.
We have a few test devices here: Motorola MotoE and MotoG, a Samsung Galaxy Tab A and an HTC Nexus 9. All of them are running Android 5 or 6, original vendor versions. None of them is able to connect to more than 7 BLE HR sensors simultaneously.
Then I have tested with my private Samsung Galaxy S4, which is rooted and has Cyanogen CM12 installed. With this device I can easily connect to 12 HR sensors simultaneously which is the number we want to achieve with our app.
I have tested this both with our own app implementation and with the Nordic Semiconductor nRF Master Control Panel which I think is a pretty good generic BLE app: https://play.google.com/store/apps/details?id=no.nordicsemi.android.mcp&hl=de
When I try to connect the app to a 7th BLE sensor on any of our devices, the ADB output prints the following error message:
E/BluetoothLeBasicConn: Connection state changing error: 133
I did some pretty intensive googling about that whole problem, but most of the results I've found were quite old. Some people said, that the limitation came from the Bluetooth Chipset itself, others said it was a software limitation through Android.
Could you help me to find out, where the limitation is coming from?
If it is the chipset, then I would like to know, which devices we should use for supporting as many parallel connections as possible. Sadly it is very hard to find out which Bluetooth chipset is built in the different devices. Hardly any of the hardware specs I found tell anything about this.
If the limitation comes from software side, can we change it somehow without rooting phones or install modded OS?
Thank you very much!
In case that you are still interested in it. The limit comes from
BTA_GATTC_CONN_MAX (hardcoded in android)
Which is set to:
4 on Android 4.3 and
7 on Android 4.4
There is by the way also a limit on the amount of characteristics for which you can activate notifications. (BTA_GATTC_NOTIF_REG_MAX)
which is:
4 on Android 4.3,
7 on Android 4.4 and
15 on Android 5.0
Since the recent release of Android 5.0 Lollipop I am experiencing very bad performance of the Bluetooth Low Energy API in my Nexus 4 device. With the previous OS version (Android 4.4.4 Kit-Kat) it worked like a charm, and the very same app run on 5.0 has the following behavior:
Frequently it does not detect any advertising packet from the peripheral.
The ADVERTISING_INTERVAL of the peripheral is 20ms, so the app should detect at least one advertising in 60ms in the worst case. I have tried with BluetoothLeScanner (with SCAN_MODE_LOW_LATENCY settings) not to use the deprecated mBluetoothAdapter.startLeScan(mLeScanCallback) with no success.
When it does, when I try to connect to the GATT server it rarely does.
I have checked with a BLE sniffer that the CONNECTION_REQUEST packet
is not even sent to the peripheral.
It seems I'm not the only one with this kind of errors and some other users have posted similar questions. Does anybody know what has happened?
--
Update 1: (2014/12/17)
I have also tested the same app with a Nexus 5 running Lollipop and it rarely connects to the GATT server. Every time I send a connection request, it never does because the peripheral does not receive the packet. Before upgrading this Nexus 5 to Lollipop, it worked perfectly on Kit-Kat 4.4.4 though.
Update 2: (2014/12/17)
Android 5.0.1 does not solve the problem at all.
Update 3: (2015/04/23)
Android 5.1 does not solve the problem either. Today I've had the opportunity to test Android 5.0.1 on a SAMSUNG Galaxy S4 and it works perfectly. I have also tested on the Nexus 5 with a fresh Android 5.1 install, and it works fine too. The problem still remains in the Nexus 4. They made something strange on the the firmware of Android 5.0 and subsequent releases that broke the perfect compatibility Android 4.4.4 had with the Bluetooth API.
reedited to a clearer answer
Last week i had some problems with bt after upgrading to 5.0 . Maybe
you can stop the bt process from apps in settings and it possibly
will reset everything like so:
Settings -> Apps -> Scroll over to All -> Select Bluetooth Share -> Clear Cache.
Shutting those services in instantiate them have been known to solve
this issue in some cases. you can also follow this link if it is
more clear:
http://www.gottabemobile.com/2014/12/01/nexus-lollipop-problems-fixes/
In my case i am nor expert in Bluetooth but I did solve this problems
after many trials. And I discovered that unplaging the bt dongle from
pc help also.
It is not generally recommended to upgrade so soon without checking
competency to bluetooth. As far as I have understood bt is known to
have issues at each upgrade
Good luck with your endeavor. If this answer is not enough I hope you find help from someone else.
I Think I may have found the answer
I had the same problem, it took 2-5 minutes to connect to my device AFTER I upgraded to Lollipop
This took 5 seconds before the upgrade.
The Fix:
Old code :
mBluetoothGatt = mBluetoothDevice.connectGatt(this, true, mGattCallbackSync);
new code :
mBluetoothGatt = mBluetoothDevice.connectGatt(this, false, mGattCallbackSync);
I just changed the autoConnect argument to false. It takes 5 seconds to connect now.
I hope this works for you.
Can anyone tell me if there have been any changes to the bluetooth functionality in the Android update?
I have an app which uses transmission and reception concurrently with a total of 5 connected devices and this works perfectly on a Motorola Droid2 with 2.2.1 but not on the ATRIX running 2.3
There may of course be a hardware element involved but I wanted to establish this first.
thanks in advance.
John
I had the problem that the bluetooth connection worked only on the second try - the first one almost always fails internally (IOException). And you don't have much time in between trials. This was on my 2.3.3 Sony phone. Logcat showed some messages that might imply an internal problem in bluez or with the bluez/java integration.
This problem did not manifest on a 2.2.x Samsung phone. Note that my program only uses one connection at a time.
Android website says "updated BlueZ stack", but that's all.
Did you check the logs, what are the errors you're getting?
Also, I guess you can try running different emulators with different versions of Android and see how that behaves.