How do I test the "App Process Killed" route on Android? - android

In the flow diagram for an Android app activity lifecycle (shown below) there is a route by which the 'App process' is killed and onDestroy() is not called. It seems this is most commonly done to free up memory resources for a different activity.
All that is fine, but how do I test this scenario? Either on device or in the simulator.


If you force stop your app, all BroadcastReceivers and also app widgets, which extend BroadcastReceiver, will stop working. See also this SO post by Commonsware
So force stopping the app is not ideal for testing app behavior under low memory conditions. What else can you do?
One option: write your own task killer app and use ActivityManager.killBackgroundProcesses(). As the documentation says:
This is the same as the kernel killing those processes to reclaim memory
Another option: manipulate the device settings as explained by Xavi Gil in his answer to Simulate low battery & low memory in Android


Steps:
Navigate to your app
Press home button so the app will not get the onDestroy call
Go to system settings and find the right place to "force close" your app
Navigate back to your app
Important note: DO NOT use back button when leaving your app when you are going to system settings, use home button instead so the app does not get killed.


The easiest and most clean solution to test those life cycle is to enable the "Don't Keep Activities" settings in the developer settings on your device.
This way you even get your activity killed as soon as you start a new activity. So if you press back than the old activity will be recreated.

Related

How can I let android system kill my application when it runs in backgroud?

I do a research about Android Activity lifecycle. And I know after an app goes to background, it is likely to be killed by system if apps with higher priority need memory, but save the activity with a bundle. And when users come back, system will restore it, that makes user feel good!
I want to know how to make this circumstance, I want to see my application to be killed before hand, not see it when it is used by users, to evaluate whether it is strong or not. Because it may be crashed when this happens.

Enable "Don't keep activities" in the developer options on your phone. This will force kill your app as soon as you put it in the background.
See this question for more detail about how it works:
Whats the main advantage and disadvantage of "do not keep activities" in android
See here for more info on how to enable it:
http://www.pcadvisor.co.uk/how-to/google-android/3590299/32-useful-things-you-can-do-in-android-developer-options/

You can emulate it by sending your app to background and killing it by adb shell am kill your.package.name.

"Force stop" Option still avaliable after app was destroyed

I noticed that after I quit an app using the back button, when I go to the "Manage apps" menu I still have an option "Force Stop". Shouldn't the app be already dead at this point? (I made sure that OnDestroy indeed runs).
Why would I have an option to force stop an app that's officially dead?
Thanks,
Geva Tal.

I noticed that after I quit an app using the back button, when I go to the "Manage apps" menu I still have an option "Force Stop". Shouldn't the app be already dead at this point?
No.
Why would I have an option to force stop an app that's officially dead?
Because the process is not "dead". Android will keep your process around for a bit, in case the user happens to pop back into your app in the not-too-distant future. Android will terminate your process if and when it needs the RAM to support other apps.
The behavior you are seeing is perfectly normal.

Using the BACK button finishes an Activity, i.e., the current UI part of an 'app'.
A common mistake is to assume that an Activity is the entire 'app' which is not necessarily the case. As CommonsWare points out, it is not necessary for the OS to immediately clean up all of the parts related to the process in which an Activity runs - in fact it can be counter-intuitive if a user briefly leaves an Activity but then re-visits it shortly after.
Android is actually very efficient at managing resources and releasing them (if needed for other 'apps'). What gets retained / maintained after a particular Activity finishes isn't worth worrying about...or at least it shouldn't be if the developer has correctly cleaned up things in their code.
Part of the culture of 'App Killer' apps is related to people assuming that apps don't clean up properly when an Activity finishes. If written correctly, they do and Android will do the rest if/when necessary.

Is it fine if I see my application from Settings App in the emulator has Force Close option enabled even tough I have come out of my application?

I have written a simple database program in android. It runs fine, there is no force close error. But I checked from my application from Settings App I see the Force Close option enabled, which implies that my application is still running in the background, even though I have completely came out from my application to the home screen by pressing back key. And moreover I am not using any services, alarm or broadcast things.
Can some one please guide me what may be the probable reason?. Or is it okay? Or will it crash if I put it on device?

