It seems that when I don't need interprocess communication, there's almost no reason to use a Service. The only reason I am aware of is this: if my process has a started Service, the process is less likely to be killed.
I could just have a utility class with dontWantToBeKilled() and canBeKilled() methods, which would start / stop a dummy Service. Apart from that, I won't use Services. Is this right?
Yes, there are other reasons.
Your application runs in a process which can be killed by the system whenever it needs more resources.
According to this a running service has a higher priority than an Activity that isn't in the foreground, meaning that the system is more likely to kill an application process that has an Activity in the background than one that has a Service running in the background.
The documentation for Service states that:
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.
So, you can use Services to decrease the likelihood of your application process being killed.
Even though the Service runs in the same process as an Activity nothing guarantees you that your Activity will not be killed.
From Processes and Threads:
For example, an activity that's uploading a picture to a web site
should start a service to perform the upload so that the upload can
continue in the background even if the user leaves the activity. Using
a service guarantees that the operation will have at least "service
process" priority, regardless of what happens to the activity. This is
the same reason that broadcast receivers should employ services rather
than simply put time-consuming operations in a thread.
Conclusion:
If you want to do a background operation that will take a while and it's important it finishes correctly, use a Service.
Its not necessary that if A process started service then,Process is likely to be killed.Actually process remain alive or not it does not affect service.As its completely background procedure.May be the situation that you have started a process to just start a service.So process and service can not interrelated like that.
AFAIK i did not got your final question properly.
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.
do you have any idea what can bee root cause of my Android app service stop working when i run random another app/game?
I do not have code available, i just need causes.
Thank you.
Service runs in your app process. If your app is garbage collected, the service will stop until:
You start the service in new process via manifest file declaration
You make the service sticky (recommended).
go ahead and research above two and let me know if you would like more explanation or code
UPDATE
If you see official documentation of Service, Google clearly explains why and when service will be destroyed. What is useful in your scenario:
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.)
using startForeground will ensure your service keeps running in the same process. some pointers:
A service with attached client will not be destroyed even on low memory scenarios
A service will be killed in low memory scenarios, regardless of the process. Running in a different process is better but does not guarantee it won't be destroyed by system.
Don't use system.exit(0) to end your app. call finish() on activity.
Starting sticky service just ensures that service is restarted when memory is freed.
hope it helps!
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.
I have some confusion with android service
As per the documentation
It will keep on running in the background on main thread . It doesn't run in a different thread.
My doubt is what is the meaning of keep on running in background . Will it execute the onStartCommand() again and again. I am really very confused with this line (Keep on running in background )
if it will not execute onStartCommand again and again then what is the benefit of Keep on running and if it executes onStartCommand again and again then it is using cpu more and more
Line which confused me is highlighted in the image please have a look
As already noted in a comment, for your particular purpose (monitoring a setting, here: volume), you can follow a non-polling approach which is described e.g. here: Is there a broadcast action for volume changes?
In general, on a modern (though not perfect) environment like Android, there's almost never a reason to actively poll something, because nobody could afford wasting so much resources, and also, you'll always risk to miss events, so you'd be tempted to poll more frequently -- this is a race which your implementation is always going to lose.
Once more, the following statements are plain wrong:
A Service runs on your app's main/UI thread. If you think this is the case then you need to read about the android:process attribute of the manifest's activity tag. Also. even if you do not let your service run in a separate process, the phrase a service runs on your app's main/UI thread suggests that your main/UI thread gets blocked by your service. Of course, hopefully nobody leaves iot art that; it's easy to just process the service's events on your app's main/UI thread and delegate the tasks to worker threads, which is what every sane implementation should do.
With START_STICKY, you can ensure that your service will always be running after it got started. Of course, this is naive and means that whoever claims this has not completely understood the meaning of this flag in conjunction with the description of the process lifecylce for Android Services. Quote: 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 you read the section, you will know that Android is going to kill the process with your running service at any time without notice if it needs memory for another task with higher priority and your service is not related to an app which the user currently looks at. In other words, if the system is low on memory and the user opens a spreadsheet which requires most of the system's memory, then the background internet radio media player and all fancy stuff is likely to get killed, period.
A Service runs on the thread of your app and after started it keeps running until it calls finish() or android needs memory.
But the running doesn't necessary means that it is processing something. onStartCommand() is called only when someone calls startService() on your service.
So the service instead of running always it's always in memory ready to be run when needed. The main use of service is to do some processing that keeps running even if you change activities, like a music player that keeps playing when you are changing activity looking for the next music to play.
Edit: On Documentation "A Service is not a separate process....A Service is not a thread. It is not a means itself to do work off of the main thread".
A Service is "A facility for the application to tell the system about something it wants to be doing in the background"
"A service can be both started and have connections bound to it. In such a case, the system will keep the service running as long as either it is started or there are one or more connections to it with the Context.BIND_AUTO_CREATE flag. Once neither of these situations hold, the service's onDestroy() method is called and the service is effectively terminated."
Service Documentation
What are the advantages/disadvantages in placing a lengthy network access code in a thread in an activity or a thread in a service? How would it affect the application? I am writing a streaming audio player and from what I've read so far putting the code in a service will still end up blocking the application so a new thread is needed, does anyone know if it makes more sense to put this piece of code in a service.
Yes, a blocking operation in a Service will still block the application. Despite first appearances, Services are not simply for running tasks in the background. They are for running tasks with a lifecycle that is independent of the Activity lifecycle (IE, they may continue after the Activity is closed).
A Service that starts when an Activity starts and ends when the Activity ends is useless.
In your case, where you are streaming audio, you may want to stream audio even after the user closes the Activity, in which case, you should use a Service, but you'll still need a thread (or an AsyncTask) for blocking tasks.
From my experience (1+ years developing Android), there is no difference between running a new thread in a service or in an activity.
Try not to keep a reference to the Activity in the new thread - use the application context.
Also, the service's life-cycle didn't help at all because some methods are not guaranteed to be invoked :(
The only difference may be that the service can be destroyed without destroying the app completely - thus potentially destroying the new threads.
Why potentially? because on the practical side, this doesn't happen. The app ALWAYS gets killed without killing the service before that, meaning: the local service mechanism is useless!!!
Remote service is a different discussion - I was referring only to "where should I run a new thread?".
Good luck!!!
The difference is how the system manages your application process lifecycle. Running threads don't affect the application process lifecycle, but a service does.
To determine which processes should be killed when low on memory, Android places each process into an importance hierarchy based on the components running in them and the state of those components. If your app doesn't have a visible activity or a foreground service but has a background service, it's categorized as a service process and will be kept alive while there less priority cached processes exist. But if the app has neither a visible activity/fragment, foreground service nor a background service, it's categorized as a cached process and can be killed at any time to free system resources, whether it has a running thread or not.
But do not rush to create a background service, there are more modern approaches to deal with background tasks nowadays. Consider alternative solutions described below and in the background processing guide and keep in mind all restrictions associated with background services.
If a thread executes a task which result is required only by an activity, the thread lifecycle should be bound to the activity. In such a case no services are required. It's so called immediate tasks, ViewModel + Kotlin Coroutines + ViewModelScope is a great way to deal with it, see Guide to background processing for more details about different kinds of background tasks.
If the task should be completed whether the user closed you app or not and it's not required to execute it immediately, consider using WorkManager which is a great way to deal with such deferred tasks. See Android Work Manager vs Services? for more details.
Otherwise, if you have an immediate task which lifecycle isn't bound to an activity/fragment, may be a foreground service would be the best choice, especially in case of an audio player. There are some limitations considering background services since Android 8, the system stops an app's background services in several minutes after the app is closed, so it's not a place for a long running task.