I have an android application that binds itself to a remote service once the application starts. The remote service provides an abstraction to a bluetooth video camera so we can send commands and receive events from it easily. The binding happens from the Application itself as opposed to an Activity. It is important to me that as long as the camera connection to bluetooth is active that my application stay running so I can receive events from the remote service. The main reason is that I need to know if it's recording or not and if so I need to periodically send it GPS coordinates.
Will my application have a better chance of not being killed if I use a service within my own application to manage that? Or is my application safe from being killed since it is still bound to the remote service? Of course, I understand that the android system will kill my app if memory requirements require it to but will it ever kill my app just because it's been sitting for awhile not doing much?
The application's process should only be removed if memory is low, but you will raise the perceived importance of your process if you use a service rather than an empty process or a background activity. You can also use startForeground() to make it less likely that Android will stop your service.
From http://developer.android.com/reference/android/app/Activity.html#ProcessLifecycle:
Process Lifecycle
The Android system attempts to keep application process around for as
long as possible, but eventually will need to remove old processes
when memory runs low. As described in Activity Lifecycle, the decision
about which process to remove is intimately tied to the state of the
user's interaction with it. In general, there are four states a
process can be in based on the activities running in it, listed here
in order of importance. The system will kill less important processes
(the last ones) before it resorts to killing more important processes
(the first ones).
The foreground activity (the activity at the top of the screen that the user is currently interacting with) is considered the most
important. Its process will only be killed as a last resort, if it
uses more memory than is available on the device. Generally at this
point the device has reached a memory paging state, so this is
required in order to keep the user interface responsive.
A visible activity (an activity that is visible to the user but not in the foreground, such as one sitting behind a foreground
dialog) is considered extremely important and will not be killed
unless that is required to keep the foreground activity running.
A background activity (an activity that is not visible to the user and has been paused) is no longer critical, so the system may
safely kill its process to reclaim memory for other foreground or
visible processes. If its process needs to be killed, when the user
navigates back to the activity (making it visible on the screen
again), its onCreate(Bundle) method will be called with the
savedInstanceState it had previously supplied in
onSaveInstanceState(Bundle) so that it can restart itself in the same
state as the user last left it.
An empty process is one hosting no activities or other application components (such as Service or BroadcastReceiver classes).
These are killed very quickly by the system as memory becomes low. For
this reason, any background operation you do outside of an activity
must be executed in the context of an activity BroadcastReceiver or
Service to ensure that the system knows it needs to keep your process
around.
Sometimes an Activity may need to do a long-running operation that
exists independently of the activity lifecycle itself. An example may
be a camera application that allows you to upload a picture to a web
site. The upload may take a long time, and the application should
allow the user to leave the application will it is executing. To
accomplish this, your Activity should start a Service in which the
upload takes place. This allows the system to properly prioritize your
process (considering it to be more important than other non-visible
applications) for the duration of the upload, independent of whether
the original activity is paused, stopped, or finished.
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
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.
With respect to Process lifecycle, Android system tries to maintain an application process for as long as possible, but eventually needs to remove old processes to reclaim memory for new or more important processes. To determine which processes to keep and which to kill, the system places each process into an "importance hierarchy" based on the components running in the process and the state of those components. Processes with the lowest importance are eliminated first, then those with the next lowest importance, and so on, as necessary to recover system resources.
One of the classification is :
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:
1. It hosts an Activity that the user is interacting with.(the Activity's onResume() method has been called).
2. It hosts a Service that's bound to the activity that the user is interacting with.
3. It hosts a Service that's running "in the foreground" —the service has called startForeground().
4. It hosts a Service that's executing one of its lifecycle callbacks (onCreate(), onStart(), or onDestroy()).
5. It hosts a BroadcastReceiver that's executing its onReceive() method.
What can be real life examples of scenarios given above I am asking this because it will help me and others as well in differentiating between this situations.
1)THe app that is currently on top of the stack (the one the user is using)
2)An app with an Activity that has called bindService on any service. The idea is that if it killed that service, it might lose data. An example of this would be a facebook app, which has a background service to fetch data every so often. If the user has it open, it would qualify
3)This is a service that has declared that its feeds data to a UI. An example of this would be a facebook app where the user didn't have an activity with it open
4)This is a service that's just starting or just finishing. This would be pure luck to have happen, but its basically saying it will try to let it start up or finish cleanly before killing it
5)This is any app that's currently responding to an event. An example would be an SMS app that was just notified of an incoming SMS and needs to deal with it. It will be allowed to run until its done, because doing otherwise may lose data.
I have a simple app with native code. That is, an Activity plus native code.
When the activity is entering background, I keep the native code running to do some processing. The problem is when the activity is killed by OS (due to low resource), JNI code seems to have no knowledge of what happened in Java land and still doing its job, hence wasting resource. Why does Android kill just the Activity instead of the whole process? and in this case, how does native code know that the activity was killed? OnDestroy() may not get called.
An Activity in an Android application is described in the documentation as
An activity is a single, focused thing that the user can do.
It is usually something that is visible on screen and has the user's attention. It has associated with it a state-machine that describes the life-cycle of being shown and hidden when another activity become active. The operating system is at liberty to start and stop activities as it choses - and memory permits.
In addition, a key point of the Android architecture is that activities and services are reusable software components and do not necessarily have a one-one relationship to processes. Inside the same process as your activity may be a service in use by another process in the system.
If the JNI portion of your code is still active in the background when an activity has received an onPause(), onStop(), onDestroy() notifications, it can only be because you haven't forwarded these messages to it. The system certainly doesn't know how to clean up native code's resource utilisation - particularly memory allocated with new() or malloc(). Unless you free it, it will only ever be recovered upon process termination.
If your concern is that your activity is not being killed fast enough by the system and as a result holding references to resources in native-land, it's a good sign that the system isn't resource limited.
You might consider implementing the native portion of your application as a Service and have it self-destruct after short periods on dis-iuse.
You could have multiple Activities in one Android Application. As your Activities go into the background, they can be killed to reclaim resources. The application is typically kept around until the phone runs really low on memory, or the user goes and kills your app manually. The process sticks around until the application is killed, roughly speaking.
Because you can continue processing in the background, when your Activity is re-created you can check the status of your global variables and perhaps pick up where you left off.
Keep in mind that Activities are killed quite often, so there's not much point to doing processing in the background but stopping when the Activity is killed. You might as well stop when onStop() is called in this case.
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