On Android Oreo, If my app starts a service while in foreground and then I close my app, will the service be killed later on? or will it stay alive?
From this video post it seems like the service will be killed if the app is in background, https://www.youtube.com/watch?v=Pumf_4yjTMc&t=198s
However, while testing, the service is quite alive. Will appreciate any productive feedback.
The service gets killed eventually
When an app goes into the background, it has a window of several
minutes in which it is still allowed to create and use services. At
the end of that window, the app is considered to be idle. At this
time, the system stops the app's background services, just as if the
app had called the services' Service.stopSelf() methods.
https://developer.android.com/about/versions/oreo/background.html
The service´s call and all of your current aplication´s process will be killed if you close or destroy your application, cause all of these process are linked to your app´s lifecycle, if the lifecycle is closed, killed or crashed, all of the processes go to the same end.
Thanks for your answers! Appreciate your responses. It Was my bad as I switched the work branch that wasn't targeting API 26.
I think, it's worth mentioning that the above restriction is only applicable if the app is targeting api 26 (Android O).
I have started moving to Job scheduler, and that seems to be working on Android O.
Related
I am building a ride-hailing app and I need a real-time driver location update even when the app is closed or in background, according to the new android os versions I can't use background services even if I could use it the os might kill it so my best option is to use foreground service with a noticeable notification, my question is, is it possible to use an ongoing foreground service for realtime location updates without being killed?
A foreground service can still be killed, its just less likely to be so. If the user was to open up a couple of memory hogging apps that meant it really needed your apps memory, it can still be killed. There's a priority to what stays in memory, having a foreground service just makes it higher priority than an app with a background service using the same resources. That said, a foreground service is your best bet for short duration updates like that.
Note that there's a difference between "closed" and backgrounded. If the app is backgrounded, a foreground service will continue. If the user terminates the app by swiping it away from recents or force stopping it, the foreground service will also be killed. But the foreground service would allow him to move to another app (like Waze or something) without killing your app unless the phone goes really low on memory.
i have a problem look like you . i am searching a lot and i test
foregroundservice , alarmManager , Worker and ...
none of them isnt working well and suddenly service stoped ! .
in the end i find 1 ways :
1- handle service in server in backened with pushNotificaiton .
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.
We have stumbled upon an issue in Android 8.1 and above that, we haven't seen before, and that, unfortunately, makes our app less convenient for our users. Background sticky services in Android 8.1 and above isn't re-started when user swipe kills the app.
In Android 8.0 and below, there are high promises for services to be always available in the background, especially for services that are implemented as "sticky services".
To sum it up, the non-sticky services is not re-launched during a swipe kill in the recent app list. For sticky services (application host together with the service), the app is re-launched shortly after the kill. And foreground services apps are actually never killed, even during a swipe kill.
This works as intended and just fine in Android 8.0 and before. So, after a kill swipe, the app process is re-created within a short time, and then onCreate and onStartCommand is called, starting up the service completely again.
But from Android 8.1, the onStartCommand call is omitted. So instead of getting onCreate and OnStartCommand, we get onCreate and OnDestroy. This effectively does not make the service active again. Needless to say, we cannot manually start our own service in onCreate either.
I think the following article shows the differences quite clear (and with functional code) between non-sticky services, sticky services, and foreground services.
In Android 8.1 and above, the onStartCommand call is omitted (and therefore the service is not restarted). So instead of getting onCreate and OnStartCommand, we get onCreate and OnDestroy during app re-creation.
Also, we would not prefer to have a visible app icon at the top persistent all the time (as when using setForeground service), and rather just let it work in the background without bothering the user too much.
Don't Optimise Battery may work your service to run properly
you can also use AlarmManager to restart service after a fixed time
it could help click
from android 8 shouldn't be started service in background, you must start service as foreground.
my suggestion using android workManager supported by Google link
workManager is a stable and reliable library for working with service and schedulers task
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.