I have an app that uses bluetooth SPP (RFCOMM) to communicate with a piece of hardware. The app and the bluetooth connection work great. The problem is when another app is started that also uses SPP and then one of the apps is stopped. Once either of the apps is stopped, either by quitting the app or by using a task killer, the phone slows down to a near halt. Most of the time I have to pull the battery.
I have seen this with Pandora, which uses SPP, probably as part of its Ford Sync support, and with my app. I have also seen this with the sample apps for SPP. It doesn't matter which apps I use. Any two apps that use SPP cause this.
I have seen this on Android 2.1, HTC device on ATT. I did not see this on a Motorola Droid running 2.2.1 stock, however I did see this on the same phone while running 2.2 and LFY 1.95 ROM with a custom kernel.
I have logs from the debugger if anyone needs to see them, but I see nothing in there that points out the problem. Once either SPP apps is stopped the slow down starts immediately. I still get logs but nothing at all indicating a problem. The slow down does not stop until the phone is rebooted.
OK I'm just going to blame this problem on HTC. Seems like HTC devices running Android 2.1 have a very buggy Bluetooth stack. There are lots of complaints on HTC's forums about bluetooth issues.
I was able t work around this by closing my SPP connection when my app is pushed to the background then restarting the SPP connection when my app comes back up.
I don't want to do this because a future version of my app will need a SPP connection even when the app is in the background. I just hope HTC fixes their buggy software before I implement this.
If anyone has more info on HTC's buggy bluetooth stack and the inability for HTC devices to handle more than 1 SPP connection please post.
Related
I am working on an Android application that uses Bluetooth to communicate with a nearby PC.
The app works greatly on my own device (Samsung Galaxy Note 3 - CM 12.1) but on of my beta-testers it does not.
Simply put the app allows people to write and receive SMS from their
PC (with my C# WPF app) via Bluetooth & their phone.
My beta-tester is using a Samsung Galaxy Note 4 stock ROM (Lollipop).
At first I thought when his screens turned off, Android would kill the MainActivity which holds on a few threads including the one maintaining the connection alive (with a inpustream.read() blocking method). Such behavior does not occur on my own device : I could keep the connection alive for a whole night without plugging my phone.
I was warned, though, that using services would avoid such problem because Android does not behave the same way from one device to another. So I updated my app and made my MainActivity use my MainService to spawn the relative threads. But it did not change a thing.
As my title suggests, the problem lies with his antivirus and more precisely : AVG.
I have no knowledge on how such antivirus work on Android and I don't even use one. By freezing AVG with Titanium Backup on his rooted Galaxy Note 4, my app stopepd crashing and is now working perfectly well as intended.
So I wonder, how come AVG deciced to kill my app when the device screen turned off?
How should my app behave so that this won't happen with any other users using AVG or any other antivirus ? What should I do so that my app does not look as a suspect ?
I don't know exactly what the AVG did to your app.But I think that AVG may don't let your app force to turn on the bluetooth or use the Bluetooth when Android device is sleep or send/receive SMS.The AVG is one kind of antivirus apps that most of them have lots of permission request limited or power saving strategy,especially on rooted Android devices or the first part app already in the Android ROMs.
Try to make clear that what's the real point AVG did to your app.And then try to solve your problems with gentle and smart.
For example：
1.If the AVG doesn't let you use BluetoothAdapter.enable() to force to turn on the Bluetooth, try to use Activity.startActivityForResult() to let users to choose whether turn on Bleutooth or not.
2.If the AVG doesn't let you use Bluetooth when the Android device is sleep.You can try to use WakeLock.acquire() to hold the Android device.
3.If the AVG doesn't let you use SMS sending or receiving.You can changed another communication protocol, SPP or BLE or something else.
Maybe you have heard Xiaomi.If you are an Android Developer in China,because Xiaomi is very popular in China,you must deal with the adaption with Xiaomi,and then you will find that Xiaomi is really fucking for Android Developers in China.
Xiaomi doesn't some really amazing things to the original Android.For example:
1.
AlertDialog..getWindow().setType(WindowManager.LayoutParams.TYPE_SYSTEM_ALERT);
you can't alert the TYPE_SYSTEM_ALERT dialog on some xiaomi ROMs that they tell you nothing.
2.Xiaomi has modified lots of original themes.
3.Xiaomi has changed the Android alarm timing mechanism while the device is sleep which is called Wake-Up-Alignment.This is really terrible for the apps that with the function of timing.
The above problems are that I met in Android development, some problems I can resolve it, some you don't have any chances to change it.
Remember that:The adaption with Android devices is that you must make your users know you app works on most of the popular Android Devices,the developers try to make the app run on most Android devices,but it maybe not work on some Android devivces with customized ROMs or with some special third part apps.That's it ,that's true, that's Android.
If the problem can't be solved,it's not a problem!
I'm developing an Android application able to connect to a BLE (Bluetooth low energy) device.
Problem is after connection, when I want to re-connect to an other device, I can't.
The only solution is to off and on phone bluetooth.
(On the iOS app, it works so problems is from Android app).
I get this error :
BLE connection generic error
I there any known bug on Android >=4.0 on BLE connections ?
There are lots of bugs in the bug tracker and the documentation and example are not good.
You have not given enough information to really be able to tell what your specific problem is but the main issue people fall over is thinking that because the api calls are asynchronous you can just use them that way. In practice you need to use them in a synchronous manner e.g. wait for one call to finish before issuing the next. I am not clear if this is by intention of just a buggy implementation but it is the case at the moment.
There are definite issues in the underlying framework / drivers as you can get the system into a state where it want allow Bluetooth to switch off, it want work without switching Bluetooth off and on again, it want work without rebooting your phone, it want work reliably with Wifi enabled. If you go through the bugs list you will find more.
In my opinion it's not at beta standard yet but we have been trying to live with it for the past 9 months and Google look to of stopped working on it as far as I can tell from the updates we have had since the initial release.
I am thinking of developing an Android app that would, as part of it's function, send-to and receive-from broadcast messages from all devices that are currently connected to a WiFi network.
While a lot of developers have suggested that such a requirement would need the application to acquire the MulticastLock, there are experiences out there that say:
Acquiring the MulticastLock successfully cannot be relied upon since the acquire() method does not return any status on the operation requested.
And even if you do acquire the lock, it's not guaranteed that the WiFi stack does not filter out packets that are not directed at the device.
There are others that say multicastlock works reliably on versions 2.3.3 and above and that the problem of reliability is only for devices running 2.3.2 and below.
Some of them say nothing is guaranteed (now or for future devices) as support for broadcast and multicast is a chipset controlled functionality and that OEMs have the final say. They cite battery drain being the primary motivation for OEMs to either allow or deny software configuration of the chipset.
So, before i delve into my project, i wish to know what the current state of this issue is and if what i am trying to do is feasible i.e no guess work involved. If there is a work around, i am willing to implement that as long as i know it will work reliably. Kindly share your opinions and experiences. Thanks in advance.
I have used Android apps based on DLNA (like iMediaShare and WDTV Live Media Player) that use multicast for Discovery and Streaming, albeit, this was on JellyBean and not on pre 2.3.3. The apps were able to discover other devices on the network. This could very well be a pre 2.3.3 issue.
Both the apps mentioned above say that their app works with Android version 2.1 or 2.2 and up
I am trying to detect my iPhone on my Android 1.6 device using Bluetooth without interaction.
I can do it when the iPhone is discoverable, meaning I have to interact with the iPhone, going through menus to Bluetooth section.
For what I have searched so far, it's seem impossible to detect the iPhone, even if it has been previously paired (paired is only a kind of shortcut to avoid the heavy discovery process).
Does anyone know any solution ?
Thanks
Antoine
In my experience, if the iPhone goes out of range or otherwise disconnects a BT connection, there is no automatic reconnect, you have to go in to the BT menu in the iPhone.
I have not worked on iPhone vs android on this, but I know a lot of the car stereo and gps manufacturers are having problems with the iPhone not reconnecting automatically.
At the moment they don't have a solution, so I doubt there is one.
Short edit for clarification: This is not an android problem, I work on BT certification and licensing, and android can drop a connection and reconnect automatically. (Under the condition that the phone supports that BP profile, but they all do.)
I have 2 applications w/ the bluetooth code derived from the Bluetooth Chat sample. Individually they work fine. Each app connects via SPP to separate devices. The issue I'm having is on phones with Android 2.1, after the first app connects to its device, you can press Home and get to running the other app, but as soon as the connection is made to the other device with this other app, both apps get the "Sorry! The application xyz (process com.xyz) has stopped unexpectedly. FORCE CLOSE" dialogs. There are try/catch blocks throughout the bt code, for which the catches are not executed. Neither app will then connect (individually) until after bluetooth is turned off then on again. This does NOT happen when these same apps are running on a Samsung tab with Android 2.2 - both apps can run and connect to the devices simultaneously just fine and you can switch between the apps, no problems.
Is this specifically an Android 2.1 issue or something else? Whether it is or not, I need some way to prevent the app from connecting if another app is using bluetooth. I couldn't find anything in the Android APIs that would allow finding this out. Is there any way to coordinate/manage this? Does anyone have any specific insights into this whole issue?
I think it is a bug in the samsung bluetooth stack.
upgrading the my samsung to cyanogenmod fixes it.
see this link
http://www.samsunggalaxysforum.com/firmware-problems/connection-problems-sgs-bluetooth-spp-device/