What happens to a running program when “home” button is pressed in Android phone?

Question

One thing puzzles me. It looks like if I use some program on Android and press the "home" button I see the home screen and can rerun the program and see that program in the same state as it was before - so looks like the program is not fully restarted, just suspended and then resumed.

Yet that doesn't seem to happen consistently with Air Control game. Sometimes when I'm playing Air Control and press "home" and later rerun Air Control - it is paused (as if I pressed "pause" button) and I can resume the game. Sometimes the same leads to Air Control dropping the game and starting anew.

So it looks like I don't understand something.

What's the deal here? What happens to a program when "home" is pressed? Does it continue running or what does it do?

Answer 1

Pressing the Home switches you from the app to the home screen, whilst leaving your app running in the background. This is a bit like switching between windows on a Windows PC.

Except that when your phone is running low on resources like memory it will start to close apps that are running in the background, so that your phone has enough resources for what you're trying to do now. Games are often amongst the first apps the phone will "kill" to save resources as they often use a lot more memory and CPU than other apps. This is why sometimes your game is still running paused, and sometimes Android has closed it for you.

The Back button is the way to close apps so that they are actually closed.

See also What is the right way to close apps in Android?

Answer 2

The Android Development document Tasks and Back Stack actually covers this pretty nicely. A relevant excerpt:

A task is a cohesive unit that can move to the "background" when users begin a new task or go to the Home screen, via the HOME key. While in the background, all the activities in the task are stopped, but the back stack for the task remains intact—the task has simply lost focus while another task takes place, as shown in figure 2. A task can then return to the "foreground" so users can pick up where they left off. Suppose, for example, that the current task (Task A) has three activities in its stack—two under the current activity. The user presses the HOME key, then starts a new application from the application launcher. When the Home screen appears, Task A goes into the background. When the new application starts, the system starts a task for that application (Task B) with its own stack of activities. After interacting with that application, the user returns Home again and selects the application that originally started Task A. Now, Task A comes to the foreground—all three activities in its stack are intact and the activity at the top of the stack resumes. At this point, the user can also switch back to Task B by going Home and selecting the application icon that started that task (or by touching and holding the HOME key to reveal recent tasks and selecting one). This is an example of multitasking on Android.

Note: Multiple tasks can be held in the background at once. However, if the user is running many background tasks at the same time, the system might begin destroying background activities in order to recover memory, causing the activity states to be lost. See the following section about Activity state.

Summary: The task is moved to the background when you press Home and sits in memory, not really doing anything and retaining its state. This means that (generally speaking) you can switch back to the task and it will pick up where it left off. However, the Android system can - and will - kill background tasks if it needs to reclaim memory. When and if this happens is entirely up to the system, and is probably why you see inconsistent behavior when resuming.

If the task is destroyed by the system, it will have to be re-created when you launch it again. So unless the application author has taken measures to save the application's state during the destroy process, it will be lost (and saving exact state in things like games is fairly impractical).

Another good (but also verbose) document is the one covering the Activity Lifecycle (there's a nice flowchart if you scroll down a bit).

Answer 3

Pressing the Home key allows the user to start a new Task, by showing the launcher. All active Tasks (and therefore Activities incl. your "Air Control" example) will call their onPause() method.

It is up to the App (and their Activity) to restore the exact previous state when it comes back visible. It is also possible that the Apps Process gets killed while the Activity is backgrounded, but this should not affect the users experience. The user should not be able to tell a difference if an Activity was just paused or if it also was killed. This could explain the different behavior of Air Control which could be a hint of an faulty implementation of the Android lifecycle management.

Answer 4

My reputation is still too low on this site to vote up, so I'm answering to emphaisze Flow's answer. I keep running into this issue in one of my app's. I have various spinner controls and you have to explicitly save their state in onPause() and then restore the states in onResume() -- Android doesn't remember their states automatically.

Another complication is that sometimes Android will call an app's onCreate() function when you only expect it to call onResume().

So your issue with Air Control (or any other app) is specific to that app and you should report the behavior to the developer for correction. Most app's have a contact email in the Market.

BTW, if you want to understand app life-cycle, I recommend Chapter 2 of Ed Burnette's Hello, Android, especially figure 2.3.