How does the apps like Swiftkey, Locker Master manages to keep process alive even after it has been removed from back stack?
They also don't use sticky notification.
Update:-
I need to keep my process alive. But in my case service is active but process gets killed.
They all have one or more unbound background service.
To kill those services you can go into Settings -> Apps -> Running.
However the services may be restarted at any time by other apps or system by sending a system wide message (intent). In most cases it is restarted by
Time events
Boot complete
Other apps
Other intents
In the Swiftkey case, it will be started by Android OS when it needs to show a keyboard.
EDIT: you can specify that a service runs in a remote process by adding this to the service definition in AndroidManifest
android:process="process_name_here"
However there is no such thing as a service that cannot be killed and can run forever. Android OS may start killing your service if it is running low on resources or the service is running for a long period of time. To overcome this, you can make a forground running service, but it needs to show a notification. It can also be killed by task managers, like you mentioned. You should instead start focusing on how to save it's state so you are able to restart it later.
Related
I'm working on an app that keeps communicating with a device by Bluetooth(ble) when it's in both foreground mode and background mode.
I know I should implement ble jobs in a foreground service in Android, but the app is written in flutter and all codes are in dart.
It seems that for now even though there isn't a foreground service, the app keeps alive in background mode.
But I want it to be alive as long as possible.
So I'm thinking about making an empty foreground service...
Will an empty foreground service make an app has some priority in background mode?
And is it ok to do so?
Thanks.
The system can terminate an application in the background at any point. In practice if there is no need for its resources, it runs several minutes maybe more.
When using a foreground service, at some point only the service will run, so there is no real use of "empty service". Closing the application manually will leave only the service running.
Yes, an "empty" Foreground Service will usually prevent the app process from being killed automatically by the system, unless the device is critically low on memory.
How the code in the service class itself looks like does not matter. The important thing is that when a Foreground Service is running in the app process, the whole process will be prevented from being killed. This means that you can have Dart threads in the same process that won't be killed. Activities belonging to the same process that are in the background can still be "destroyed" though, i.e. the onDestroy callback can be called.
Since BLE connections in Android uses the Binder mechanism which are not tied to any of the standard Components (Service, Broadcast Receiver, Activity, ...) that otherwise control how the app process stays alive, having an "empty" Foreground Service is actually a common way to keep BLE connections alive.
I have been reading about process life-cycles after I noticed that android unexpectedly terminated my app. The app is normally running also in background but now it was terminated. The app listens gps location updates, battery state broadcasts, receives sms broadcasts, runs Bluetooth and tcp server etc. So it has quite a lot of jobs to do and until now it has succeeded pretty well.
What I found out was that android probably closed the process due to low RAM. My app was still in the 'app swap' list but when I selected it I noticed that it was actually restarted which explained the fact that I was not able to connect it earlier using tcp. Do you agree my conclusion or is there any other reason than low RAM that could cause this?
After reading a bit more I understood I should have implemented almost the whole application as a foreground service because those will be killed only after there are no normal activities to kill. However I'm not that comfortable in doing such a bit changes to the application at this point. BUT, then I found this:
http://developer.android.com/guide/components/processes-and-threads.html
There are five levels in the importance hierarchy. The following list presents the different types of processes in order of importance (the first process is most important and is killed last):
Foreground process
A process that is required for what the user is currently doing. A process is considered to be in the foreground if any of the following conditions are true:
-It hosts an Activity that the user is interacting with (the Activity's onResume() method has been called).
-It hosts a Service that's bound to the activity that the user is interacting with.
-It hosts a Service that's running "in the foreground"—the service has called startForeground().
-It hosts a Service that's executing one of its lifecycle callbacks (onCreate(), onStart(), or onDestroy()).
-It hosts a BroadcastReceiver that's executing its onReceive() method.
Please correct if I got the bolded condition wrong. Doesn't it mean that I could just make my app to host a dummy foreground service after which the process running my app and the dummy service would be considered as foreground process which again would mean that it would be very unlike that Android killed my app?? This way I wouldn't have to go through all the functions my app has and to figure out how to get them work as a service.
Thanks!
I am wondering that why there is still a process running even I had already left(pressing back button) the Flickr and the Messenger apps in the picture above?
Recently I wrote an app that contains a service, I've found that if there is still a process running, the service will less likely be killed by the system.
So how does the apps above keep processes running in background?
They uses background service that will stay alive even if you quit the app.. as the documentation said
The Android system will attempt to keep the process hosting a service around as long as the service has been started or has clients bound to it
As long the app is not ended service will stay alive unless there is no memory left.
When running low on memory and needing to kill existing processes, the priority of a process hosting the service will be the higher of the following possibilities:
If the service is currently executing code in its onCreate(), onStartCommand(), or onDestroy() methods, then the hosting process will be a foreground process to ensure this code can execute without being killed.
If the service has been started, then its hosting process is considered to be less important than any processes that are currently visible to the user on-screen, but more important than any process not visible. Because only a few processes are generally visible to the user, this means that the service should not be killed except in extreme low memory conditions.
If there are clients bound to the service, then the service's hosting process is never less important than the most important client. That is, if one of its clients is visible to the user, then the service itself is considered to be visible.
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.)
you can learn more about Service here
The back button doesn't end the app, its like minimizing them in Windows. TO end them they need to be call finish. Androiud's design (which I think is a stupid, insecure idea, but its how it works) is that apps will not exit unless they exit themselves with finish or you run low on memory and the OS kills them.
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.
I would like to simply stop the app, and all its activities and services. Currently, from my main activity (which had started other activities), I call finish(), and the app appears to stop, as it goes to the home screen of my device. However, when I check running apps on the device, this app is still listed. It says "one process, and one service". Is there a way to just kill everything? Or, if I have to do it individually how would I find what is running, and how do I stop it? thanks
Is there some specific reason you want to make sure the process is killed?
Android manages processes intelligently. It keeps your process around, and if the user starts your app again it can use the existing process, rather than start up a new one. And if your device start running low on memory, Android will start killing off these inactive processes to free up resources.
In short, it's a good thing that Android keeps your process around. You shouldn't want to have it killed needlessly.
Although it sounds like you may not be stopping your application's service. If you use bindService to start the service from your activity, the service will automatically be stopped when the Activity is stopped (assuming nothing else has bound to the service). Alternately, if you use startService to start the service, you need to call stopService to stop it.