here here :-)
One thing that I think it's important to document here is theinformation
that Brian provided in response to your question about how many (or
actually how few) applications fall into this catefory
David Lang
Quote:
For Java/Dalvik apps, the wakelock API is pertty high level -- it
talks to a service via RPC (Binder) that actually interacts with the
kernel. Changing the basic kernel<->userspace interface (within
reason) is not unthinkable. For example, Arve's suspend_blocker patch
provides a device interface rather than the proc interface the older
wakelock patches use. We'd have to make some userspace changes to
support that but they're pretty low level and minor.
In the current model, only a few processes need to specifically
interact with the kernel (the power management service in the
system_server, possibly the media_server and the radio interface
glue). A model where every process needs to have a bunch of
instrumentation is not very desirable from our point of view. We
definitely do need reasonable statistics in order to enable debugging
and to enable reporting to endusers (through the Battery Usage UI)
what's keeping the device awake.
Brian
--
