Develop Reference

Bluetooth scanner reconnect android

I have a Samsung Galaxy Xcover 4, and a scanner (Intermec SR61).
The Samsung Galaxy XCover 4 is running an application 24/7, and never goes to sleep.
The Intermec SR61 is connected to this phone, and when scanning barcode, the application reads the barcode and handle the data.
After 24 hours, the Intermec SR61 loses connectivity to the phone.
It won't reconnect. I have to reconnect it through the application (disable/enable).
Why does this happen, and what can I do to make sure that doesn't happen?

I have created something similar and some phones connected to some scanners will do that. It is either a Bluetooth bug, a phone bug or a hardware thing.
There is not much you can do about it, I am afraid. Possibly you can change some settings in the scanner (sleep mode or something).
What I did to fix it, was to create a background process that keeps an eye on the connection and re-connects if it is gone. That process even goes so far to switch the Bluetooth adapter off and on again (because of problems on a certain phone).

Android Service And Lenovo

I'm trying to make App that will communicate with Bluetooth device. i have a service which set connection, get data from Bluetooth & collect it to int array, and sent users settings to device. Then when App ask for new Data service return array.When user change some data in App it sent it to Service and service sent it back to bluetooth*. I have tested this app on Sony Z, HTC, Samsung Tab2 - it works fine... But on ZTE, and Lenovo i have problems! The main problem that this devices have slow speed on reading socket.getInputStream(); too slow... i have a great delay... with data reading. And the App Crashes.
Why it so?
I think, i ll try to make to Threads in Service for get and sent data... but on devices Sony HTC Samsung.. it works fine! By the way Samsung have only 500 mb RAM (damaged) ZTE Blade and Lenovo Tablet must be more faster!

Android BLE, Can't connect to device

I'm making an application which has to talk to a BLE devices on Android.
I am running into issues establishing the connection to the BLE device.
Case 1) Scan:
During a scan after a device has been discovered and reported via
BluetoothLEScanCallback.onScanResult(...)
I am attempting the connect via:
result.getDevice().connectGatt(...)
Problem is on some devices I test this (namely HTC One M8 running Android 5.0.1 and HTC Desire 516 running Android 4.3) the connection process seems to fail, i.e. the callback
BluetoothGattCallback.onConnectionStateChange(....)
is simply not called most of the time.
Now this is not a consistent behavior, sometimes it is sometimes it is not.
The second problem is that often if the connection is established
the
BluetoothGatt.discoverServices()
call fails, i.e. the
BluetoothGattCallback.onServicesDiscovered(...)
is also not called. I tried retrying the call a couple of times spaced by X number of milliseconds but it seems to consistently fail regardless of the number of attempts or spacing between them.
Case 2 Listening
The pretty much same thing happens when I attempt to simply "listen" for a device, again calling
BluetoothDevice device = BluetoothManager.getAdapter().getRemoteDevice(macAddress);
device.connectGatt(...)
results often in the same situation.
In both cases I am having issue with Android most of the time, I have a Nexus 5 device on which that same code seems to work for the most part (sometimes the BT stack seems to fail to do its job)
A bit more disturbing that the iOS application we have has none of these problems.
Has anyone encountered these issues?
Any ideas how to address them?

EDIT:
We did "solve" this one. Just in case somebody stumbles on such situation, the issue in my case is that ymmv a lot from device to device or even from connection to connection.
Sometimes the process happens in a second or so other times it takes 5, in my tests it can climb up to like 15 on the devices I test with.
As for why this is I can't tell.

I encounter the same problem. I connect to a Bluegigga BLE113 bluetooth 4.0 module. My app is based on the BluetoothLeGatt Sample source. My Samsung phone connects great, with no problems. My LG V10 can't connect. Except sometimes, when it will connect. Mostly, it won't connect. onConnectionStateChange never gets called. It is very frustrating, and I haven't been able to figure out the problem.
But I can connect my LG phone if I use NRF Connect, which seems to prove there is a programming solution. But they don't release the source for NRF-Connect.
If anyone can expand of how to fix this, I would appreciate it.

