[lkml]   [2010]   [Aug]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Attempted summary of suspend-blockers LKML thread, take two
    On Thu, Aug 5, 2010 at 6:18 AM,  <> 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

    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).


    > 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
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2010-08-05 15:43    [W:0.034 / U:15.860 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site