I'm building an application similar to Runtastic/Endomondo/Strava, which needs a service getting GPS locations until the user stops it explicity.
I ran Runtastic and my app to try it. Runtastic worked fine. But my app, looses all data altought the notification was in the status bar yet. I think the service restart itself, or Android kill my service.
I tested the app in a LG G3 with 2GB of RAM, which I consider it's enought to run Runtastic and my app.
So, my question is ¿what is the best way to keep a service running in background, or avoid the system kill it? I want to emulate the logic of Runtastic/Endomondo/Strava. That means, it doesn't matter the battery life.
I've tried start the service with START_STICKY flag on method onStartCommand.
I've tried to start service with startForeground method
I've tried aquire a WakeLock
Following the documentation (https://developer.android.com/guide/topics/processes/process-lifecycle.html) my service should be 'A visible process'.
Here is a gist of my service's code: https://gist.github.com/cpalosrejano/cc1ab73c4819c3e84234f2d619421b93
¿Should I declare the service as process in Manifest.xml?
what is the best way to keep a service running in background, or avoid the system kill it?
You don't. A foreground service is the best that you can get.
But my app, looses all data altought the notification was in the status bar yet
Save your data to a database, SharedPreferences, files, or a server. A process is not a persistent data store.
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 .
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.
This is similar to another question I asked where I was wondering how other apps like drupe dialer keep their service running forever when it is not in foreground. Because I've used job services, alarm manager, START_STICKY and everything else to try to keep my service alive but it always gets stopped by the OS.
You can run the service as "Foreground" and it will be not candidate to be killed by the system under low memory conditions. The gotcha is that you will need to show that behavior to the user with a notification. This is the way that music players uses to go background and alive when you start another apps.
Foreground Services
The app you mentioned (Drupe Dialer) is a Dialer. It might be listening to broadcasts and turning the service up every time by checking whether its up.
To answer your question, you need to keep the service started as START_STICKY to make it restart after the OS kills it. But AlarmManager does not work at device sleep states, and doze will stop it from running in the background nevertheless.
The real question is; WHY you want to keep it running? That might answer your question on HOW you want to do that.
If its a communication type app, you will need to use something like
GCM.
If its running background work based on some event, you might
want to start the service inside the BroadcastReceiver.
etc.
it depends on what app you're writing.
I've been looking through many questions about services, but I couldn't find one that suited me.
I need a service that both starts on BOOT_COMPLETED (not bound to an Activity) and runs ALL the time (therefore I can't user AlarmReceiver). I know it might drain my battery but so far I don't care. It is just for research purposes.
I have a service that monitors sensor's data. What I managed to do so far was: either start the service as a regular Activity, but it runs only for +-20s and it is stopped (I think the SO cuts it down to release its memory); or start a service that runs in foreground. It worked to keep the process running, however the class that actually runs the service somehow was not started, besides an annoying notification which is required.
The code I refered as the one that runs the service in foreground was taken from here:
Implement startForeground method in Android
I mean, how does an app like WhatsApp run constantly? Is it running in foreground? Because looking at Settings it seems the service is very stable, and it does not show any permanent notification, since it is not possible for a foreground service run without one.
( How to startForeground() without showing notification? )
Any advice?
You can use a WakeLock. But please remember, with great power comes great responsibility (to release them again and not over-use them).
But for now, just acquire a hefty WakeLock and only release it until you are done. This should keep your device's screen and CPU awake and allow you to do whatever it is you want to do.
for my android app I want that users should not be allowed to kill it. The app has a service running that waits continuously for event notifications and currently if the user goes to the task manager he can force close the app and kill the service.
I read about START_STICKY but I am not sure what it does exactly...and when. If the app is automatically killed(low memory ??), does START_STICKY ensure that the service is restarted so the app will function normally again?
If that is indeed the case, can I use START_STICKY to restart the service even if the user force closes it?
or is there any other way to prevent the user from closing the app???
As far I know, START_ STICKY is useful if your are implementing a service that uses a server socket for socket programming. Sometimes Android OS may, under low memory circumstances, kill background services so that memory may be reclaimed. So if you use START_ STICKY then the service will not be considered for reclaiming.