Windows allows desktop apps to remain running whether they’re visible or not, while Apple’s iOS only allows apps to perform a few limited tasks in the background. Android sits somewhere in between — apps running in the foreground are prioritized, but apps have much more freedom to run in the background than they do on iOS.

We’ll take a look at exactly how Android is managing the apps and processes running on your phone or tablet, demystifying what’s going on in the background.

The Process Lifecycle Hierarchy

A process on Android can be in one of five different states at any given time, from most important to least important:

  • 1. Foreground process: The app you’re using is considered the foreground process. Other processes can also be considered foreground processes — for example, if they’re interacting with the process that’s currently in the foreground. There are only a few foreground processes at any given time.
  • 2. Visible process: A visible process isn’t in the foreground, but is still affecting what you see on your screen. For example, the foreground process may be a dialog that allows you to see an app behind it — the app visible in the background would be a visible process.
  • 3. Service process: A service process isn’t tied to any app that’s visible on your screen. However, it’s doing something in the background, such as playing music or downloading data in the background. For example, if you start playing music and switch to another app, the music-playing is in the background is being handled by a service process.
  • 4. Background process: Background processes are not currently visible to the user. They have no impact on the experience of using the phone. At any given time, many background processes are currently running. You can think of these background processes as “paused” apps. They’re kept in memory so you can quickly resume using them when you go back to them, but they aren’t using valuable CPU time or other non-memory resources.
  • 5. Empty process: An empty process doesn’t contain any app data anymore. It may be kept around for caching purposes to speed up app launches later, or the system may kill it as necessary.

For example, let’s say you turn on your phone and open a music app. While you use it, the music app will be a foreground process. When you start playing music and leave the music app, the music will continue playing as a service process.

Let’s look at Angry Birds as another example. Angry Birds would be a foreground process while you were playing it. When you leave Angry Birds and enter the Gmail app to view your email, Angry Birds becomes a background process (because it doesn’t have to do anything in the background), while Gmail becomes the foreground process. When you switch back to Angry Birds, it will become your foreground process and the game will resume quickly. Angry Birds wasn’t using resources in the background — aside from some RAM — but it resumes quickly because it remained cached and ready to resume.

Android Automatically Manages Processes

Android does a good job of automatically managing these processes, which is why you don’t need a task killer on Android.

When Android needs more system resources, it will start killing the least important processes first. Android will start to kill empty and background processes to free up memory if you’re running low. If you need more memory — for example, if you’re playing a particularly demanding game on a device without much RAM, Android will then start to kill service processes, so your streaming music and file downloads may stop.

In most cases, Android does this all without you needing to worry about it. Android intelligently uses your device’s RAM for caching apps and other data, because there’s no point in leaving your RAM empty.

Of course, Android provides apps with so much flexibility that they have room to misbehave. For example, a poorly coded app could start a service process that remains running in the background all the time, using up all your CPU time and dramatically decreasing your battery life.

One interesting thing you’ll notice in antivirus apps like Avast! for Android is that the antivirus app uses a notification icon. if you try to disable the notification icon, Avast! will recommend against it. By having a visible notification icon, Avast! makes itself higher-priority app, preventing Android from considering it a background app and killing it.

Android Apps Can Start in Response to Events

Android apps can also start in response to events. For example, a developer could program their app to automatically run at startup and run a service in the background. Apps can start in response to a variety of other events, such as when you take a picture, when your data connection changes, and so on. This allows apps to perform actions in response to events without running constantly in the background.

Managing Processes

You shouldn’t need to manage processes manually, but there are a few ways to do it if you want. You can use the multitasking menu on Android 4.0 and later to do some basic process management. To access it, tap the dedicated multitasking button on Nexus devices. On other Android devices, you may have to double-tap or long-press the Home button.

Apps displayed in the menu are likely in “background process” state. You can kill them by swiping an app to the left or right, which will remove it from your device’s memory. This shouldn’t be necessary, but can help when you want to quickly kill an app — perhaps it’s misbehaving.

You could also go into the Settings screen, tap Apps, tap an app, and use the Force stop button to kill a misbehaving app.

Android is based on Linux, and every app on Android is assigned to a different Linux user ID — or user account. This isolates apps from each other. If you root your device, apps can escape their user sandboxes and run with root privileges.

Image Credit: JD Hancock on Flickr

Profile Photo for Chris Hoffman Chris Hoffman
Chris Hoffman is Editor-in-Chief of How-To Geek. He's written about technology for over a decade and was a PCWorld columnist for two years. Chris has written for The New York Times and Reader's Digest, been interviewed as a technology expert on TV stations like Miami's NBC 6, and had his work covered by news outlets like the BBC. Since 2011, Chris has written over 2,000 articles that have been read more than one billion times---and that's just here at How-To Geek.
Read Full Bio »