Android Bluetooth cannot be turn on, after it has been turned off while BluetoothServerSocket.accept() is working

I'm developing an Android program that uses Bluetooth.
The first device is Haier W718 Android 4.0.3 , the second one is Samsung GT-P5110 Android 4.2.2. They both listen and may connect each other and transmit some data.
Almost everything works properly but I encountered a strange problem in Haier W718.
If I turn off Bluetooth of my Haier device, when my program is listening (BluetoothServerSocket.accept()), sometimes I can not turn on Bluetooth again. I press the Bluetooth icon in the status bar, but nothing happens.
In case I manage to turn Bluetooth on, BluetoothSocket.connect() gives me the error "IOException Service discovery failed", however BluetoothServerSocket.accept() works good.
In order to solve this problem I have to turn my phone off and on again.
What may be the reason of this strange behavior?
I have only 2 Android devices and Samsung works good. May it be a problem of Haier firmware?

Am I having a SocketTimeoutException in Android because the phone is switching network connections?

I have an Android app which, as part of its core functionality, makes ASP.NET WebService calls. I have authored the app successfully using ksoap2 to make the calls and it does what I need it to.
Our client reports that they have found some phones where the app does not work. Namely, during some of the WebService calls it appears to time out. This befuddled me because it works perfectly on the handful of phones we've tested it with here in my office.
One of the phones the client reported having an issue with was the Samsung Galaxy S2 on Sprint (the other phone they reported was either a Samsung Galaxy S or a Samsung Galaxy S3 - real similar phone, in other words). As luck would have it I was able to hunt down an employee in the company who had a Samsung Galaxy S2 on Sprint and was willing to let me borrow it. And I was able to re-create the issue. Attached to Eclipse it appears to be getting a SocketTimeoutException. Not every time, but more often than not.
As part of my testing, I connected the phone to a MiFi on Verizon. So, essentially I was taking it off of Sprint's network and putting it on Verizon's. When I did this, the app worked as expected, no timeouts.
At first I thought maybe Sprint's network was just bad but that seemed unlikely seeing as how my client is on the other side of the country from me so unless their network is consistently bad I doubt that's the case.
But what I noticed is - in the status bar of the phone, when connected to Sprint, I saw 3G and 4G icons, and they appeared to be switching back and forth (the way they're laid out, they both appear, just turned off/on right next to each other). When I was connected to the MiFi, as far as the phone knows or cares I'm connected to a Wi-Fi point.
So what I wonder is - could it be that the phone is "switching" back and forth between the 3G and 4G networks and the response to the webservice call is getting lost? On the iPhone if you make a request for a webpage in Safari with your phone on the 3G network (for example) and the phone then finds a Wi-Fi point to connect to and switches over, you still get the webpage on your device even after it connects to Wi-Fi. I presume that the OS is allowing the 3G calls to finish out before switching that network off.
Could something that Samsung has done with the OS for the Galaxy S* line be causing my responses to be getting lost? And if so, is there something I can do about it to prevent this from happening? Is there a way to figure out what network connections are still alive?
UPDATE: See my answer below, this question's premise turned out not to be the reason, although it does occur to me that I forgot to point out that the particular calls that fail or timeout contain base64-encoded images and so they're larger than normal webservice calls.

For what it's worth, the answer appears to be "no"
I used the code from this blog entry which allows me to monitor when a network connection change occurs and I was able to verify that the behavior occurs even when the network connection doesn't change.
So it does appear that for whatever reason this particular combination (Sprint/Samsung Galaxy S or S2) doesn't like what I'm doing.
One thing I forgot to mention is that I'm sending a Base64-encoded image across the web service call so the size may have some relation to it but I can't figure out what the issue is exactly.