27

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?

Improve this question
1
  • I doubt that pressing the home button results in higher power drain.
    – Flow
    Jan 10, 2013 at 12:03

5 Answers 5

Reset to default
12

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?

Improve this answer
27

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

Improve this answer
1
  • So they are killed on a per-task basis, not a per-activity/process basis. The latter would allow partial task killing, which is probably undesirable.
    – jiggunjer
    Sep 9, 2016 at 6:10
4

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.

Improve this answer
3
  • I think by "killed" you mean stopped, as opposed to destroyed. I believe in normal Linux terminology when you kill a process (e.g. Activity) you destroy() the corresponding app components.
    – jiggunjer
    Sep 9, 2016 at 6:18
  • No, I mean destroyed.
    – Flow
    Sep 9, 2016 at 7:11
  • When you press home key the onStop method is called. A killed process doesn't mean the activity gets its onDestroyed method called, though it is indeed similar. "Killing" an Activity process means the VM is removed from RAM. To me this (Android killing it) seems likely to affect user experience.
    – jiggunjer
    Sep 9, 2016 at 7:43
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.

Improve this answer
3

Home Button Pressed when in an app:

Most apps will save their state (any bit of data that would be needed to keep itself consistent when being resumed), and the device will switch to the launcher app.

Home Button Pressed when on the Home screens:

This is configurable by many 3rd party launchers; however a lot of them default to bringing you back to your "main" home screen (the default launcher does this).

What your friend might be concerned about:

Switching apps can be memory intensive and cause several disk writes to save the data. This uses battery; however it is usually not the main cause of battery drain on devices (the operating systems are optimized to do these things).

Some applications will continue to run as a background application, so pressing the home button will not kill them (e.g., Google Play Music will still play after pressing the home button).

Your friend might be concerned that by pressing the home button you did not exit the program, and therefore it is still running. Android will unload those applications as necessary.

You and your friend should be more concerned with the display - which uses the most amount of power.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .