Code Pollution: Boot-Time Services

In the Code Pollution series, I'll be writing about topics where a coding anti-pattern may work tactically for an individual application, but strategically will be bad for Android as a whole, just as pollution may benefit one firm while harming many others.

Many readers have, at one point in time or another, had a Windows PC that got overloaded with "cruft" and took forever and a day to boot up. Or, even if it would boot normally, it would be slow as a dog for the first minute or two after the desktop showed up.

While it would be fun and entertaining to bash Windows for this, in reality, it was probably third party applications causing a chunk of the problem. Lots of programs think that they just have to do something when the PC starts up, and too many of them bring the boot process to a halt.

The good news is that, for most people, Android is plenty stable enough not to require constant reboots. The bad news is that Android devices may still need to be rebooted from time to time, to process firmware upgrades, to recover from a dead battery, and the like.

One of the things the core Android team feared was too many applications asking to do something at boot time, via the BOOT_COMPLETED broadcast Intent, and causing the boot process to become horribly slow. That is why you need the REQUEST_BOOT_COMPLETED permission to receive BOOT_COMPLETED broadcasts -- the theory being that users who have had problems with slow boots might be less inclined to install other programs that demand boot-time access.

Still, though, it is up to us as developers to try to make the boot process as quick and painless as possible. Here are some ways you can help:

Do not request BOOT_COMPLETED broadcasts unnecessarily. For example, some developers may think it would be cool to steal three or four seconds of processing time at boot to do some sort of initialization, rather than have to deal with that work when their app is started. Tactically, this will improve responsiveness of that one application...at the cost of harming all applications on a reboot.
Do whatever you need to do quickly. If BOOT_COMPLETED is unavoidable, try to get in and out in few dozen milliseconds, not a few seconds.
Consider whether you can wait a bit. Many times, apps do not need to start up right at boot time, but rather sometime after a reboot. Unfortunately, there is no built-in way to ask for a "early, but not right away" broadcast...unless you set one up yourself. Consider whether you could use AlarmManager to do a one-shot alarm to fire your real boot-time code a minute or two after the boot is over. You only lose a minute, and it clears out the rest of the boot processing, and perhaps some initial user actions, before your code needs to join the fray.