I can't figure out the onDestroy() behaviour.
My question is: Is there any chance that an activity will be killed without calling it's onDestroy() while not killing the hole app?
I mean, Could it be that I'll get back to my app (to an activity other then the activity that the launcher calls) and be in a situation where one activity was killed without calling it's onDestroy()?
I have a need to know that if I get back from the background to an activity that there is no way some of my activities where killed without it's onDestroy.
Thanks!
No i don't think so , when your application get killed because of lack of Memory your whole app process would be killed so in this situation onDestroy() may not be called and your app will back again on your launcher Activity unless you can save your application state on onPause() state before your app get killed.
yes, Android will kill a least frequently used activity if there is not enough memory is available for the newly started app. Also the back button triggers the onDestroy(). A best bet is to save your app state. Here is an example to a similar question how to save and restore your current instance.
As stated in the API documentation Activity#onDestroy():
Note: do not count on this method being called as a place for saving
data!
http://developer.android.com/reference/android/app/Activity.html#onDestroy%28%29
And don't forget to call super.onDestroy()
Related
I am working on a WebRtc Calling App. When my application is in background when incoming call come the Calling Activity PopsUp for call . And When call hung Up i need to send app to the recent background state.
So i came around a solution moveTaskToBack(), which is working perfectly but the problem is after calling Activity finish it shows the Last Activity for 2 or 3 seconds and then going back to recent app. Also tried in onStop() but the result remain the same .
#Override
protected void onDestroy() {
moveTaskToBack(true);
}
Is there a better Alternative of moveTaskToBack() without any Delay? If anyone need more clarification on question let me know in comments. Thanks in advance.
You shouldn't do it onDestroy, because it's not guaranteed that to be called in Activity Lifecycle.
In the onStop() method, the app should release almost all resources that aren't needed while the user is not using it. For example, if you registered a BroadcastReceiver in onStart() to listen for changes that might affect your UI, you can unregister the broadcast receiver in onStop(), as the user can no longer see the UI. It is also important that you use onStop() to release resources that might leak memory, because it is possible for the system to kill the process hosting your activity without calling the activity's final onDestroy() callback.
Problem might be the time takes to calling onDestroy. You can try to call it where you are finishing activity.
If I, for example, need to keep some very important data which the user can edit within my app, should I need to save them every time user changes such data or is it ok if I would save it within onPause(), onStop() or onDestroy() methods?
Can somehow application end without any of those methods calling? (For instance when battery runs out)
This certainly can't be done in onDestroy().
According to the documentation:
There are situations where the system will simply kill the activity's
hosting process without calling this method (or any others) in it, so
it should not be used to do things that are intended to remain around
after the process goes away.
So yes, the application can end without calling any of the lifecycle methods.
In that scenario when the phone is shutting down, you can use the ACTION_SHUTDOWN Intent.
More info here. For all other cases onPause should do the work. Even in the link provided, there is a statement that onPause will be called if the app is in FG.
Apps will not normally need to handle this, since the foreground
activity will be paused as well.
However, if it is not so expensive operation, I would go with saving data after edit.
As per the documentation of Android activity life cycle, onPause is called when an activity is going into the background, but has not (yet) been killed.
Hence, in most Android documentation, and sample codes you will find onPause is used for saving any persistent state the activity is editing, to present a "edit in place" model to the user and making sure nothing is lost if there are not enough resources.
So in your use case, all you need to do is implement onPause for your Activity and write a code to Save the activity state (EditText content or any other ongoing user interactions). Android system will save the activity state which you can always get back in onCreate of your Activity when android launch your activity next time.
in this case please verify your phone activity via debug interface , some of phones are terminate your application this is force quit.
activity manager clear all recent and kill process in background?
-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?
i'll use code but don't work
mgr.killBackgroundProcesses(p.processName);
When your activity receives a call to the onStop() method, it's no longer visible and should release almost all resources that aren't needed while the user is not using it. Once your activity is stopped, the system might destroy the instance if it needs to recover system memory.
- http://developer.android.com/training/basics/activity-lifecycle/stopping.html
So yes the system can destroy your activity when its not visible.
Depending on how its destroyed, it might save an instance by calling the onSaveInstanceState(), and when it resumes it will call the onRestoreInstanceState(). This article has more information on the questions.
First of all I have to say that Google does not recommended to kill any process.
This migh be helpful for you: Is quitting an application frowned upon? and
Android destroying activities, killing processes
I hope these links will answer all your questions.
If you want to finish your activity use finish();
Here are the examples how you can destroy your app: https://stackoverflow.com/a/26586015/3864698
I just want to ask a small question. How long my application will be stored in background before Android kill it automatically. And, will be onDestroy() event fired when it happens?
Thank you!
As explained in the Activity Lifecycle onDestroy() is called when "The activity is finishing or being destroyed by the system" That means that you either manually call finish() in your code, or the phone's system needs the resources occupied by your app. When this happens(for example when another app needs those resources) the OS will call onDestroy() on your app.
onDestroy() isn't necessarly called especeally when your app is getting killed.
I know I can use isFinishing() in onPause() to know whether an activity is going to be killed by finish().
Then, how can I know an activity is going to be killed by OS temporarily due to low memory?
Thanks.
Per the docs, onDestroy should be called right before the Activity is destroyed, regardless of the reason. If the finish was requested, isFinishing will return true. So if it is false, you can assume that the system needed to finish.
However, as the docs also say
Note: do not count on this method
being called as a place for saving
data!
In general, you cannot guarantee that your Activity will be killed nicely. Things like task killers mess with the lifecycle.
Use onPause or onSaveInstanceState to save things properly.
You cannot.
It's possible your activity could go away without the rest of your app going way, in this case onDestroy would be called. However it's also possible that your whole app is going to get killed at once, this like a kill -9 in unix. Your app cannot run any code at this time, it's killed instantly and without warning.
To handle this properly, you want to design your app to save all vital information to disk in onPause and be ready to retrieve it later in onCreate if needed.