This may be discussed before, but i didn't find answer. I've problem with my application beeing killed when some other apps needs memory. I looked at Activity Lifecycle and tested my app. All i want to know is: when in one of my processes are called onPause() or onStop() and other apps needs memory, how to avoid from my process being killed.
You can't avoid this. When system needs memory or does cleanup, it can kill application.
However you may somehow control importance of your application, so that it may live longer.
Read here about importance of various application parts related to process killing:
http://developer.android.com/guide/topics/fundamentals/processes-and-threads.html#Lifecycle
To have long-running application, implement Service. However, also Service may be killed, but system schedules to restart killed or crashed services after some time.
This isn't possible, every application is treated equally in android and one of the things you have to consider is that your app might be killed. You can keep services running, that might do what you want if it's something in the background.
Related
I have a Service running in the same process as my Application.
Sometimes the Android OS decides to kill my service (probably due to low memory).
My question is: does my Application get killed along with the Service? or how does it work exactly?
Thanks!
First be sure to read: http://developer.android.com/guide/components/processes-and-threads.html#Lifecycle
The key to this is that on Android a process is just a container for code -- or specifically one or more components (activities, services, receivers, providers). By default all components in a .apk get their own, dedicated process, that they all run in together. This is almost always what you want.
When the user is directly interacting with a component of that process (that is an activity) Android will try very hard to keep that process running, and you won't see it killed except under extraordinary circumstances.
When the user is no longer directly interacting with the process, then it becomes expendable relative to other processes as described in the referenced documentation. That is, empty processes (no interesting components) will be killed before processes holding activities that the user had been using, which will be killed before processes with running services. So having a running service will tend to keep your process around at the expense of other processes.
At the same time, we need to deal well with more and more applications leaving services running, often indefinitely, and often with memory leaks. So has a service runs for an increasingly long time, Android will try less and less hard to keep its process going. Effectively this means moving it down to the background bucket until the out of memory killer takes it out. After that, if the service still wants to run, then a new process will be created for it to be restarted in.
The upshot is that for normal services that are running a long time, it is expected behavior that their process will get killed after a while. This doesn't need to stop the service; a service that wants to continue running will do so, it will just need to be instantiated in a new process.
Of course as long as the user is interacting with an activity in your process, the process won't be killed, since this pulls it to the foreground category regardless of what is going on with any services in it.
Processes are killed by the low memory killer, not Applications. So unless you do extra work to get your Service running in a different process, then your Activities are killed along with your Service.
The low memory killer doesn't try to destroy any objects in your process, although the activity manager may call onDestroy on Activity objects that are no longer needed. But that happens as part of the regular activity lifecycle, not due to low memory conditions.
(By the way, I'm unclear whether you mean "application" in general, or your object that extends Application, or whether you mean your Activities that show the UI.)
An application is something that has a user interface and if you have included a service along with it, then definitely it will be killed since Applications are terminated once the cached application queue becomes full
so create Service separate from application or in other words create an other project for it :)
btw, i'm not an experienced Android developer but thats i think what i learned by watching the Android development life cycle videos by Google
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.
My Problem
I have a Service within which I monitor location changes. Its vital this stays running when in the background so it is a Foreground service.
My problem is whilst its in the background and things are getting destroyed, how do I save this data.
My Question
This brings me onto my potential solution.
I have a subclass of Application which I declare in my manifest file.
Would it be safe to see that any objects stored in this Singleton would be accessible throughout my Service's life and therefore give me a means to save my locations?
Thanks in advance
The short answer to your question is yes, Application basically lives as long as your process does so anything that you store there is as stable as it can be in memory until such time that Android may need to reclaim your app from the background to get more memory for a foreground application. However, not much benefit is added over simply saving your state data inside the Service itself. Android does not have a mechanism by which components out of an application are selectively destroyed to reclaim memory. If it needs additional memory to keep the foreground process happy, it simply kills the entire process of other apps in order of priority (based on recent use and their foreground/background priority state).
By having a running Service in your process, your application has already promoted its priority to be more important than other apps in the system that are in the background, reducing the likelihood that your process gets killed. By making your Service run as foreground, you've only slightly increased this priority level further and it's not the sort of thing Google recommends you do for long periods of time. When the system comes under enough memory pressure that apps start getting killed, eventually your process will suffer the same fate.
If you truly need any of your data to live beyond the life of your process, you need to persist it into any of Android's local storage formats.
I would say no. Even if you have a static class with static variables that you are setting, you have no guarantee that the OS will not arbitrarily kill your process at any time it chooses. Maybe 99% of the time what you are saying may work but it would not be a solid solution in my opinion.
You should, as suggested, store any important data in a database or in the android preferences, which ever is more logical for your application/data.
The Application object is the longest-lived object in the Android lifecycle. So yes, it has a lifespan at least as long as your Service. I'm unsure how it helps you save anything, though. Once Android kills your process -- and it will at some point, foreground service or no -- you'll still have to reload or recreate your data when your Service is next created.
how to prevent our process to be killed by Android System while low memory?
You probably should not do that, and properly implement the lifecycle methods instead. Are you absolutely sure your application needs to do that?
Services has higher priority than Activities.And it will be restarted automatically when android get enough resources.
If your app does not need user interaction continuously,I think that's what you want.
If you need something to run in the background, you need a Service. A Service is less likely to be killed by the OS than a background Activity. Still you should expect that it will be killed, that is the design of Android. You can use the AlarmManager to frequently restart a Service if it has been killed, so that very little time passes without your Service running.
I have a Service running in the same process as my Application.
Sometimes the Android OS decides to kill my service (probably due to low memory).
My question is: does my Application get killed along with the Service? or how does it work exactly?
Thanks!
First be sure to read: http://developer.android.com/guide/components/processes-and-threads.html#Lifecycle
The key to this is that on Android a process is just a container for code -- or specifically one or more components (activities, services, receivers, providers). By default all components in a .apk get their own, dedicated process, that they all run in together. This is almost always what you want.
When the user is directly interacting with a component of that process (that is an activity) Android will try very hard to keep that process running, and you won't see it killed except under extraordinary circumstances.
When the user is no longer directly interacting with the process, then it becomes expendable relative to other processes as described in the referenced documentation. That is, empty processes (no interesting components) will be killed before processes holding activities that the user had been using, which will be killed before processes with running services. So having a running service will tend to keep your process around at the expense of other processes.
At the same time, we need to deal well with more and more applications leaving services running, often indefinitely, and often with memory leaks. So has a service runs for an increasingly long time, Android will try less and less hard to keep its process going. Effectively this means moving it down to the background bucket until the out of memory killer takes it out. After that, if the service still wants to run, then a new process will be created for it to be restarted in.
The upshot is that for normal services that are running a long time, it is expected behavior that their process will get killed after a while. This doesn't need to stop the service; a service that wants to continue running will do so, it will just need to be instantiated in a new process.
Of course as long as the user is interacting with an activity in your process, the process won't be killed, since this pulls it to the foreground category regardless of what is going on with any services in it.
Processes are killed by the low memory killer, not Applications. So unless you do extra work to get your Service running in a different process, then your Activities are killed along with your Service.
The low memory killer doesn't try to destroy any objects in your process, although the activity manager may call onDestroy on Activity objects that are no longer needed. But that happens as part of the regular activity lifecycle, not due to low memory conditions.
(By the way, I'm unclear whether you mean "application" in general, or your object that extends Application, or whether you mean your Activities that show the UI.)
An application is something that has a user interface and if you have included a service along with it, then definitely it will be killed since Applications are terminated once the cached application queue becomes full
so create Service separate from application or in other words create an other project for it :)
btw, i'm not an experienced Android developer but thats i think what i learned by watching the Android development life cycle videos by Google