Dianne Hackborn wrote: > - When we are in the process of delivering a broadcast we may bring the > application out of the background class, so we do not need to wait a > long time for it to complete. (Broadcasts have up to 10 seconds to > complete; it is very undesirable to let them take longer, as that can > block up other important things driven off of broadcasts). > > - Likewise services are raised out of background when delivering create, > start, and destroy operations. This is done for the same reason, to > avoid timeouts.
Hmmmm...the upshot of this is that pretty much anything using AlarmManager for scheduled operations will, at least briefly, steal CPU time from foreground operations. If the alarm routes to an IntentService, the "heavy lifting" will still be done at low priority. But, those who elect to implement more smarts directly in the BroadcastReceiver will run at foreground priority for that work. I was planning on writing a blog post on AlarmManager (again), and I'll try to bring this up there. Thanks for the info! -- Mark Murphy (a Commons Guy) http://commonsware.com | http://twitter.com/commonsguy Android Training in NYC: 1-2 May 2010: http://guruloft.com -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
