1

I have an application which I make crash at a certain point by deliberately throwing a RuntimeException. The result is that the app crashes, all visible traces of the activity disappear and the user is shown a popup dialog:

App has stopped
[X] Close app

So far so good, all of this is to be expected.

However, I was able to observe on by calling adb shell ps | grep <packageName> before and after the crash that my process actually survives this crash. (The process is only killed once the user hits 'Close app'.)

  • What are the implications of this process staying alive? In what state is this process? What resources does it need, and what information is still kept in memory?

PS. I know of different possibilities to force app termination without the process surviving (e.g. System.exit() or android.os.Process.killProcess()) but this isn't the question - I'm really more interested in why the process is surviving an app crash.

Background of my question is application hardening and root/tamper/debugger detection. In some of those cases, from a security/hardening perspective (i.e. making reverse engineering harder for potential attackers) it can be desirable to kill the app as quickly and cleanly as possible. I am totally aware that Android is not designed to give this kind of control to applications, and that you shouldn't normally try to terminate an app.

Jonathan Hall
  • 75,165
  • 16
  • 143
  • 189
fgysin
  • 11,329
  • 13
  • 61
  • 94

1 Answers1

1

The reason Android keeps process alive for some time after crash is right the opposite to your goal :) it needs to gather some debug information and make it available for the app creator.

You can kill your process directly from code:

android.os.Process.killProcess(android.os.Process.myPid());
Anton Malyshev
  • 8,686
  • 2
  • 27
  • 45