Can some one please guide me what may be the probable reason?. Or is it okay? Or will it crash if I put it on device?
Your application is alive until Android OS needs more memory and destroys it. What I have understood does Android start destroying activities before killing the whole application. This means that your application can be alive even if you have finished your activities.
Do not worry about this; Android OS is handling this extremely well.

How to force all activities in an application to always be destroyed (for testing purposes)?

I am basically looking for the same functionality found in the DevTools (Development.apk) app that comes with the emulator. I am wanting to perform similar testing on an actual device but the DevTools app does not work properly on the device I have so I cannot use it.
I am looking to test in a similar way.
What this does is causes each Activity to be destroyed whenever it leaves the screen, holding onto its instance state just as if the system needed resources and had killed it. (So I can't just call finish)
Is there a way to do this?
Thanks

You can kill your app's process at any time using the DDMS stop button. highlight your application in the list and click the stop sign button. your application will be destroyed like it was killed by the system.
See the stop button in the left pane(Devices) above each device listing:

How to simulate killing activity to conserve memory?

Android doc say:
"When the system, rather than the user, shuts down an activity to conserve memory, ... "
But how to simulate this situation?I want to debug the onRestoreInstanceState(Bundle) method,but don't know how to.

You can't do it in an automated way b/c its completely non deterministic.
See my answer here: https://stackoverflow.com/a/15048112/909956 for details.
But good news is that all you need to do is just simulate calling onSaveInstanceState and you are indirectly testing this low memory situation.
onSaveInstanceState can be triggered by:
losing focus (by pressing home which in essence is like switching from your app to launcher app), launching another activity, pressing recents
changing orientation. this is the easier way if you are using an emulator
changing developer setting: goto developer options --> Apps --> Don't keep activities. This is best option if you are testing temporarily on an actual device.

I've used the "Don't keep activities" developer option to reproduce a crash that happened when an activity was killed due to memory pressure. You can find it in the Apps section of Settings->Developer Options.
It destroys every activity as soon as you leave it. E.g. if you press home to put your app in the background the current activity is destroyed. See https://stackoverflow.com/a/22402360/2833126 for more information.

There's two way to simulate the android killing process: using the setting "Don't keep activities" in developer settings or killing the app process by yourself.
To kill the process, open the activity you want to test, then press home button to send your app to background, and then, using the DDMS in Android Studio (Android Device Monitor), select the process and then stop the process (as seen in the image below). Your app was killed. Now, open your app again (accessing the list of open apps). Now you can test the killed state.

For the purposes of debugging onRestoreInstanceState(), just change the screen orientation ([Ctrl]-[F11] in the emulator). Your activity will be destroyed and recreated, and the onSaveInstanceState()/onRestoreInstanceState() pair will be invoked.

Use the SetAlwaysFinish app (works on a real device and in the emulator) or use the Google DevTools app (works in the emulator only).
These apps use the hidden AlwaysFinish setting of the ActivityManagerNative class to change the behavior of the OS and cause it to immediate unload every activity as soon as it's no longer in the foreground. This will reliably trigger the onSaveInstanceState and onRestoreInstanceState events.
See link below for more details:
http://bricolsoftconsulting.com/how-to-test-onsaveinstancestate-and-onrestoreinstancestate-on-a-real-device/

To debug onRestoreInstanceState you could do the following:
make sure you can debug application right after its start (calling android.os.Debug.waitForDebugger() from your constructor helps, it hangs your application until debugger is connected),
put you application in some state,
causally kill it from Settings->Apps,
causally switch back to it through Recent Apps button (it will still be in the list),
at this moment your application will be started anew and onRestoreInstanceState will be immediately called on the top activity.

Good answers here.
Now, residing in the distant future, using Instant Run in Android Studio will also trigger a save and restore when activities are restarted with code changes.

There's a decent solution for this in Android 6 and newer. See my answer here: Simulate killing of activity in emulator

Categories

Resources