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.
Related
I am developing a simple app that just play a white noise sound in background while I am doing other things.
It works very well when I switch to other apps ( like games, chrome browser, etc ) but sometimes ( for example when there are many chrome tab opened ) the white noise sound stop and I need to reload my app.
I am NOT using Services, is this the reason ?
Because your apps is getting killed by the system to give up resources for to other apps (games, chrome, etc). So you need to use a Service.
Here an excerpt from Processes and Application Life Cycle
for more details explanation:
An unusual and fundamental feature of Android is that an application
process's lifetime is not directly controlled by the application
itself. Instead, it is determined by the system through a combination
of the parts of the application that the system knows are running, how
important these things are to the user, and how much overall memory is
available in the system.
...
A cached process is one that is not currently needed, so the system is free to kill it as desired when memory is needed elsewhere. In a
normally behaving system, these are the only processes involved in
memory management: a well running system will have multiple cached
processes always available (for more efficient switching between
applications) and regularly kill the oldest ones as needed. Only in
very critical (and undesirable) situations will the system get to a
point where all cached processes are killed and it must start killing
service processes. These processes often hold one or more Activity
instances that are not currently visible to the user (the onStop()
method has been called and returned). Provided they implement their
Activity life-cycle correctly (see Activity for more details), when
the system kills such processes it will not impact the user's
experience when returning to that app: it can restore the previously
saved state when the associated activity is recreated in a new
process.
I think Services is What You are looking For.
A Service is an application component that can perform long-running
operations in the background, and it does not provide a user
interface.
For better chance of preventing OS to kill your app, you should use a
Foreground Service
following the official guide here: https://developer.android.com/guide/components/services.html#Foreground
Remember that there is no way to be certain that OS will never kill your app, because when RAM becomes really low it could kill every process indipendently from type, following his priority rules
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
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
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.
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