Killing processes in android

Android process death — and the (big) implications for your app

With more developers using Dependency Injection (e.g. Dagger) in Android and adopting patterns such MVP or MVVM, this topic is more needed than ever. There is a recent spike in use of what I would call “hidden Singletons”, the same anti-pattern just bundled differently.

Your Android application (process) can be killed at any time if it’s in paused or stopped state . The state of your Activities, Fragments and Views will be saved. When your return back to the application — the system will start the process again, recreate the top activity (the Activities in the back-stack will be recreated on demand when you go back) and you will get a Bundle with the stored state.

And here lies the issue some developers don’t fully realise — the whole process was killed. So any Singletons (or any “application scope” objects), any temporary data, any data stored in your “retained Fragments” — everything will be in a state as if you just launched the application. With one big difference — the state is restored, the user is at the point where he left the app.

Imagine, in your Activity you are depending on some shared Object, or some injected dependency where you keep recent data. Most likely the application will just crash on a NullPointerException because you didn’t expect the data to be in null.

How to test the application background kill & restore?

1. Launch your application, open some new Activity, do some work.
2. Hit the Home button (application will be in the background, in stopped state).
3. Kill the Application — easiest way is to just click the red “stop” button in Android Studio.
4. Return back to your application (launch from Recent apps).
5. Crash? You are doing something wrong in your application :-).

By opening the app — the system will restore its’ state and the user will not even notice that actually the process was killed in the mean time. Well unless your application crashes because you were not prepared for it.

For this scenario it’s definitely not enough to just test your app with the “Don’t Keep Activities” options in the Debug Settings. This will just test if your activities can restore their state, but the process is never killed this way. The crashes will start coming in when you release your application, the users will open it and the leave it in background for a day and return back.

You can also set Background Process Limit to “No background processes” in Developer options. Put the application into background, launch any other application and then return back — application process will be restarted (the same as if killed due to lack of memory or battery saving).

Troublemakers in your app

• Singletons
• Any other shared instances that keep mutable data (such as injected dependencies where you keep some state)
• Data and State stored in your Application class
• Mutable static fields
• Retained fragments (state is restored, data is lost)
• Basically anything which is not stored in onSaveInstanceState and you depend on it

There is no single solution and it depends on the type of your application. Generally you should try to stay away from anything mentioned in the list, but that’s not always easy or possible.

You should be able to “reinitialise” the state — either load data from a database, SharedPreferences or reload anything needed again.

You may also have a login screen and timeout in your application — in that case it’s an acceptable approach to just detect the process kill scenario and forward the user back to the login screen.

Know the Android platform rules

Any architecture, framework or library has to play according to the Android platform rules. So anytime you see a new library or approach — think about if and how is it handling state restoration.

And as always — test your application for these cases. This particular issue is bad in the way that you will almost never see it during development and simple testing. But the end users will run into it regularly.

Follow me and read about possible solutions to this problem in the next article.

Источник

Android destroying activities, killing processes

Hi I’m wondering how Android is managing memory and I can’t find precise answer anywhere. Let’s assume I have an application with 5 activities on current activity stack (4 are stopped and 1 is resumed), there is no service connected. I press HOME button so that all of my activities are stopped. I start some other memory consuming application and overall device memory is starting to be low. And the question is

. What will happen to my application?

1. Can system destroy only one or some of my activities to recover memory?
2. Will system kill the whole process of my application? Will all activities be nicely destroyed?
3. What will happen when I get back to my application when it was totally killed? Will it start from beggining (like the first start) or will it try to recover activities to previeous state / if yes — is it only the one on the top of the stack or all of them?

UPDATE:

Before asking this question I’ve seen Activity lifecycle a few times but it doesn’t have answers to my questions. I made some tests and I have some answers. «Stop process» in DDMS was a clue for testing.

I haven’t tested answer for question 1, but as guide says:

If an activity is paused or stopped, the system can drop the activity from memory by either asking it to finish, or simply killing its process.

It seems that one or more of the activities can be destroyed gently(with onDestroy method) without killing the process. You will simply get (onCreate + bundle) when getting back to them.

Question 2 answer:

YES. Generally system kills the whole process this means all data including activities and static fields are destroyed. This is NOT done nicely — you won’t get onDestroy or finialize() for any of your paused/stopped activities. This is why saveInstanceState() is called just before onPause method. onPause is basically the last method where you should save something because after this method you could never see onStop or onDestroy. System can just kill the process destroying all of your objects whatever they hold and whatever they are doing.

Question 3 answer:

What will happen when you get back to a killed application?

• Prior to Android 2.2 — application will start from the beggining, with launcher activity.
• Starting from 2.2 — system will restore the previous application state. What does it mean? It means that last visible activity will be recreated (onCreate + bundle). What will happen with activity stack? Stack is fine but all activities on it are dead. Each of them will be recreated (onCreate + bundle) when you get back to it with back button. There is one more thing 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.

Conclusion?

1. Don’t think that handling activity rotation problems can be solved by android:configChanges=»orientation». When you do that you will get many other problems that you are not even aware of.
2. Test your application with DDMS — Stop process button. See This
3. Be careful when using static variables. Don’t think that when you initialized them in activity 1 — you will have them initialized in activity 2. The only safe place to initialize global statics would be Application class.
4. Remember that you may never see onStop or onDestroy. Close files/databases, stop downloaders in onPause. When you want app to do something in BG — use foreground Service.

That would be it . Hope I helped with my essey 🙂

2 Answers 2

First please have a look at this:

