When and a how process is reclaimed?
satya - Saturday, May 14, 2011 11:26:24 AM
when is an android process reclaimed?
when is an android process reclaimed?
Search for: when is an android process reclaimed?
Once started by a user, a process with an activity can move between foreground and background. This process may even have long running threads in them initiaed by an activity.
Especially when such a process moves to the background as the user has navigated away from it, what are the life times? what guarantees are there that the background tasks might be completed? for how long? is there a time limit?
will the device goes to sleep terminating such processes? Should the long running task request a wake lock??
satya - Saturday, May 14, 2011 11:39:50 AM
Lets rereard activity documentation
satya - Saturday, May 14, 2011 11:41:16 AM
relevent material restated
If an activity in the foreground of the screen (at the top of the stack), it is active or running.
If an activity has lost focus but is still visible (that is, a new non-full-sized or transparent activity has focus on top of your activity), it is paused. A paused activity is completely alive (it maintains all state and member information and remains attached to the window manager), but can be killed by the system in extreme low memory situations.
If an activity is completely obscured by another activity, it is stopped. It still retains all state and member information, however, it is no longer visible to the user so its window is hidden and it will often be killed by the system when memory is needed elsewhere.
If an activity is paused or stopped, the system can drop the activity from memory by either asking it to finish, or simply killing its process. When it is displayed again to the user, it must be completely restarted and restored to its previous state.
satya - Saturday, May 14, 2011 11:42:34 AM
A paused activity (extreme low memory conditions)...
can be killed in extreme low memory conditions
satya - Saturday, May 14, 2011 11:43:18 AM
a stopped activity is often killed in low memory conditions
The state is still maintained
satya - Saturday, May 14, 2011 11:45:02 AM
An activity is dropped by killing its process
An activity is dropped by killing its process
satya - Saturday, May 14, 2011 11:45:48 AM
My previous notes on activity state management
satya - Saturday, May 14, 2011 11:53:30 AM
Navigating away from an application
either by a back or pressing home is deemed by the SDK as an intention of the user to "close" the app and not expecting to retain its state.
As a consequence the save and restore state methods may not be called with respect to such explicit actions.
It is recommended that on pause one should save any "persisten" data that has been accumulated and not saved so far. One is expected to forego transient state in case of explicit user actions.
satya - Saturday, May 14, 2011 11:55:54 AM
asynctask implications....
when an activity goes to background and hence its process, there are no guarantees that the asynctask will run. as stated it would most likely be removed.
However the hint may be a call to save/restore. If it happens the process is not getting killed (or is it!!) and you want to keep the asynctask running. If these methods are not called but onstop and ondestroy is called the user is not expecting to return to a saved state.
satya - Saturday, May 14, 2011 12:06:38 PM
May be we can discover this from an application: api link
satya - Saturday, May 14, 2011 12:10:04 PM
A process is terminated never telling the application...
As per the docs in production environments the process is killed with out telling the process. You may get onLowMemory() call back