I have a few questions about certain behavior on Android devices.
I'm using SDK which ask the user to turn-off battery optimization for the app.
I'm also running a foreground service which implements some interfaces from said SDK.
I need the foreground service to run as long as possible with out any other interaction with the app.
What I wanted to know is:
If the user allows to turn off the battery optimization - does it mean that the OS can't kill my foreground service (or it will be killed under some strict conditions).
If the user doesn't allow to turn off the battery optimization - does it mean that the OS will kill my service more easily?
If under some conditions the OS kills my service, the foreground service is also dead, will the service come back to life if I made it START_STICKY and if so, how long does it take it to restart?
Each manufacturer implements Android in a different way, so a specific behaviour seen on (as example) Samsung could not be the same on Xiaomi, and vice-versa. Battery optimization could not involve Services in the way you expect, or maybe yes. It's impossibile to find a fixed rule for this.
(same as 1)
the restart is near-instant, it takes just the time to empty memory, release locks/files and similar things and finally run an "internal startService()" method again.
I'm using a Background Service as the main purpose in my App (it creates some floating windows/interfaces when needed) and I never seen that the OS killed my Service in more than 6 years. However the Service should support to be killed and restarted without FC something.
Related
Im a bit confused on background limitations of apps, and I could use an explanation. So, starting from android 8 we have limitations on services and sending broadcasts. As for now, we can only make service run in background if it has the foreground notification, otherwise it will be killed. The app is considered to be in background if none of it's activities are visible, and my questions are: 1. For how long can the app-process itself live without foreground service? For instance, if I go to home screen, thereby putting app in background my app can still play sounds for hours, but I expected it will be killed by system in a couple of minutes. 2. Is foreground service somehow related to application lifecycle? For instance,maybe if I start the foreground service then my app won't get killed or less likely to be killed by the system.
I'm asking all this because my app is using c++ libs to make VOIP calls and do other stuff in background and I'm wondering what would happen if I just open the home screen and leave my app working, so far I've never seen the system kill the app while the call is active.
For how long can the app-process itself live without foreground service?
Android low memory killer daemon monitors the system constantly. If there is high memory pressure, least essential process gets killed. If there is not a memory problem, your app might live in the background for a long time. However vendors might limit the number of background processes. If this limit is 3 and your app falls to 4th place, it gets killed even if there is no memory pressure. And some vendors just kill the unvisible apps and there is nothing you can do about it. You can check this answer for a similar problem on OnePlus devices.
Is foreground service somehow related to application lifecycle? For instance,maybe if I start the foreground service then my app won't get killed or less likely to be killed by the system.
According to Android Processes and Application Lifecycle documentation foreground services have the 2nd highest priority in the system. So the answer is yes, if you are running a foreground service, your app is less likely to be killed even if you do not have a visible Activity.
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.
I'm creating an app that captures location every 30 seconds. To do so, I've a foreground service and a handler in it that gets the latest location every 30 seconds. The app is working just fine for many devices with stock OS. But, on some devices like OnePlus, Panasonic, Vivo etc. the foreground service gets killed by the OS(sometimes the app too) even after changing the battery optimization status and the doze mode. I know that it is not possible to create a service in Android that does not die. Is there any way I can achieve what I'm trying to? Please let me know. Thanks!
First of all, yes you are right the operating system will stop services when resources are limited, so to get around this you state the type of the services while creating them as the following:
START_STICKY, START_NOT_STICKY, START_REDELIVER_INTENT...
read the last part of this article it talks about when to use which of them
https://android-developers.googleblog.com/2010/02/service-api-changes-starting-with.html
Service.onStartCommand() callback that allows the service to better control how the system should manage it. The key part here is a new result code returned by the function, telling the system what it should do with the service if its process is killed while it is running.
I would like to upload large files (~10 - 100Mb wifi or mobile network), but in background, because the user maybe will leave the app and later the system will close the app (if not enoguh memory) I created a service for this case but my problem is that when i killed the app the service restarting and the uploading start again. I found same problems without solution:
keeping background service alive after user exit app
My service is restarted each time the application is closed
So it won't work, but what is the solution? How does the youtube app???
You should use a foreground service via the startForeground() method if you are concerned about the possibility of the service being killed.
From the Service Lifecycle Docs:
A started service can use the startForeground(int, Notification) API to put the service in a foreground state, where the system considers it to be something the user is actively aware of and thus not a candidate for killing when low on memory. (It is still theoretically possible for the service to be killed under extreme memory pressure from the current foreground application, but in practice this should not be a concern.)
Do you have control over the server? This seems just like:
Uploading big files over HTTP
Googling brought up a proposal for the Gears project:
https://code.google.com/p/gears/wiki/ResumableHttpRequestsProposal
If you can use a server/plugin/module that will allow for Ranged PUTs, that's your best bet, otherwise you may have to roll-your-own "chunking"... Depending on your tools and knowledge, that may be the best option anyway, you could tweak it to optimize it for your specific mobile conditions.
I am relatively new to Android, so what I am asking may seem obvious (although I have read all the similarly titled questions, and have searched extensively). I need to monitor the accelerometer continuously for long periods. Two approaches have been suggested:
1) acquire a partial wake lock that is held the entire time the acceleromtere is being monitored; and
2) monitor the accelerometer in a foreground service.
The first approach appears to use a lot of battery life. The second approach should result in a service that is only killed rarely, but I'm not sure what "rarely" means. Which approach should be used, and are there alternatives that I should consider?
Holding a WakeLock and a foreground Service are not really related and shouldn't be compared are to which direction is best.
Android OS is built to swap out processes based on a variety of factors. This means your process might get killed at any point by Android and it provides a framework to help you, the developer, to ensure your app can save and restore its state when this happens.
A WakeLock simply prevents the CPU from sleeping which helps save battery when the phone is not in use.
Now, a combination of both would help you achieve what you want but at great user cost. I wouldn't want an app in my phone to keep the CPU constantly running or a notification icon to show up constantly in the notification bar (that's what a foreground service does).
Keep in mind, starting a service in foreground mode does not guarantee your app will not get killed. It might still happen albeit rarely.
What is it you are trying to achieve here? Why keep monitoring the devices accelerometer? Perhaps you should only monitor it only when an Activity of your app is in the foreground instead.
I had exactly the same need and problem. I believe the solution is to use both a partial wake lock and a foreground service. Android will try not to kill a background service that holds a wake lock but is free to kill it when it needs the resources and possibly restart it later. That's fine for a lot of purposes but at least in my case that is not good enough. Putting a service into the foreground state is the way to tell Android that that killing it is unacceptable. Yes, it might still happen in extreme situations but that would now be a violation of the API contract whereas with a background service Android is free to kill it. You should therefore probably code as if that that will never happen but just know that this is a possible but probably rare error.