onPause() Called when the system is about to start resuming a previous activity. This is typically used to commit unsaved changes to persistent data, stop animations and other things that may be consuming CPU, etc. Implementations of this method must be very quick because the next activity will not be resumed until this method returns. Followed by either onResume() if the activity returns back to the front, or onStop() if it becomes invisible to the user.

onStop() Called when the activity is no longer visible to the user, because another activity has been resumed and is covering this one. This may happen either because a new activity is being started, an existing one is being brought in front of this one, or this one is being destroyed. Followed by either onRestart() if this activity is coming back to interact with the user, or onDestroy() if this activity is going away.

So, when you press «HOME» button on your device, your current foreground activity is put onto onPause() then onStop() , the other 4 should remain onStop()

According to Google’s Documents:

• If an activity in the foreground of the screen (at the top of the stack), it is active or running.
• If an activity has lost focus but is still visible (that is, a new non-full-sized or transparent activity has focus on top of your activity), it is paused. A paused activity is completely alive (it maintains all state and member information and remains attached to the window manager), but can be killed by the system in extreme low memory situations.
• If an activity is completely obscured by another activity, it is stopped. It still retains all state and member information, however, it is no longer visible to the user so its window is hidden and it will often be killed by the system when memory is needed elsewhere.
• If an activity is paused or stopped, the system can drop the activity from memory by either asking it to finish, or simply killing its process. When it is displayed again to the user, it must be completely restarted and restored to its previous state.

And, for the process lifecycle:

Process Lifecycle 3. A background activity (an activity that is not visible to the user and has been paused) is no longer critical, so the system may safely kill its process to reclaim memory for other foreground or visible processes. If its process needs to be killed, when the user navigates back to the activity (making it visible on the screen again), its onCreate(Bundle) method will be called with the savedInstanceState it had previously supplied in onSaveInstanceState(Bundle) so that it can restart itself in the same state as the user last left it.

It is confirmed that the system can destroy non-acitve activities and recycle memories when you launched some memory consuming applications. And you can implement like: isFinishing() in your activity and then using «kill» button in DDMS to detect which of your activities is being dropped by system. But I guess the system will destroy the oldest one first. However it is no point to keep other activities when the «Launch Activity» has been recycled.

UPDATE

Here’s some opinions I found from here:

When an activity is not visible, but still in memory, we say it’s in a stopped state. Stopped activity could be brought back to the front to become a Running activity again. Or, it could be destroyed and removed from memory.

The system keeps activities around in a stopped state because it is likely that the user will still want to get back to those activities some time soon, and restarting a stopped activity is far cheaper than starting an activity from scratch. That is because we already have all the objects loaded in memory and simply have to bring it all up to the foreground.

Stopped activities can be removed from memory at any point.

Источник

Android kill process [duplicate]

How to kill whole application in onne single click.. finish() is not working?? it redirects to tha previous activity. pls guide me.

5 Answers 5

System.exit() does not kill your app if you have more than one activity on the stack

Use android.os.Process.killProcess(android.os.Process.myPid()); this way.

I hope this will help you.

You can use this function to close your application

• Use startActivityForResult to start any activity.
• Write finish() in onActivityResult of the activity in which you are starting another activity if result == RESULT_CANCELLED .
• Finally use finish() at the point of exit.

i think you want this

Added in API level 1 Call this when your activity is done and should be closed. The Activity Result is propagated back to whoever launched you via onActivityResult().

you must use System.exit() to kill your application on a click to directly close the activity.

Why finish() is not working for you ?

Take an example where Activity A had called Activity B and when you call finish() on your activity B if finish the activity but as Activity A had given him called and it is a previous activity it returns back you to Activity A screen

You can call System.exit() — It will directly kill the application wherever it is called from it does not matter.

Start the home activity by killing your current activity by using finish() and then call

Источник

Android process killer

Maybe you can help.

Is it possible to get list of all Processes which are running in the Android system, and kill some of them? I know that there are some applications ( task managers ), but I would like to write my own, simple application.

I would like to write simple task manager, just list of all processes and button which will kill some of them.

Could you just write some Java methods which I can call in order to get list of process, and method for killing them. Or just give me some advice’s.

3 Answers 3

Killing apps/services in Android is generally a really bad idea. Whilst it is possible to write task killer apps, it shouldn’t be encouraged for anything outside of development/debugging purposes.

Task management is the responsibility of the Android O/S, the tasks you can see are not processes (in the sense of the processes you see in the Windows task manager for example), in fact, they only have a process when Android tells them they can have one.

Apps are regularly broken by these task management tools, as they often fail to recover from the forced termination, particularly if they were busy writing to a file or using another resource when they were killed. It also puts the handset users into a false expectation that the apps listed are actually RUNNING on their phone, which they are often not. This is explained in the [ActivityManager docs][1]:

Information you can retrieve about a particular task that is currently «running» in the system. Note that a running task does not mean the given task actual has a process it is actively running in; it simply means that the user has gone to it and never closed it, but currently the system may have killed its process and is only holding on to its last state in order to restart it when the user returns.

When you see the list of running apps in apps like TaskKiller or Quick System Info, many of them are not actually running, they are just in a suspended state. These apps are not consuming system resources because Android has decided to stop them until they are needed again. However, when you kill them, you don’t give them time to shut down cleanly, and when you try to launch them next time you can be presented with an unfriendly force close dialog. I have seen apps break completely, with even a re-install being ineffective, because they are trying to read a corrupted file on the SD card, or they use unofficial API calls.

In short, friends don’t let friends use task killers in Android.

Anyway, to answer your question, the ActivityManager is what most of these apps use to list activities that are in running/suspended state.

freetaskmanager is an example of one of these task managers in use.

Источник