I am using my Android phone as a receiver for a Bluetooth sensor located on the room. I am struggling in solving an issue, whenever I leave the phone unattended (I am sleeping), the app keeps logging information for some time but then everything is stopped and only starts working if I start the app again.
My device is a Samsung Galaxy S7, but this has happened across many manufacturers and models.
Related
I'm currently having issues with Samsung Devices running Android Pie.
My App is using a foreground service with an active notification. Once a geofence is entered I'm scanning for a bluetooth beacon.
This works on all devices across all Android versions (also used to work on Samsung devices running oreo).
The problem begins after entering the geofence.
It seems like the system prevents the bluetooth scan from starting as long as the display is black.
Once I press the power button (without unlocking or even opening the app) I see the scan results coming in.
I'm already using scan filters since this led to the same problem on all android devices after updating to oreo.
Has anybody experienced the same issue or could point me in the right direction?
Kind regards
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!
Overview:
We have developed an app that allows customers check in using an NFC enabled card with a stationary Nexus S. The app sit ready to read a card, when a card is tapped, the app reads the unique ID for the NFC card.
Problem:
The challenge we have run into, is that the Nexus S locks up after scanning 50 to 100 tags. The app continues to function, and so does android, however neither our app, or the native app within android will read a tag. It is as though the scanner has been disabled. I have tested it using 4 different Nexus S devices running Android 2.3.6.
Debugging:
The only solution I have been able to find is to either:
- power the nexus s off and then power it back on
- disable NFC and then re-enable it through Setting --> Wireless & network settings --> NFC
If either of those are done, the scanner works again and app continues to work as normal until it locks up again after 70 or so scans.
Any idea how to fix this bug, or work around the issue?
Update: it appears as though this is not just with our app, testing the "Tags" native app that comes with the Nexus S also has this issue.
We have experienced the same issue with our NFC apps. Seems to be a hardware issue. We have done the same thing you are doing by re-enabling NFC in settings.
Unfortunately I don't think it's your problem so you may have to report the issue directly to Samsung or Google via Samsung Tech Support or a Google Android bug report.
Another thing to do is to see how the tag recognition works with the new Galaxy Nexus when it gets released in the next 2 weeks.
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.
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/