I've noticed an issue when I pause my app, say by pressing home, and then bring up the list of recent apps (via the square button) to resume it.
If I resume it shortly after pausing it, it works fine. But if I leave it paused for too long, i.e. a few hours or overnight, then when I touch its window to resume it, it just posts a "failed to start..." toast and removes the app from the list.
I've searched around, but haven't found any info about what would cause this or how to start debugging it.
My theory would be that is has to do with the activity lifecycle. You can find it here:
https://developer.android.com/training/basics/activity-lifecycle/starting.html
When an app is paused, the onPause() function is called, and if the app is paused, and the system needs memory for another app that is running in the foreground, it will stop, or destroy the activity. When you go back into the app, it calls the onCreate() and onStart() functions
I don't know how your app is structured, but my guess is that when the activity is stopped, it is leaving behind some kind of code that needs to reference something that is no longer there, or destroying the referenced thing itself. Then, when onStart() is called, it checks for that thing that is no longer there and crashes.
The best way to fix this is to make sure that each step of the life cycle isn't referencing anything that could possibly be non existent at the time it is called.
When the user leaves a task by pressing the Home button, the current activity is stopped and its task goes into the background. The system retains the state of every activity in the task. If the user later resumes the task by selecting the launcher icon that began the task, the task comes to the foreground and resumes the activity at the top of the stack.
If the user leaves a task for a long time, the system clears the task of all activities except the root activity. When the user returns to the task again, only the root activity is restored. The system behaves this way, because, after an extended amount of time, users likely have abandoned what they were doing before and are returning to the task to begin something new.
You might look up into the Android documentation regarding Tasks and Back Stack and upon some information about Pausing and Resuming an activity. :)
You issue probably related to memory management on android. It looks like android kills you app to release memory so that it can be used by another app. I have an app with very complex layout (The app loads too many images). After some times, when I run the app from recent app list, it always run the app from start. Not from the last state where I left the app. Anywa, nothing to worry about. This is normal behaviour.
As of my concern this is your problem-
you are starting an activity.
then you press home button. and the activity goes to background.
when you start the app after 5 minutes the app starts from the paused activity. but when you start app after 5 hours the app starts from the beginning.
Solution-
This is happening because the activity is being killed in background by the android system.
the application can be killed by calling the ondestroy() method of the activity.
and when the app goes to background it is added to the application stack of the android system. when ever android needs more memory for any operation it takes memory from the last application in the application stack. it kills the last application and takes its memory.
this is the reason your app is being killed after long time. your app is at the last of the stack and android has killed your app to get memory.
you can find more explanation of the process here.
How to solve this problem
this can be solved by bringing your app to front of the stack periodically.
you can run a service from your activity in background so that is stays on top side of stack.
or save the last opened activity in a shared preference and go to this activity when the app starts.
Related
I am working on a project, where while being on a specific Activity we show a local sticky notification. That should also be the case when the app is minimized. What I have to accomplish is to remove the local notification whenever the app is killed (by Android, because of memory lack or by the user, with a swipe from the recent apps list).
Usually onDestroy would be called whenever Android takes the Activity to open some space. That is fine in one of the cases, however swiping an app from the recent app lists doesn't call the onDestroy and the sticky notification stays.
What I did is, I implemented an empty Service which would force the onDestroy when the app is killed (both swipe and system kill) so I can get my notification removed.
However, what I would like to do is to differentiate between the swipes and system kill.
Is this even possible?
In general, if Android wants to kill your application because it has been in the background for too long (or because it wants to reclaim resources), Android will just simply kill the OS process hosting your app. It will not call finish() or onDestroy() on any Activity or Service components. The behaviour of "swipe from recent tasks list" has changed over time and is different in different Android versions. Someone should write a book about that :-(
You can check for when the user swipe-closes the app by adding a service to your app, and implementing the onTaskRemoved method: https://stackoverflow.com/a/26882533/2441655
This is a comment I found in reddit that seems to me really interesting:
Swiping an app away will effectively "kill" most apps. You can test
this out using ADB if you have the SDK installed. Swipe everything out
of your recents list, then launch the browser.
Use ADB to run 'ps' on the device and verify that the com.google.android.browser process is
running. Go to the home screen, it's still running. Launch some other
apps, and the com.google.android.browser process is still there.
Swipe it out of the recents list, however, and the process is gone. You can
create a test app to further verify, and log the onDestroy() call in
your Activity. It's not called when you back or home out of the app,
or when you launch other apps. It does get called when you swipe the
app out of the recents list though. I do agree that the recent apps
list isn't really "multitasking".
The apps in the list aren't necessarily even running, the processes could have been killed by the
memory manager long before you try to re-open it. However, you can't
argue that the only purpose is to jump quickly to other apps when the
swiping makes the actual process go away.
This is another good answer about what happen when you swipe an app out of the recent apps list. But the part that I liked most was:
Actually, removing an entry in recent tasks will kill any background
processes that exist for the process. It won't directly causes
services to stop, however there is an API for them to find out the
task was removed to decide if they want this to mean they should stop.
This is so that removing say the recent task of an e-mail app won't
cause it to stop checking for e-mail.
If you really want to completely stop an app, you can long press on
recent tasks to go to app info, and hit force stop there. For stop is
a complete kill of the app -- all processes are killed, all services
stopped, all notifications removed, all alarms removed, etc. The app
is not allowed to launch again until explicitly requested.
By Swiping from recent task list removes only from recent tasks ..
It was also called onDestroy before android 5.0 .
Might be you are having issue above api level 20 devices.
System kill normally can not be executed in normal android activity lifecycle.
It just finishes the activity on back press event.
when swiping app to left if any Thread still run in your app Interrupted but service not stopped, when you kill handy app Thread and services are stopped.
the behavior is similar to but not exactly the same as closing an app -- in general (for apps that don't define explicit back button handling) it's the same thing as hitting back enough times from within an application that you exit out of it.check out this link discussion it has some good input on the subject
First, let's get one thing clear: Android MAY NOT CALL onDestroy(). Referring to the Activity Page, from Honeycomb onward, onPause() and onStop() are guaranteed to be called before an app is killed.
Be aware that these semantics will change slightly between applications targeting platforms starting with HONEYCOMB vs. those targeting prior platforms. Starting with Honeycomb, an application is not in the killable state until its onStop() has returned. This impacts when onSaveInstanceState(Bundle) may be called (it may be safely called after onPause() and allows and application to safely wait until onStop() to save persistent state.
So after (hopefully) clearing the air on the Android lifecycle, I think you can achieve what you want by putting the notification removing code in onStop() instead. If you end up needing it back because the user actually DOES come back to the specific Actvitiy(IE not killed), you can bring it back in onRestart().
I've done a fair bit of searching for my issue, but can't find any solutions to my exact problem.
I have an app that has 3 activities in succession. The main activity (on launch), the second activity (where most of the meat and guts live), and then a final activity that is more or less a summary page of what happens in the 2nd activity.
I run into this issue semi-sporadically where if I keep the 2nd activity running in the background (turn the screen of my phone off, or just hit home) and then hit the launcher icon to go back to the app, it creates a new instance instead of returning to my 2nd activity that is running in the background. I can't find any rhyme or reason as to why it happens sometimes and not others (usually it doesn't). Most of the time it takes me right back to my 2nd activity and all is good in the world, but on occasion, it fires up another instance.
Is there anyway to check if an instance is running and ALWAYS return to that instance if there is?
When you hit Home or the screen turns off, the app automatically goes through the onStop() phase. Depending upon the available memory, the app might become a candidate to be killed by the Android OS. There really is no way to prevent the OS from killing an app that is no longer in the foreground - this is an Android OS design. This should most likely not happen if you do not have a lot of applications open.
If the first instance of the app is still around and you launch the app, it will automatically retrieve this instance. Android is designed to never create a second instance of the same app while the first one is still running. Hence there is no way to check is an instance is running. You could use logging inside onDestroy() to see when the app terminates. But again, Android does not always call onDestroy() and might just simply terminate the app.
I got a main-activity, then it opened a new-activity. After putting it to background by clicking home button. If I killed the process using adb shell commands, then I reopen my app.
The new-activity is shown by default instead of starting from the first activity.
My question is that activity's life cycle is beyond its application process?
As the sample shows, even activity's application process is killed, the saved activity still is there. Is this correct? And will android system recycle the saved activities later?
If you reopen the app via the activities list, it will attempt to restart via the last open activity. It's a "feature" of Android that can be incredibly annoying (and frequently just wrong)- Android assumes every app can serialize its entire state when exited for later reopening. You either need to do that (via onSaveInstanceState and onRestoreInstanceState) or you need to catch when you're relaunched and explicity launch your main activity.
This shouldn't happen if you're relaunched via the app launcher, as that should always launch your specified activity.
Android remembers the state of recent tasks and activities. Android can kill your application's process at any time (if it is in the background). If your application was killed while in the background, Android remembers what activities were in the task and how they were started (Intents). If the user now returns to the task (either by selecting from the list of recent tasks, or by tapping the application's icon in the list of applications), Android will create a new process for the task and recreate the activity that was on the top of the stack (ie: the activity that was in front when the task was sent to the background). This allows users to open an applicaton, use it, leave it to do something else, and then return to the application where they left off.
In order for this to work properly, you must save and restore any necessary state (using onSaveInstanceState() and onRestoreInstanceState().
If a task goes to the background and is idle (unused) for some period of time (device manufacturers can change this, usually the value is something like 30 or 60 minutes), Android will reset the task. In this case, if the user returns to the task, the previous saved state will be ignored and the user will start from the beginning. However you can prevent this from happening by setting alwaysRetainTaskState="true" on the root (starting) activity.
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 just did a little test: I started my app, went to a certain screen, pressed the home button and killed the process via Advanced Task Killer.
Now, if I go back to my app just a few moments later, I come back to that very screen. I also know that onRestoreInstanceState() is called in this case, as I have played around with this method quite a bit.
However, just out of curiosity, I did all the same, but let my phone lie around for some time (an hour or something). When I restarted my app, it went straight to the main activity.
So my question is: for how long does Android keep the saved state? or what determines if it throws it away or not? I already figured out it had nothing to do with lockscreen on/off.
Kind regards,
jellyfish
The activity is restored because such applications as Advanced Task Killer use "illegal" methods for killing applications. Android kills application is a similar way when it's low on memory and when killed application is launched again its state is restored.
Android keeps an application state for some time. Usually it's about 15-30 minutes but I think it depends on the device. But you can ask Android to keep an activity state "forever" (until the activity is finished) using android:alwaysRetainTaskState="true" attribute.
When you killed an application with Advanced Task Killer for example, the application restart with the main activity the next time. I suppose that the application save the state in file to restore the same activity even if it killed!
Android will dispose of the activity when it needs the resources that the activity is holding (usually memory) and the activity is not in the foreground. There's more criteria involved, but that's the general case. There's no predefined time limit or criteria other than "when it decides it needs to". The app could die almost immediately or it could stay up indefinitely. You should never assume your app will ever be killed and you should never assume your app will never be killed.