I want to understand and simulate when does Android call onDestroy() of my activity, without destroying the entire process. I'm not calling finish(), and I want to make Android destroy my activity on it's own.
From the activity-lifecycle documentation:
The system never kills an activity directly to free up memory. Instead, it kills the process in which the activity runs, destroying not only the activity but everything else running in the process, as well.
But the Android Activity documentation says:
This (onDestroy) can happen because [...] the system is temporarily destroying this instance of the activity to save space.
So which one is it? Does Android destroy activities when it's low on memory, or does it only kill entire processes?
I want to simulate a situation where Android kills the activity without killing the entire process.
I can mimic this by using the "Don't keep activities" developer-mode setting, but I want to understand how can this happen in the real-world.
I want to make Android destroy my activity on it's own.
Android does not do that, other than through your actions (e.g., finish()) or user actions (e.g., BACK navigation, configuration changes).
So which one is it?
The former (Android kills processes, not activities). See this answer from the woman who wrote this stuff. FWIW, also see this decade-old blog post of mine.
Related
I'm wondering if Android system is able to kill the activity without the entire application process while the app is minimized. From Android documentation we know that onDestroy is only called when the activity is about to be destroyed and the systems guarantees to call this method whenever it is about to kill the activity, it will not be called only in case the entire application process is killed.
So, imagine such a situation - you send the app to the background(minimize) and after some time the os starts to run low on memory and decides to kill the activity, but since the app is currently suspended and cannot execute code it is not able to call its onDestroy method althought it is guaranteed that it will be called before every activity destruction.
So, this kind of reasoning gives me a thought that while the app is in the background os is only able to kill the entire process but not some specific activities. Is my reasoning correct, or did I miss something?
That's true: while the app is in the background os is only able to kill the entire process but not some specific activities.
Your reasoning is correct.
If the user navigates away from the activity/application (e.g. by pressing the home button) then the activity is said to be in the "Stopped" state. (States being "None-existent", "Stopped", "Paused" and "Resumed"). If android get low in memory and needs to kill some processes it will target those processes whose activities are in the "Stopped" state and it kill the whole process (not the activity). Furthermore, it will not be polite when doing so and therefore, will not call the activity's onDestroy() method.
Edit following comments about the confusion of saved state on process death:
If the activiy's process is killed, the system temporarily saves a set of settings outside the activity and using these settings, it recreates the activity the next time it is launched.
For example, just before moving to the "Stopped" state the system calls onSaveInstanceState(Bundle) on an activity that is not "finished" and saves this Bundle outside the activity. The system also does remember that it killed activity's process while it was not finished. Using these two along with other settings (saved outside the activity), the system recreates the activity.
If, However, the activity is finished (e.g. user presses the back button, swipes away the activity's card from the overview window, Activity.finish() is called explicitly, etc), onSaveInstanceState() is not called and the system doesn't save any settings to recreate the activity next time it's launched. It simply creates a fresh one.
This is good news, why? Becuase if it wasn't the case, the developer would have had to stash key state properties manually outside activities and reinstate them when activities are relaunched (that would've been a nightmare)
Since there's been much confusion on this issue, in large part due to the confusing state of the official docs in the past, here's what the docs say
at present:
The system never kills an activity directly to free up memory.
Instead, it kills the process in which the activity runs, destroying
not only the activity but everything else running in the process, as
well.
This as well as real world observation yields that the answer is no.
https://developer.android.com/guide/components/activities/activity-lifecycle#asem
Android's Activity life cycle again. I looked at the official life cycle diagram and I got puzzled because it suggests that there may be some other reasons why Android OS will destroy Activity besides the case when other app with higher prio needs memory?
In the onDestroy() section I see there are only 2 reasons:
is finishing (after a call to finish())
is being destroyed by Android OS due to configuration change
The diagram however suggests that there are some other reasons why system may want to destroy this Activity, are there?
In general, if Android wants to reclaim resources it will kill off the OS process hosting an app that is in the background.
However, we have seen situations where, instead of killing off the entire OS process, Android will selectively destroy activities to reclaim resources. This seems to be manufacturer-dependent and has probably been implemented by specific manufacturers (for whatever reason). In this case, Android will call onDestroy() on activities that have had onStop() called, even though the Activity has not called finish().
We don't know exactly why this occurs but we have definitely seen it. It is possible that this happens when the user removes the app from the recent tasks list (by swiping) and the app has a running Service in the OS process. In this case, Android may be just destroying all activities but leaving the OS process running so as not to have to restart the Service.
Is there API or commands to force Android system to recycle all background activities no matter there is enough resource or not? And how to check all the activities' status to check that the activity is actually killed?
There is an API called killBackgroundProcesses(), but this API is killed the whole process, I am wondering how to only kill some activities without killing the whole process.
As the android dev guide page says below, I am looking for the first way.
activity lifecycle
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.
Yes, there is a way:
Settings -> Developer options -> Apps -> Don't keep activities
Check that box, and you are good to go.
Cheers.
I don't think so Android gives you the information of Activities are in background (i.e in Paused or Stopped State). Even if Activity Stack as well will give you the access of activity at Top.
Possible Solutions :
1. If at all you want to destroy the service , better to call finish() after startActivity() method.
2. If you want to periodically destroy all the background activities. You should implement your own activity stack. Which does pushToStack() on start of new activity and popFromStack() and then activity.finish();
Hi I'm wondering how Android is managing memory and I can't find precise answer anywhere.
Let's assume I have an application with 5 activities on current activity stack (4 are stopped and 1 is resumed), there is no service connected. I press HOME button so that all of my activities are stopped.
I start some other memory consuming application and overall device memory is starting to be low. And the question is
... What will happen to my application?
Can system destroy only one or some of my activities to recover memory?
Will system kill the whole process of my application? Will all activities be nicely destroyed?
What will happen when I get back to my application when it was totally killed? Will it start from beggining (like the first start) or will it try to recover activities to previeous state / if yes - is it only the one on the top of the stack or all of them?
UPDATE:
Before asking this question I've seen Activity lifecycle a few times but it doesn't have answers to my questions.
I made some tests and I have some answers. "Stop process" in DDMS was a clue for testing.
I haven't tested answer for question 1, but as guide says:
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.
It seems that one or more of the activities can be destroyed gently(with onDestroy method) without killing the process. You will simply get (onCreate + bundle) when getting back to them.
Question 2 answer:
YES. Generally system kills the whole process this means all data including activities and static fields are destroyed. This is NOT done nicely - you won't get onDestroy or finialize() for any of your paused/stopped activities. This is why saveInstanceState() is called just before onPause method. onPause is basically the last method where you should save something because after this method you could never see onStop or onDestroy. System can just kill the process destroying all of your objects whatever they hold and whatever they are doing.
Question 3 answer:
What will happen when you get back to a killed application?
Prior to Android 2.2 - application will start from the beggining, with launcher activity.
Starting from 2.2 - system will restore the previous application state. What does it mean? It means that last visible activity will be recreated (onCreate + bundle). What will happen with activity stack? Stack is fine but all activities on it are dead. Each of them will be recreated (onCreate + bundle) when you get back to it with back button.
There is one more thing about that:
Normally, the system clears a task (removes all activities from the
stack above the root activity) in certain situations when the user
re-selects that task from the home screen. Typically, this is done if
the user hasn't visited the task for a certain amount of time, such as
30 minutes.
Conclusion?
Don't think that handling activity rotation problems can be solved
by android:configChanges="orientation". When you do that you will
get many other problems that you are not even aware of.
Test your application with DDMS - Stop process button. See This
Be careful when using static variables. Don't think that when you initialized them in activity 1 - you will have them initialized in activity 2. The only safe place to initialize global statics would be Application class.
Remember that you may never see onStop or onDestroy. Close files/databases, stop downloaders in onPause. When you want app to do something in BG - use foreground Service.
That would be it ... Hope I helped with my essey :)
First please have a look at this:
onPause() Called when the system is about to start resuming a
previous activity. This is typically used to commit unsaved changes to
persistent data, stop animations and other things that may be
consuming CPU, etc. Implementations of this method must be very quick
because the next activity will not be resumed until this method
returns. Followed by either onResume() if the activity returns back to
the front, or onStop() if it becomes invisible to the user.
onStop() Called when the activity is no longer visible to the user, because another activity has been resumed and is covering this
one. This may happen either because a new activity is being started,
an existing one is being brought in front of this one, or this one is
being destroyed. Followed by either onRestart() if this activity is
coming back to interact with the user, or onDestroy() if this activity
is going away.
So, when you press "HOME" button on your device, your current foreground activity is put onto onPause() then onStop(), the other 4 should remain onStop()
According to Google's Documents:
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.
And, for the process lifecycle:
Process Lifecycle 3. 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.
All the quotes above are come from: Android Developers Reference: Activity
It is confirmed that the system can destroy non-acitve activities and recycle memories when you launched some memory consuming applications. And you can implement like: isFinishing() in your activity and then using "kill" button in DDMS to detect which of your activities is being dropped by system. But I guess the system will destroy the oldest one first. However it is no point to keep other activities when the "Launch Activity" has been recycled.
UPDATE
Here's some opinions I found from here:
Stopped state
When an activity is not visible, but still in memory, we say it’s in a
stopped state. Stopped activity could be brought back to the front to
become a Running activity again. Or, it could be destroyed and removed
from memory.
The system keeps activities around in a stopped state because it is
likely that the user will still want to get back to those activities
some time soon, and restarting a stopped activity is far cheaper than
starting an activity from scratch. That is because we already have all
the objects loaded in memory and simply have to bring it all up to the
foreground.
Stopped activities can be removed from memory at any point.
Can system destroy only one or some of my activities to recover
memory?
Yes. Android kills activities which are running in the background when there is a need for memory. Killing one or all might depend on some conditions. For an instance paused or stopped can make android kill an activity or a process itself. Here under Activity Lifecycle you can get the below points. I recommend you to go through that page completely. It will definitely clear your doubts.
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.
Will system kill the whole process of my application? Will all
activities be nicely destroyed?
Activity pertains to an individual whereas process pertains to group of activities. Look at the third point above again it kills the process as mentioned.
What will happen when I get back to my application when it was totally
killed?
Its similar to restart . Again the third point will give you some answers like When it is displayed again to the user, it must be completely restarted and restored to its previous state
Get some more information about memory related stuffs here.
Edit:
All activities in an application runs in a single process. So when a process is killed all the activities no matter 5 or 10 will be killed i.e., restarted. Restart will cause your application to start from a beginning no saved states.
I am seeking short characteristic of Android Multitasking. I have found, that when you minimize Android application, it is ended and it's process remains on the background. When user wants to reuse his app, this process alive it's application. User will be at the same state, when he left (if there was enough memory while working with it), or it will be loaded from scratch, because there was no free RAM for other work and Android exited this process. Am I right? Everywhere there are articles with 20 pages and more about Android multitaksing. I need to know key points because I am lost in a such long artices.
Thanks
Short Answer: Yes. If your app can live in memory despite being 'closed' then it will stay in RAM and processing will continue when you click on it again. Otherwise it will be restarted and you will get an onResume().
Long Answer: Please just read the Activity Lifecycle:
When Android activity is covered by other windows it will enter into paused state and method onPause will be called. It may also me destroyed by OS and then onDestroy will be called. You have very little control over it and can't expect your application to come back up with the same state. However, when activity is brought up again to foreground in will go through steps of onCreate and onPause. Those methods can be used to restore its state.
Here you can find nice diagrams describing Activity lifecycle. Similar but slightly different lifecycle is applicable to service.
http://developer.android.com/reference/android/app/Activity.html
Android activities are the main visible screens that user see while the application is running. If you close the screen or switch to another application, the current activity is put to hibernate and you can save the state with
Activity.onSaveInstanceState(Bundle bundle)
After your activity gets the control back, you can restore the state with
Activity.onRestoreInstanceState(Bundle bundle)
Note that you need to be careful not to store any context references within the activities and related classes as the activity and thus context has changed between pause and resume. Instead, you should always pass the current activity as the active context to avoid having exceptions from invalid context.