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 work

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

<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>

Answer 6

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.