Android Enthusiasts Stack Exchange is a question and answer site for enthusiasts and power users of the Android operating system. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

On Ice Cream Sandwich (ICS) the OS categorizes your app and each category has its own threshold in which the OS uses for determining which app to close first when it runs out of memory.

Has anyone of you been annoyed by, say you opened a timer to run in the background to measure the time elapsed of something, then you opened few more apps and got back to your timer just to see it was reset or closed? I mean, seriously, it is really excruciatingly annoying.

Is there a way to force an app to remain running in the background no matter what even when the OS runs out of memory?

share|improve this question
That is a sign a bad code by the App. A user should never have to bother with this and Android provides means so that an App can save their state and restore it later on (since the early Android versions). You should send an bug report to the App developer. – Flow Jul 9 '12 at 6:54
up vote 4 down vote accepted

Simple answer: No. Android always uses OOM (Out-Of-Memory) prioritizing to free unused memory. You can change the priorities of apps (at least until reboot) with some task managers but even then if the memory runs low, apps in the background start getting killed.

Think about this scenario: you've downloaded a badly coded app which runs on boot, causes a buffer overflow and hogs all your memory. Normally, this app is killed, but if it's set to stay open it effectively bricks your phone until reboot, and after that starts again, and again, etc.

Some timers use services with high priorities to avoid this problem, but if you launch enough high-performance, resource-hogging apps while the timer is in the background, it will eventually get killed.

share|improve this answer
Looks like that's it. I wonder if there's any exception to that rule, you know, system apps like phone, contacts, alarms, etc. I do hope google will provide an option in the future for users to "pin" any apps that the user has manually started. It doesn't have to be done on startup to prevent bricking the phone. Or perhaps they could at least let the system attempt to pin it for a while and if the system gets unresponsive, let the user close it. – supertonsky Jul 10 '12 at 11:58
If this ever happens, the least I'd expect is a new permission category for such apps. This would help people who value their battery life and system stability to avoid those apps. I would. – onik Jul 10 '12 at 12:39
It doesn't need to be that way, IMO. Let the system do its old ways by default and in case the user intends one particular app to run in the background just at that particular moment when the need arises, just provide that option. It doesn't need to have another permission category since it is users' discretion to "pin" an app. I don't want an app to be permanently unstoppable once it runs. I just want an option to do this when there's a need just like what I have described in my question. – supertonsky Jul 10 '12 at 16:46
@onik a buffer overflow has nothing to do with hogging memory. Do you know what a buffer overflow is? – user14344 Oct 22 '14 at 18:47
@dcow Yes, I'm familiar with buffer overflows. Since Android has dynamical memory allocation to it's sandboxes, a buffer overflow can go past the current memory boundaries and cause the sandbox to grow. Of course, due to Java's memory handling this was maybe a niche example, a better one would be an infinite loop in a LinkedList, which is not restricted to Integer.MAX_VALUE by it's structure and can be dynamically grown. – onik Oct 22 '14 at 22:18

The accepted answer turned out incorrect or outdated. The "App Settings" module for the Xposed app allows you to specify on a per app basis to keep apps from being killed or freed:

Responsible care should of course be exercised when playing with apps changing such low level behaviour.

share|improve this answer

No. However, two methods to alleviate the problem come to mind but both of them can only be implemented by the developer: The first one is to display a notification, Android will give apps that do this a higher priority than others. The second one is to save the start time so when the timer gets eventually restarted, it won't be reset.

share|improve this answer
Running Apps without reason with Foreground priority (that's why the notification is needed) is considered bad practice. As is said before: Android provides a nice Api that even allows timers/counters that aren't affected by the OOM killer. There is a nice post by Dianne Hackborn about this topic – Flow Jul 9 '12 at 7:06
I don't doubt that there is such an API, but where in this question has this been mentioned before? – Erik Jul 9 '12 at 7:10
Also, there is obviously a reason to keep the app running if at all possible in this case, unlike the game example you posted. – Erik Jul 9 '12 at 7:13
No there is no reason to keep an App running just because of a timer. Just use onSaveInstanceState and onRestoreInstanceState to safe the App state, including the timer information. No need to run in Foreground. Even if it's a alarm you could use AlarmManager to make sure that it's executed later. The only reason where Foreground should be used is: 1. You have some actual foreground activity going on, like playing music or showing a video. 2. You want to keep a data connection open (e.g. IMAP IDLE (push)). – Flow Jul 9 '12 at 7:43

There is sometimes an option to lock the app. This prevents killing or stopping of that application in the phone.

Lock option is not available in the OS itself, using some 3rd party apps like GO Task Manager, etc, can help.

share|improve this answer
OOM killing is done by the kernel and no app can prevent it or "lock" a process. The app you have linked to is a task killer that kills apps itself. The locking feature you are referring to will only prevent killing by the task killer. – Erik Jul 9 '12 at 15:28
Thanks for correcting me. – jayeshomg Jul 21 '12 at 8:26

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.