Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

How to simulate Android killing my process

Tags:

android

People also ask

How do you kill a task on Android?

Tap and hold on the application and swipe it to the right. This should kill the process from running and free up some RAM. If you want to close everything, press the "Clear All" button if its available to you.

How do you kill apps on Android emulator?

Go to DDMS and select your App process. Click STOP icon in upper-right-hand side. It will kill the process.

What is process death Android?

But there is something we know: When an app dies, we lose state. Unfortunately mobile devices don't have unlimited battery or unlimited memory. That's why when system needs more memory, it kills processes to make some room. So we should make sure that our apps are not effected by this process death.


The best way to test this for me was doing this:

  • Open ActivityD in your application
  • Press Home button
  • Press Terminate Application in Logcat window in Android Studio (this will kill the app process, make sure you select your device and process in Logcat dropdowns at top)
  • Get back to the application with Home long press or opened apps (depends on the device)
  • Application will start in recreated ActivityD (ActivityA, ActivityB, ActivityC are dead and will be recreated when you get back to them)

On some devices you can also get back to application (ActivityD) with Applications -> Your launcher icon but on other devices it will start the ActivityA instead.

This is what Android docs are saying 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.


This seems to work for me:

adb shell am kill <package_name>

This is different to adb shell kill mentioned by the OP.

Note that the help for the am kill command says:

am kill: Kill all processes associated with <PACKAGE>.  Only kills.
  processes that are safe to kill -- that is, will not impact the user
  experience.

So, it won't kill the process if it is in the foreground. This seems to work as the OP wanted in that if I navigate away from my app, then run adb shell am kill <package_name> it will kill the app (I've confirmed this using ps on the device). Then if I return to the app I'm back in the activity I was in previously - i.e. in the OP's example the process gets recreated and creates ActivityD (rather than ActivityC like most other methods of killing seem to trigger).

Sorry I'm a couple of years late for the OP, but hopefully others will find this useful.


Another method, probably one that is scriptable since it doesn't require DDMS:

One time setup: go to Developer Options, select Background process limit setting, change value from 'Standard Limit' to 'No background processes'.

When you need to restart the process, press the home button. The process will be killed (you can verify in logcat/Android Monitor in studio -- the process will be marked [DEAD]). Then switch back to the app using the task switcher.


This question is old but, there is an answer for this question which does not require adb, Android Studio etc. The only requirement is API 23 or newer.

To simulate app restart by OS, go app settings while your app is running, disable (then you can enable) a permission and return the app from recent apps. When permission is disabled, the OS kills the app but keeps saved instance states. When user returns the app, the app and the last activity (with saved state) are recreated.

'No background processes' method sometimes causes same behavior, but not always. For example, if the app is running a background service, "No background processes" does nothing. But the app can be killed by system including its services. Permission method works even if app has a service.

Example:

Our app has two activities. ActivityA is main activity which is started from launcher. ActivityB is started from ActivityA. I will show only onCreate, onStart, onStop, onDestroy methods. Android calls onSaveInstanceState always before calling onStop, because an activity which is on stop state can be killed by system. [https://developer.android.com/reference/android/app/Activity.html#ActivityLifecycle]

Permission method:

<start app from launcher first time>
Application onCreate
ActivityA onCreate WITHOUT savedInstance
ActivityA onStart
<open ActivityB>
ActivityB onCreate WITHOUT savedInstance
ActivityB onStart
ActivityA onStop (the order is like this, it is stopped after new one is started)
<go settings>
ActivityB onStop
<disable a permission>
//Application is killed, but onDestroy methods are not called.
//Android does not call onDestroy methods if app will be killed.
<return app by recent apps>
Application onCreate (this is the important part. All static variables are reset.)
ActivityB onCreate WITH savedInstance (user does not notice activity is recreated)
//Note that ActivityA is not created yet, do not try to access it.
ActivityB onStart
<return ActivityA by back>
ActivityA onCreate WITH savedInstance (user does not notice activity is recreated)
ActivityA onStart
ActivityB onStop
ActivityB onDestroy
<press back again, return launcher>
ActivityA onStop
ActivityA onDestroy
<open app again>
//does not call Application onCreate, app was not killed
ActivityA onCreate WITHOUT savedInstance
ActivityA onStart

I want to compare other methods which are mentioned on the other answers.

Do not keep activities: This does not kill application.

<start app from launcher first time>
Application onCreate
ActivityA onCreate WITHOUT savedInstance
ActivityA onStart
<open ActivityB>
ActivityB onCreate WITHOUT savedInstance
ActivityB onStart
ActivityA onStop
ActivityA onDestroy (do not keep)
<return launcher by home button>
ActivityB onStop
ActivityB onDestroy (do not keep) 
<retun app from recent apps>
// NO Application onCreate
ActivityB onCreate WITH savedInstance (user does not notice activity recreated)
ActivityB onStart
<return ActivityA by back>
ActivityA onCreate WITH savedInstance (user does not notice activity recreated)
ActivityA onStart
ActivityB onStop
ActivityB onDestroy
<press back again, return launcher>
ActivityA onStop
ActivityA onDestroy
<open app again>
//does not call Application onCreate, app was not killed
ActivityA onCreate WITHOUT savedInstance
ActivityA onStart

Force stop method: Does not store saved instance states

<start app from launcher first time>
Application onCreate
ActivityA onCreate WITHOUT savedInstance
ActivityA onStart
<open ActivityB>
ActivityB onCreate WITHOUT savedInstance
ActivityB onStart
ActivityA onStop
<go settings>
ActivityB onStop
<force stop, return app from recent apps>
Application onCreate
ActivityA onCreate WITHOUT savedInstance 
//This is important part, app is destroyed by user.
//Root activity of the task is started, not the top activity.
//Also there is no savedInstance.