Please Ignore the HOME Button
There has been a spate of questions recently from people saying that their apps need to intercept the HOME button. For example, one person wrote:
I have a thread that needs specifically to be cancelled when the home button is pressed.
These people just are not thinking this all the way through.
UPDATED: I have added a new section at the bottom to cover more of this person’s actual scenario.
HOME Is Not Magical
All the HOME button does is cause another activity to take over the foreground.
Moreover, there are lots and lots of ways that another activity will take over the foreground:
- The user responds to a
- The user receives a phone call, from the built-in app or from a third-party VOIP client
- An alarm clock app alerts the user, either the built-in app or a third-party app the user installed
- You explicitly launch another activity via
startActivity(), either one from your own app or an activity from another app
- You implicitly launch another activity, such as via a
- And so on
All of those have the same effect: another activity will take over the foreground. HOME is not special.
HOME Is Not Predictable
Some developers who are not thinking believe that the user pressing HOME means that the user is “leaving my app”.
One could argue that any of the events listed above would indicate that the user is “leaving my app”. Do you somehow think that a user spending an hour on a phone call has not mentally checked out from your app?
Beyond that, anyone who has not accidentallly pressed HOME on their device simply has not used an Android device much. It is really easy to bump HOME, whether due to conscious action (e.g., was trying to get to BACK) or unconscious action (e.g., shifted how they were holding the phone and grazed the front panel).
Hence, pressing HOME is neither necessary nor sufficient to indicate that the user is “leaving my app”.
Dealing With Departure
Now, I can completely understand the desire to minimize resource
consumption when your app is no longer in the foreground.
It would be nice if, say,
Application had an
callback that would be invoked when the process flipped between
the various importance levels.
Alas, this information is not automatically available.
In some cases, you are better off leaving things alone entirely. Interrupting something that will wrap up on its own in a matter of seconds is probably a waste of effort. And some background work should continue even if the application goes to the background, such as a long download.
Also, take into account that, for any of these departure
reasons (pressing HOME, responding to a
the user might return in seconds, minutes, hours, or days. In
the case of “seconds”, ideally you will have done nothing to
impact your application.
One pattern to apply would look like the following:
Keep track of whether your application is in the foreground yourself, either via maintaining some counter in a static data member, or using
unbindService()with a simple counter service, or something.
When the counter hits 0, use
TimerTaskto get control again after some period of time. This period should be long enough that if the user is only gone briefly that they will experience no ill effects, but short enough that the user will not feel that you are over-burdening their device while the user is not in your app. You might consider making this configurable via a
If the user returns before that time elapses, cancel the outstanding
TimerTaskfires, then and only then do you take steps to stop background threads or otherwise minimize device usage.
This pattern does not depend upon intercepting the HOME button.
Home Screens Should Be Home Screens
Another scenario — which, based on followup messages, is what the person quoted above is seeking — is that they want a device to work in “kiosk mode”, where it only runs one app. They think they have to override the HOME button for this.
Kiosk mode devices should have the kiosk app be the home screen, so pressing HOME has no real effect.
However, bear in mind that most, if not all, Android devices offer some sort of safe mode reboot, one that disables third party apps. Somebody could use this to return to the device’s built-in home screen. Hence, the only real way to have a kiosk app will involve custom firmware, so there is only one possible home screen.
Learn second-generation Android app development — with Kotlin and the Android Jetpack — through CommonsWare’s Android app development training!