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_COMPLETEDbroadcasts 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_COMPLETEDis 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
AlarmManagerto 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.
13 Responses to “Code Pollution: Boot-Time Services” Leave a reply ›
Regarding the last proposed solution that is what I do in NewsRob. NR runs a sync regularly, say once an hour and it saves when the last sync was triggered.
When the phone boots NR checks if a sync is overdue, i.e. last sync is longer ago than an hour, and then will schedule one for in 3 minutes to give the phone time to come up completely and let other apps do its thing. Otherwise it just schedules one for in 30 minutes or whatever.
Ok, I write this because this approach has a downside also. The NewsRob process needs to be started to receive the BOOT_COMPLETED message. Then other processed will be started which likely will lead to the NewsRob process being killed and then 3 minutes later started again.
It would be great if the OS would handle the delayed passing on of BOOT_COMPLETED or even better the AlarmManager would persist its state, then this whole thing would not be necessary.
I regularly do the same thing, since the already posted alarms are cleared when rebooting. It would be really convenient to have Android persistent alarms!
Thank you for your info .I like it very much
Yes that's a real problem.
At boot time, my phone almost always goes into "killed background processes" because of low memory. Before I do anything.
Also, from a user point of view, what is missing is a way to "disable" applications. For now, only option possible is to uninstall apps, so if you need it again you will have to redownload it (and generally will have lost its data/settings).
A lot of apps you just need once in a while stay active even when not used. Ex : even when set to no refresh, no automatic updates, they often still start at boot time (I suppose they check if they have something to do, even if there is nothing).
But even with almost no processing done, starting an app eats memory... then other apps will suffer.... and they all may just be killed and have to restart later....
This problem at boot time is also there with some other events (network changed, incoming call phone, ....). I have seen a lot of apps registering to be called, and keeping being registered even when set to do nothing. (=> then you wonder why your phone takes ages to allow you to answer a call !)
Of course, "good" apps will allow to be totally unregistered from events they know are not useful given how they are configured. But majority of apps don't !! (and user is not aware unless he has specific tools, or check logs).
Well, it is possible to dynamically deactivate a component. My app disables the BOOT_COMPLETE receiver when auto-sync is turned off.
At the end of the day though, it is not such a big deal if the process comes up once and then dies again. It's just annoying when you wait for your phone to boot up.
Yes it is possible, but if only all developpers did it....
I do not agree about the "not such a big deal".
1 app may not be a big deal, but you can easily have 10 apps starting (even to do nothing) at the same time, which can be often (connectivity changed, incoming call, etc....).
Even if they do nothing, memory used by a process started is far from negligible.
I have already seen this in my logs. Not only this slows down a bit, but sometimes this will just trigger background apps to be killed, slowing down even more. (and maybe hurting those process which would have done something useful).
Awesome bro
Great Service provided here. Boot time service is indeed needed for all of us.