I've chosen to save the persistent application state in the OnPause() method to my database because OnPause() is guaranteed to be called before the application gets killed according to the documentation of the activity life cycle.
Now I am facing following behaviour using eclipse and avd emulator (api level 8):
1. I start my application via eclipse - Instance1
2. I start my application via eclipse again - Instance2
Now Instance1 is being terminated without calling OnPause()!
Could somebody please explain me why OnPause() is not being called? I thought it is guaranteed to be called always. If this is not the case, maybe because of the way eclipse terminates Instance1 process, then I would like to know if I could change this. Thanks a lot.
When you start the application via eclipse, it will effectively rip the rug out from any instance of the same app already running on the device or an emulator. This will never happen in practice, only when running from eclipse.
So you can plan on onPause() always being called.
what you mean you start application via eclipse - instance 1 and 2?
when click on run button, emulator (in your case or a real device) runs your application. please don't run it in other AVD (if i get correctly based on your instance 1 and 2). If you have put log code in your onCreate() and onPause() methods, For example Log.i(TAG, "I'm in onCreate()!");, you should see it in logcat. therefore, when you launch your app you will see onCreate message and when you click on home button for example, you will see onPause() message.
This is the way which is guaranteed to be called.
Related
We have one very difficult to reproduce problem with an app. The use case is as follows:
User opens app
User leaves app in background
User openes 5 to 7 more apps
System kills our app
When user tries to resume app, app crashes due to NullPointerException
I was trying to use console log with Application class method onTrimMemory() and onLowMemory() but this methods are not being called. Is there any method or callback I can be listening to know when android system will kill my app due to many more apps being opened and in that case for me to do something?
You can save whatever states you need in onSaveInstanceState() and restore them in onRestoreInstanceState(). onDestroy() is what the system will most often call to clear room while your Application is in the background, but it is not guaranteed to be called, so it is better to have already saved your states in onSaveInstanceState().
Is there any method or callback I can be listening to know when android system will kill my app due to many more apps being opened and in that case for me to do something?
Not really. Depending on circumstances, onDestroy() of running activities and services will be called.
We have one very difficult to reproduce problem with an app
That should be reproducible in a matter of seconds:
Run your app.
Switch to another app.
Kill your app's process from your IDE (e.g., "Terminate Application" toolbar button in "Android Monitor" tool window).
Try returning to your app from the overview screen (a.k.a., recent-tasks list)
I'm working on an app that targets Api 19, and that is basically a Processing sketch.
The problem I'm facing is that the first time my app is run, right after installing it, it works well until the user sends it to the background. Then, if they click on the app icon again, onCreate() is called but the activity is not destroyed or restarted. Some variables change and that produces strange behaviours.
This happens ONLY the first time the app is used. After force closing it, this behaviour won't happen ever again (as far as I've tested). And this does not happen when launching the app from Eclipse either.
Summarising, this is what happens after the first force close (and what I deem correct):
Activity is running.
Activity is sent to back via home button
onPause()
We click on the app icon again
onResume()
And this is what happens -ONLY- the first time the app is run after installation:
Activity is running.
Activity is sent to back via home button
onPause()
We click on the app icon again
onCreate() <-- !! note no onDestroy()
onResume()
I wonder if the fact that I'm using Immersive Mode has anything to do with this, but changing the Api target version to 10, removing Immersive mode or testing on old devices do not help. I have, of course, used android:configChanges="orientation|keyboardHidden|screenSize" on my manifest.
Does anyone have a clue on what might be causing this? Is this a common issue or should I look for a bug in my code? Maybe a Processing bug?
Thanks in advance for any clue. I hope this is the right way to ask about this issue. This is my first post.
Update:
My explanation is not very accurate, but apparently there is a bug report for this. The problem is much better explained here: https://code.google.com/p/android/issues/detail?id=26658
Unfortunately, I can't get the proposed solutions to work, using this in onCreate() causes my app to either close or crash:
if (!isTaskRoot()) {
finish();
return;
}
Ok, this is how I solved it, in case anyone else bumps into this wall.
This might affect especially people coming from the Processing Developing Environment, as it converts a "Processing sketch" into the only activity of the project.
The original problem (Android managing apps in a different -wrong?- way when launching them from the Package Installer) is well explained here: https://code.google.com/p/android/issues/detail?id=26658
Solutions posted there might solve most cases,but if -like me- your launcher activity is the one that carries out all the work, you will need to create a specific launcher activity that just starts the main one... and commits suicide when the Android bug happens.
Add this bit to the onCreate() method of the launcher activity:
if (!isTaskRoot()) {
finish();
return;
}
I hope this helps.
This looks like a valid application lifecycle, you put your app to background, android is then allowed to destroy your app. onDestroy is not guaranteed to be called, you have to be prepared for that, as you say onPause is called so you can use it. Why it happens only once after install is hard to explain, but in my opinion you should not actually care about it and prepare your app to be killed any time it is in background.
In above diagram may OnDestroy method never called because other application need memory.
onStop() is the last method which is guarantied to be called. After this method Android is allowed to kill your activity at any time. Check out the table in the activity's lifecycle table. There is a "Killable" column describing the time, when activity can be killed.
If you don't use static variables and you initialize everything properly in onCreate(), then you should have no issues with this behavior. Just never expect onDestroy() to be called.
I just want to ask, when does the debugger get disconnected?
I am debugging my app on the device and when I go to the background and wait some time (around 2 to 5 minutes), my app is being disconnected and I want to handle this case because it makes my app crash when I go back to the app.
Thanks!
Hi guys I know its a little late but for everyone else searching here what you have to do:
Go on your device -> settings -> developer options -> select debug app -> turn on 'Wait for debugger'
Now on Android Studio run the app in debug mode, close it and wait for the process to close (causing it to detach from the debugger) and reopen it from the recent drawer. You will get a waiting for debugger message on the device.
Go on Android Studio and press the attach debugger to process button , select the process and done :D
The same thing happened to me. In my case, the debugger was getting disconnected every time the system destroyed the app after being stopped for a while (i.e. in the background). This happens when the system needs more memory/resources for the foreground app or when your app has been stopped for too long, cf. http://developer.android.com/training/basics/activity-lifecycle/recreating.html.
The best way I have found to debug this is to add Log.d() logging (http://developer.android.com/reference/android/util/Log.html#d(java.lang.String, java.lang.String). After I started logging all lifecycle events, I found that in my case the following was happening:
I switch to a different foreground app, causing my app to go in the background in a stopped state
onPause()
onStop()
debugger disconnects (typically after a few minutes, sooner if using a memory intensive foreground app). Note that onDestroy() doesn't get called here but activity does get destroyed.
I re-launch my app, debugger is no longer attached
onCreate() - system tries to re-create activity using savedInstanceState
onStart()
onResume()
Because the system was the one that destroyed the activity, when it re-creates the activity it tries to restore the state of all Views. If you need to save additional information, be sure to override the onSaveInstanceState() method which gets called before the activity is destroyed, and then recover the saved information by accessing the savedInstanceState Bundle in the Activity's onCreate() method.
Hope that helps.
I have a bug I'm trying to analyze that occurs when the Activity's onDestroy() method is called after hitting the back button. I've put breakpoints in the offending code (using Eclipse). The debugger pauses the app at the breakpoint, but the Android system also takes the app off the screen and returns to the phone's homescreen. After the app is paused for about 10 seconds, the app's thread seems to get destroyed by the Android system because the debugger suddenly disconnects.
Any ideas on how to keep the Android system from doing this? I need to keep the app alive so I can step in the debugger, look at variables, etc.
Phone is running Android 2.3.5.
A workaround that I found is to put a startActivity() call into onDestroy() (before super.onDestroy()) that starts a dummy instance of the Activity, just to keep the app alive. The Android system won't garbage collect the app thread because there is still an Activity running within it (the new dummy Activity). This in turn allows you to debug things because the debugger's connection to thread won't be lost.
If the phone pops up a dialog saying the app is not responding (Force Close or Wait), don't click Wait, just leave it alone. It seemed that clicking Wait caused the app thread to be killed and a new thread was created for the dummy Activity.
You can try a breakpoint on super.onDestroy(), but I suspect you'll have the same luck. :(
Android won't let you linger in onDestroy, it will timeout, so try to accomplish your shutdown more quickly. onDestroy() is intended only for freeing resources and isn't always called before termination; data should be persisted in onPause() or onStop().
https://developer.android.com/training/basics/activity-lifecycle/stopping.html
Addendum: Other options include using a background service for some of the work or to manually handle the back button to give yourself more time, but it could negatively impact user experience.
http://www.stanford.edu/class/cs193a/03/
sent from my phone, please cut my thumbs some slack.
I am starting up my app in the emulator and seeing a call to onDestroy() on the starting activity. Android doc seems to suggest that onDestroy() is called only when the app is stopped. Are there other circumstances when it can be called? It causes a problem for my app because I am shutting down an executor in the onDestroy() method (which was created at class loading time). The first attempt to use the executor then throws a RejectedExecutionException. I'm guessing this is because I have shut it down.
Wisdom gratefully received.
onDestroy() only gets called when your app is being shut down. Here are some things you can try:
What happens of you remove the code to shutdown the executor altogether?
What happens if you instead move the code to onStop()?
Are you sure onStop() is not being called on a previous instance of you app already running on your device. (i.e. you install the app, make changes, install it again, the first one must stop.)