Thanks Dianne, that makes sense.

I didn't realize there was essentially one wake lock that the kernel &
applications layer use, so when all apps give up the wake lock, they
will still get awaken when the cpu wakes to handle kernel processes.

This explains why the 1-second timer pops occurred at 1 second
intervals before & after the sleep, and at very erratic intervals
during the sleep.

I saw the same behavior on a similar test case with an AsyncTask
sending messages through a handler to the UI.  Neither the task, nor
the handler, was completely frozen during the sleep, but the task was
taking longer to complete during that time.

Unfortunately, my production app has specific power usage constraints
imposed by the manufacturer/carrier (especially with the device
asleep), and it doesn't seem there is a good way to make sure the app
completely goes dormant when the device sleeps.  Any suggestions are
welcome.

Cheers
Tim

On Apr 22, 10:58 am, Dianne Hackborn <hack...@android.com> wrote:
> It is possible for the kernel to hold wake locks for various reasons.  If
> you want to see what was holding wake locks while you were unplugged, use
> "adb shell dumpsys batteryinfo" and look at the last set of stats (this is
> the raw information used to generate the battery usage UI).  However the
> kernel wake lock information is extremely hard to understand, and
> unfortunately I can't say for sure off-hand how to interpret it. :}
>
>
>
> On Thu, Apr 22, 2010 at 10:52 AM, THill <thill.dr...@gmail.com> wrote:
> > I've seen similar behavior as the OP.
>
> > I have a simple activity that starts a timer in onCreate, logging a
> > message every second.  No wake lock is requested, so after the time
> > indicated in setting, the device sleeps (allowed to dim, then sleep
> > naturally, not with power button press).  After letting it sit like
> > that for a few minutes, I plug it in via USB & check the logs, where I
> > can see the timer continued running through the sleep.
>
> > If I then do 'adb shell dumpsys power', the only wake locks shown are:
> > mLocks.size=2:
> >   SCREEN_DIM_WAKE_LOCK           'StayOnWhilePluggedIn Screen Dim'
> > activated (minState=1)
> >  PARTIAL_WAKE_LOCK              'StayOnWhilePluggedIn Partial'
> > activated (minState=0)
>
> > which makes sense since the device is now plugged in via USB.
>
> > Is this expected behavior?  Seems to go against the idea that all
> > threads are suspended during the sleep...
>
> > Thanks for any clarification,
> > Tim
>
> > On Apr 14, 4:31 am, Mark Murphy <mmur...@commonsware.com> wrote:
> > > westmeadboy wrote:
> > > > Just to confirm: the device isnotplugged into USB and I'mnotusing
> > > > any broadcasts or broadcast receivers.
>
> > > You aren't, but unless you have a completely clean device (or have
> > > hammered stuff into submission with a task killer), there might be other
> > > appsusingalarms.
>
> > > > When I do plug in and start the service these are thewakelocks:
>
> > > > mLocks.size=3:
> > > >   SCREEN_DIM_WAKE_LOCK           'StayOnWhilePluggedIn Screen Dim'
> > > > activated (minState=1)
> > > >   PARTIAL_WAKE_LOCK              'StayOnWhilePluggedIn Partial'
> > > > activated (minState=0)
> > > >   SCREEN_BRIGHT_WAKE_LOCK        'KEEP_SCREEN_ON_FLAG' activated
> > > > (minState=3)
>
> > > > and then when I homescreen, other app, turn the screen off (as
> > > > describe above) but leave the device plugged in, the third one
> > > > disappears.
>
> > > > So I would assume that when I unplug the USB, the first two to
> > > > disappear also...
>
> > > Make sure your screen timeout setting is set to a low value (yes, I
> > > know, you're manually turning off the screen, but humor me for a bit).
>
> > > --
> > > Mark Murphy (a Commons Guy)http://commonsware.com|
> >http://twitter.com/commonsguy
>
> > > _The Busy Coder's Guide to Android Development_ Version 3.0
> > > Available!
>
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Android Developers" group.
> > To post to this group, send email to android-developers@googlegroups.com
> > To unsubscribe from this group, send email to
> > android-developers+unsubscr...@googlegroups.com<android-developers%2bunsubscr...@googlegroups.com>
> > For more options, visit this group at
> >http://groups.google.com/group/android-developers?hl=en
>
> --
> Dianne Hackborn
> Android framework engineer
> hack...@android.com
>
> Note: please don't send private questions to me, as I don't have time to
> provide private support, and so won't reply to such e-mails.  All such
> questions should be posted on public forums, where I and others can see and
> answer them.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Android Developers" group.
> To post to this group, send email to android-developers@googlegroups.com
> To unsubscribe from this group, send email to
> android-developers+unsubscr...@googlegroups.com
> For more options, visit this group 
> athttp://groups.google.com/group/android-developers?hl=en

-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

Reply via email to