I have written an VPN using android's VPNService and it works perfectly. When I run it, it creates a foreground service and sends all traffic through my VPN server. It also has an internal reconnecting mechanism to reconnects VPN server if it disconnects for any reason without stopping service itself.
I like to have this VPN service working all the time. But my problem is that this VPN service is stopped occasionally after a completely random period(sometime it takes just 10 minutes, but other times it works for 2-3 days before stopping).
Since the stopping time is completely random and I cannot find any place in code that creates this situation (I have been debugging for weeks), I thought maybe android OS itself stops my VPNService for some reason. I wonder if there is a way to detect if system has stopped my service from outside or not. Any idea?
Unfortunately, Android OS still can terminate the service in low memory and possibly other situations, even if it's a background running service !
It is not only Android, but all Mobile Operating Systems optimize RAM usage by killing background apps.
This is done so that the foreground app can be given top priority. It ensures smooth functioning of the current app and reduces load on the system.
There's are two approaches as mentioned in this post: Background Service getting killed in android
If you are implementing the service, override onStartCommand() and
return START_STICKY as the result. It will tell the system that even
if it will want to kill your service due to low memory, it should
re-create it as soon as memory will be back to normal.
If you are not sure 1st approach will work - you'll have to use
AlarmManager
http://developer.android.com/reference/android/app/AlarmManager.html
. That is a system service, which will execute actions when you'll
tell, for example periodically. That will ensure that if your service
will be terminated, or even the whole process will die(for example
with force close) - it will be 100% restarted by AlarmManager.
I had this issue previously and I've solved it by creating the service running forever even if it's killed manually or from the system it recreates itself.
Related
My Android app activity binds to a service, which connects to a BLE peripheral and receives data. It does this until the user presses a button on the activity to disconnect from the peripheral and stop the service.
Sometimes after running with the screen locked for about ~45 minutes+ the activity and service are terminated. My conclusion was that Android 8.1 was more aggressive than previous operating systems, so I changed the background service to a foreground service, and made sure that once the peripheral is connected I stop scanning.
This didn't work, and every now and then my app is killed in the background, and I don't think it is an uncaught exception. I have read the Android docs on Services and the Application Lifecycle and have added some debugging logs into lifecycle callbacks, which hasn't helped. I have observed this behaviour on Huawei Y5 and Nokia 8 running Android 8.1 - I don't remember it being an issue on an older phone which I no longer have.
I have a few questions about behaviour that aren't clearly documented that might help me figure out this issue. Thanks for your help!
1. If an activity is killed in the background and it is bound to a service, will that kill the service?
2. If a service is killed in the background, will that kill my activity
3. If there are multiple services running and one consumes too many resources, does the OS kill everything, or just the misbehaving service?
4. What sort of things makes an activity or service a target for the OS? Holding on to wakelocks permanently? BLE scanning? Receiving too many BLE packets? Uploading too much data? Any insight here about what might be happening under the hood is appreciated.
5. Does having the phone on charge prevent the OS from killing apps? I believe it occurs in my case regardless.
There are several reasons for Android to kill.your activity. Therefore it is not a good idea to setup you bluetooth in an activity. Set it up in a seperate class or in your Application class and use other ways to send data to your activity, e.g. broadcasting. That way it will keep working even if your Activity is killed or recreated.
Is your application really being killed or is it just your Activiry that is killed?
Android app that I am working on reads from near by beacons(devices) using bluetooth. It works fine when the app is in the foreground (tested it for 20 minutes). However, few minutes after app goes to background it stops reading.
I notice when app goes to background, onpause() method is executed; still my app reads for few minutes and then simply stops reading anything (when I manually bring the app to foreground, oncreate method is executed and app continuous normally).
Why is my app stopped reading few minutes after it went to background. My app is an activity and not service.
should convert the activity to service or
should I create intentservice or
should I create foregroundserive
I donot understand the difference between above 3 types of services and if any of them would help me.
Though slightly older threads, I reviewed Prevent that the app get stopped or paused by the OS and How can we prevent a Service from being killed by OS? and my app killed by android system when it running in background
But I am lost. Any discussion is appreciated
EDIT
As I understand from #davidgyoung answer, I have to write a service. I assume GUI portion of my app goes into mainactivity; then how I can ensure my mainactivity/GUI is still active in memory and was not killed by Android by the time service tries to broadcast/notify GUI
/EDIT
An Activity is not designed to run for long periods in the background. The Android OS will destroy activities that are not visible as memory is needed for other functions. While a Service is the proper alternative, even a service will be destroyed under memory pressure by the OS, so you still need to restart the service if it is killed by the OS and you continue to want to do beacon scanning.
All of these issues came up when we built the Android Beacon Library, and we settled on these solutions to keep scanning going:
Use a Service to scan for beacons in the background. It does not have to be an IntentService, but that is a reasonable option.
Use an AlarmManager to restart the scanning service 5 minutes in the future in case it gets killed. (This delay allows the OS to time to recover from a temporary need for extra memory.) If the scanning service is still running, just reschedule the alarm.
Register for OS level events (boot, power connect/disconnect) to restart the scanning service at a later time if the user kills the app with the task switcher.
All of this is built for you if you decide to use the Android Beacon Library (and we welcome contributions, too!) If you want to roll your own, you may want to look at the source code to see how these things were built. Feel free to copy and modify, too. That's the beauty of open source!
Full disclosure: I am the lead developer on the Android Beacon Library open source project.
I am working on an Android project and I need the app to work even when the device is locked.
The idea is to open the app that will start the (Intent)Service, the service processes the data all the time. The device can be locked/put away and after some time when the app is opened the service is manually stopped. The service should be running all the time in the background.
I have found information online, but I am not sure what to use and in which way..
I have found that the IntentService can be used. Also the service should run in a new thread. I need to process the data from gps all the time, should I use WakefulBroadcastReceiver?
Thank you.
IntentService is not necessarily what you want to use. It will automatically spawn a new thread just to handle an incoming Intent. Once all incoming Intents have been handled it will stop the Service. To have a long running Service, you would need to derive from Service and when it is started return START_STICKY from the onStartCommand() method, plus spawn your own thread to handle your background work.
If you need to monitor GPS, you'll have to manage that along with keeping the device awake using a WakeLock. Note that in Marshmallow, this gets more complicated because of the new Doze mode where even wakelocks are ignored.
Also, note that the way Android is architected there is still a chance that your application running the background Service may be killed. Android uses a unique process management technique based on memory pressure and user perceived priority to determine how long a process should stick around. I recommend reading up on the Service lifecycle in the documentation.
In android their is no fool proof way to ensure that your service runs forever because the LMK(low memory killer) when the system needs resources (based on a certain memory threshold) , kills the service then if it can restarts it. If you handle the restart properly the service will continue to run.
Services that are given foreground priority are significantly less likely to be killed off, so this might be your best bet. However their will be a notification of your service running the in the background on the menu bar up top. Foreground Service
I have an Android application which supposed to be active in the background all the time. I've built it as normal Android application. It works pretty fine, however, sometimes it stops by itself (or by Android OS) and have to re-run it. It's not because of an error caused, this is because it's a normal application, perhaps.
How do I make work all the time in the background?
UPDATE:
the application has GUI.
Android OS may terminate a process at any given time due to memory constraints, you can learn how Android manages memory here. As #Karakuri mentioned starting a service would make it much less likely to be terminated, another plus for using service is that even in the event that it is killed the OS would try to resurrect at a later time when memory constraints permits:
Note this means that most of the time your service is running, it may
be killed by the system if it is under heavy memory pressure. If this
happens, the system will later try to restart the service.
You can learn more detail on Services from the Android dev site.
Create a Service and call startForeground() to make it a foreground service. It doesn't prevent it from being killed, just makes it less likely as Android will try to keep it alive longer than non-foreground services. Note that you need to place an ongoing notification with an icon on the status bar when using a foreground service.
Assuming you are using a Service. If you return START_STICKY from onStartCommand() of service, then even if android has to terminate that service, it will be re-started as soon as the resources are free.
I notice that applications like Skype use a service which basically runs 24x7, without getting killed at all. You cannot even manually kill it using task killers ( you can kill them by going to running services and kill service ). How is this implemented?
I find that in Android 2.3, my service gets killed after running for sometime. onDestroy() is never called even if I start the service with START_STICKY. However this works fine on my 2.1 device, that is the service doesnt get killed.
Thanks
How is this implemented?
Based on the Skype screenshots that show a Notification icon, then they are most likely using startForeground().
I find that in Android 2.3, my service gets killed after running for sometime.
That is perfectly normal.
First, most Android applications do not really need a service that "basically runs 24x7". Users do not like such services, which is why task killers and the Running Services screen and the auto-kill logic in the OS exist. The only reason a service should be running "24x7" is if is delivering value every microsecond. VOIP clients, like Skype, will deliver value every microsecond, as they are waiting for incoming phone calls. Most Android applications do not meet this criterion.
If your service is running constantly, but for a user-controlled period (e.g., a music player), startForeground() is a fine solution.
Otherwise, I would rather that you find a way to eliminate the service that "basically runs 24x7", switching to a user-controllable polling system using AlarmManager, so your service is generally not in memory except when it is delivering value.