On Sun, Aug 8, 2010 at 10:40 AM, Felipe Contreras <felipe.contreras@xxxxxxxxx> wrote: >> This goes back to your first assertion that there are *many* >> applications that need to run in the background. I just don't think >> that's true. There will be a few, and probably more than just the >> restricted set allowed (and programmed) by Apple. But not *many*. > > The argument in favor of suspend blockers is that you could take > applications that are not designed for embedded, and make them run on > an embedded device without draining excessive battery life; those > applications would have to be background services not conflicting with > Android's design. > > I agree there probably would not be that many background apps, and > probably even less ported background apps, but that is actually an > argument against suspend blockers. > > The rest of the apps (UI apps), cannot be ported, but have to be > written specifically for Android, and therefore should have PM in > mind, and not require suspend blockers to have good power usage. I think there's some confusion here. The default operating mode for Android is to aggressively reach the lowest possible power state (typically full suspend). suspend blockers are used by applications to inform the system that they are currently doing work which requires immediate processing, so the system will avoid fully suspending until that work is done. You could think of it as setting your laptop power management settings to be "blank screen after 60 seconds, power down 5 seconds after blanking", except that there's also a mechanism for apps to hold off on that power down if they're doing important work, and a lot more ways to wakeup beyond opening the lid or pushing the power button. Straight-forward UI apps don't actually require much special handling -- it's preferable that they do busy-wait on things, but even when power is not an issue, wasting cpu spinning needlessly is frowned upon, so this isn't a special request. There's nothing stopping somebody from writing an Android app that acts as a bridge to X11 apps (embedding an X server, etc) and making it possible for native X11 apps to coexist with the Android composition model. I'm a little surprised nobody has done so, actually. I figured *somebody* would decide that they like their phone but absolutely need to run xclock or something locally as a first class app. The Android app model does say that if you're not in the foreground (from a UI standpoint) you should save your state, as you may be terminated if the system runs low on resources. The system only does this when it has to -- generally when we bottom out on memory. On devices with sufficient memory, it's quite common for many apps to remain resident for days-weeks -- I've seen as many as 45-50 apps running on my nexus one. I am a little puzzled by the assertion that Android lasks "true multitasking", but that's another discussion entirely. We certainly don't lack for many concurrent processes and threads... Brian _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
