On Sun, Aug 8, 2010 at 10:40 AM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
quoted text
>> 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
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/