On Thu, Aug 05, 2010 at 06:37:15AM -0700, Brian Swetland wrote: > On Thu, Aug 5, 2010 at 6:18 AM, <david@xxxxxxx> wrote: > > On Wed, 4 Aug 2010, Paul E. McKenney wrote: > > > >> Continuing to rush in where angels fear to tread... > > > > here here :-) > > > >> o "PM-driving application" are applications that are permitted > >> to acquire suspend blockers on Android. Verion 8 of the > >> suspend-blocker patch seems to use group permissions to determine > >> which applications are classified as power aware. More generally, > >> PM-driving applications seem to be those that have permission > >> to exert some control over the system's sleep state. > >> > >> Note that an application might be power-oblivious on one Android > >> device and PM-driving on another, depending on whether the user > >> allows that application to acquire suspend blockers. The > >> classification might even change over time. For example, a > >> user might give an application PM-driving status initially, > >> but change his or her mind after some experience with that > >> application. > > > > 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 > > I think I need to clarify here. When I say "app" in the context of > Android, I mean "an application running under the Android app model -- > sandboxed under a per-app or app-group uid", not "a process". The > vast majority of processes on an Android device are "apps" in this > sense, but some (usually low level services or daemons) are not. Also > I use "wakelock" as a place holder for "suspend blocker" or whatever > exact API we're trying to hash out here, because it's shorter and I'm > lazy. > > Any app may obtain a wakelock through the standard Android APIs, > provided it has permission to do so. In the current implementation, > apps obtain wakelocks via making a binder RPC call to the power > manager service which tracks high level wakelocks (for apps!) and > backs them by a single kernel wakelock. Access control is at the RPC > level. This implementation could be changed to have the app API > simply open /dev/suspendblock or whatnot, with access control enforced > by unix permissions (the framework would arrange for apps with the > android "can block sleep" permission to be in a unix group that has > access to the device). > > For native services (native daemons that run "underneath" the android > app framework -- for example the media service, the radio interface, > etc), the kernel interface is used directly (ok, usually via a very > thin C convenience wrapper). Thank you for the added detail on Android user-space operation!!! Thanx, Paul > Brian > > > > Quote: > > > >> I should have asked this earlier... What exactly are the apps' > >> compatibility constraints? Source-level APIs? Byte-code class-library > >> invocations? C/C++ dynamic linking? C/C++ static linking (in other > >> words, syscall)? > > > > 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 > > > > _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
