Why is calling Process.killProcess(Process.myPid()) a bad idea?

Question

I've read some posts stating that using this method is "not good", shouldn't be used, it's not the right way to "close" the application and it's not how Android works...

I understand and accept the fact that the Android OS knows better than me when it's the right time to terminate the process, but I haven't yet heard a good explanation on why it's wrong to use the killProcess() method. After all - it's part of the Android API.

What I do know is that calling this method while other threads are doing potentially important work (operations on files, writing to DB, HTTP requests, running services..) results in the threads being terminated and it's clearly not good. Also, I know I can benefit from the fact that "re-opening" the application will be faster because the system stills "holds" in memory state from the last time the app was used, and killProcess() prevents that.

Besides this reason, assuming I don't have such operations, and I don't care my application whether my app will start from scratch every time it is opened, are there other reasons why I should not use the killProcess() method?

I know about the finish() method to close an Activity, so please don't include that in your answer.

finish() is only for Activity, not for all applications, and I think I know exactly why and when to use it.

And another thing - I'm developing games with the Unity3D framework and exporting the project to Android. When I decompiled the generated apk, I was very surprised to find out that the java source code created from unity - implementing Unity's - Application.quit() method, with Process.killProcess(Process.myPid()).

Application.quit() is supposed to be the right way to close the game according to the Unity3D docs (Is it really? Maybe I'm wrong and missed something), so why did the Unity's framework developers implement this in native Android?

Nucleoprotein

What did you mean by "not good" - in reference to thread operations? – Fully

Answer 1

Who said calling Process.killProcess(Process.myPid()) is a bad idea?

Yes, letting the OS manage its own memory is the best practice for both you and the user using your application (faster to open again, less chances for force closes, etc...).

However, assuming you know for sure that you're not interrupting threads or other background operations and you use this call in onDestroy() - I see no reason why you shouldn't use it. Especially when it's an API call and not a workaround, and Google didn't mention it's better not to use it in the API documentation.

Felonious

"Who said calling Process.killProcess(Process.myPid()) is a bad idea?" -- the core Android development team, notably engineers like Dianne Hackborn and Romain Guy. – Bistort

@Bistort and the reason it's bad is? – Felonious

It prevents the framework and core system process from doing its own cleanup relative to the app's process (e.g., task history). – Bistort

@Bistort From what I understand, killing an app by calling android.os.Process.killProcess is equivalent to the kernel way of reclaiming memory and it is what's being called when you're pressing the "Force stop" button in "Manage apps", isn't it? – Felonious

That's like saying "death by cancer" and "death by being shot 73 times" are equivalent. Yes, the end result is the same. No, the means by which you got there are substantially different. Notably, the other things that you mentioned have many other pieces to them (e.g., Force Stop setting some flags to prevent broadcast receivers from running until an activity is manually started). Now, I am not a firmware expert. I am merely reporting what I know from conversations with engineers and what those engineers have publicly posted. – Bistort

I agree with @liorry this isn't necessarily a bad idea. If your intention is to kill an app, it can serve as a backup to the ActivityManager APIs. It can also be used to restart your own application albeit forcibly. – Dior

@CommonsWare: if I want my own application to "die completely" and free all memory associated with it : unless it can cause problems to other applications or to the system itself - I don't care if it is cancer, shot gun or Arnold Schwarzenegger which doing the work. so please tell me if you know it can cause such problems. if not - I'll have to agree with liorry, Russ and Tom. – Nucleoprotein

One clear reason it's a bad idea, is that if Android does not expect the process to be dead, it may in some circumstances re-create it. If you want something to stay dead, you have to make sure that Android doesn't think it should be alive. The normal Android pattern is to remove the reasons why it needs to be alive, and then let Android decide if it should hang around dormant, or be reaped to recover resources. – Vesicate

Application class does not have an onDestroy() method. So what to do about that? – Fully

@Fully Application class have onTerminate() – Felonious

@LiorIluz You read the documentation? This method is for use in emulated process environments. It will never be called on a production Android device – Fully

Answer 2

<rant>

In a perfect world, with perfect code and libraries, you shouldn't need to call Process.killProcess(Process.myPid()) and the OS will correctly kill your application as appropriate. Also there will be peace in the Middle East, pigs will fly, and the halting problem will be solved.

Because all of these things haven't happened yet there are times when you need to execute such 'forbidden' code.

Most recently for an Android game I made, the free version used an Ad library which would keep the application alive and also leak memory. The paid version didn't have this problem as there were no ad libraries linked. My solution was to add a Quit button on the main menu that executed such code. My hopes were that the majority of people would hit this button when done and I don't have to worry about it eating up memory. The paid version I just executed finish() and was done. (This was before In-app purchases for Google were available, so I had to make a paid and free version, also they may have fixed the issue by now and I could update said game but it really didn't do too well and I doubt any time spent on it would be worth it)

Its kind of like in elementary/middle school they tell you that you can't take the square root of a negative number. Then later in a higher level algebra class they say... well you can take the square root of a negative number but you get weird results but it's consistent and solves the problem.

In other words, don't execute the 'forbidden' code unless you know what you're doing.

</rant>

Dhyana

loved your answer, but It's kind of saying what liorry already said in more philosophic way.. I've lost you a little bit with the "In-app purchases" story, but got your final main point. I've gave you my up-vote, cause you raised an interesting points.. – Nucleoprotein

omg I thought it was a typo, heaps sorry dude, now that is irony. – Aril

I wish I could give 2 upvotes. The same goes for the foreground service. Even though it's been almost 10 years since your reply, Admob still causes memory leaks. – Menopause

Answer 3

Well, Unit3d is most probably using native code, and they are killing the process as an insurance -- they don't want to leak memory. You could argue whether this is a good idea or not, but the fact that they used it does not mean that you should too.

Maybe there are some extreme cases where you would want to use killProcess(), but usually the OS does this for you, according to current load and usage. Not sure what kind of an answer you are looking for -- you are aware that using killProcess() might break things, unless you can justify its usage, don't use it.

Pitchford

as you said, it really not the answer I'm looking for, but it surely worth an up-vote. you raised some interesting points. – Nucleoprotein

I think it's more likely they were unable to clean up their native resources correctly and are using killProcess() as a bandaid fix. – Apiece

~"killProcess() might break things". What kind of things? – Fully

Answer 4

Here are two situations where killProcess will bite you and not work as desired:

1. Sticky Services - they will restart automatically, even though you killed the process

2. Timer - if you scheduled threads to run on a Timer, they will continue to execute after killing the process

Hence, as you can see, there are situations where killProcess is not a prudent solution to clean up your running app.

Fully

It looks like even NOT_STICKY services get restarted - moreover, the Service receives onCreate() callback but not onStartCommand() callback, what breaks the lifecycle completely. I'm not 100% sure about the mechanizm, but I've met this issue in real code. – Anson

Answer 5

it is a bad idea. for one, your activity won't worth with instrumentation, as those frameworks register on all the lifecycle methods and only after clean execution do they report a test success status. if you kill the process from underneath the test application, it will report a failure and it won't be clear this is happening.

Impose

Answer 6

In my opinion, the reason why kill process is not recommend by some Android developer is , it's hard to make sure all the service, activity quit safely and properly if you just simply kill the process. For a APP developer, their APP may sharing data with other APP, some Activities may export to others. If you kill the process, other app might goes wrong. Moreover, in most of cases, you actually do not need "kill" the app, just finish what you are doing and what you don't wanna user see, leave other works to the Android system. They know better than us. OK, if you know clear what you wanna do, don't care about open faster and so on, like you wanna quit a game when users click some button, your game of course will not export to other app, will not sharing data outside your game, it's ok to do this, just carefully make sure no other services or thread need running. In this case, I recommend finish all the activities before you kill the process, just to make sure Activities properly save state, I'll call something like:

    activity.finishAffinity();
    Process.killProcess(Process.myPid());

in Current Activity. This is just my opinion, and it's welcome to correct me.

Professional