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!
Related
According to the documentation, both should have the same priority:
Android ranks a process at the highest level it can, based upon the importance of the components currently active in the process.
Using a service guarantees that the operation will have at least "service process" priority, regardless of what happens to the activity.
Is this really the case? Isn't memory usage a factor? If the services in both processes consume the same amount of memory while the killed activity consumes alot more (not garbage collected yet or because of leaks), would that make its process more eligible for termination?
Context:
My app consists of a service and an activity. It's important (for the user) that the service remains running even when the activity is not so to decrease the probability that it will be terminated I decided to assign each a separate process. The justification for this so far is possible unhandled exceptions in the activity that can bring down the whole process. I want to know if I should consider termination policies as another reason.
*Foreground service is not an option.
*The service is sticky (I just want to decrease downtime).
P.S., English is not my first language. Feel free to rephrase my question and correct any technical or grammar mistakes.
For your context you can make the service Sticky which will restart it upon destroyed.
Starting service in different process is not the solution, if you need it to run continuously. I am guessing you did it because your service got destroyed when Activity crashed. This happens because process is terminated when activity crashes or is force closed. Also, make sure your service is not bounded to Activitie's lifecycle
Is having a foreground service protective for the entire process? The documentation is a bit unclear, saying the service is highly unlikely to be killed. However, I've learned there's a big different between a service (or an activity) being destroyed versus the process (which contains all the activities and services, unless you are specifically forcing your service to be in a different process) being killed.
Any ideas?
Thanks.
First off, nothing prevents a process from being killed, and unfortunately there is very little you can do about it. Android uses a modified form of Linux's "out of memory" process killer to periodically kill processes. Memory does not even have to be low for a task to be killed - it can simply have been running for too long. If you are root you can fiddle around with various files (under /sys or /proc, it's been a while since I have looked at this) in order to fight Android and try to keep a process from being killed, but unless you touch these files very rapidly (several times a second) Android will still likely to kill your process at an inopportune time.
Having a foreground service won't change any of this, it will merely bump your process to a higher priority so Android is more likely to kill other things first. But depending on what else you are doing it may still have little effect. For instance, I have a logger app which I wrote which takes 12-15MB of (non-shared) memory while running, and when foregrounded it still gets killed on a device with 512MB of RAM if I switch to (memory hungry) Firefox and do much of anything. Note that there are things you can do to recover from this, for instance, telling AlarmManager to send you an intent periodically, which if your service is killed will restart it. This will increase battery usage, however.
Now with regards to the Service itself versus the Activity class, Android can very well garbage collect your Activity after calling onPause without killing the process. In this case, for example, if you have a pointer to your Activity from your Service class you will find that it is suddenly null, so if you are referring to your Activity in this way you should always test for a null pointer before trying to call into a non-static member of your Activity.
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.
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.
I am building an application where I need a service which will never stop like android system services. I can make my service restarted by system using start_not_sticky but there is no guarantee that my service will never stop. So my idea is if there is any way to broadcase receive when my service will be goes off I can restarted the service. Is there any way to receive that?
The documentation explains it best :
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.)
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. An important consequence of this is that if you implement onStartCommand() to schedule work to be done asynchronously or in another thread, then you may want to use START_FLAG_REDELIVERY to have the system re-deliver an Intent for you so that it does not get lost if your service is killed while processing it