Thanks Yusuf.  That's helpful - I am very familiar with that
documentation. I was looking for something more though.  I'm hoping to
see a more comprehensive discussion about this behavior.  I need to
put together something for QA testers.  No state can be left un-
described for what I need.

And thank you Dianne.  As always - a big help.  This makes sense.
What's not complete on my list, though is how a dark screen, phone
components, and wake locks relate.  I am not just looking for
documentation on DIM wake lock and full wake lock.  There are
additional use cases here:

* menu lock on/off (must press the menu button): what affects that?
How do wake locks affect that?

* dark screen versus a fully functional phone: for the complete list
of sensors and application services (e.g TelephonyService notification
to my TelephonyListener, Wifi antenna, and sensors), how do wake locks
affect each one?  When does each one get turned off?

* how do each power state affect Timer class objects and application
threads - for both foreground apps and background services?

* when the user forces the screen to go dark by pressing the end-call
button, what power state/wake lock state am I in?

* when the application forces the screen to go dark by calling
PowerManager.

I also have the following case that I need to prove is working
properly:

1. A RTC clock alarm fires an intent and wakes up the phone.
2. The application catches the intent and gets a wake lock. A
background service is ran (no UI involved).
3. The wake lock is a dim wake lock, but the screen doesn't come on
(that great).
4. The application does its processing then releases the wake lock(s)
it acquired when responding to the intent.


I believe it is.  The more comprehensive information I'm looking
proves it.....

Thanks again.

Richard Schilling








On Oct 1, 1:05 pm, Dianne Hackborn <[email protected]> wrote:
> Unless there is a third party app messing with you, there is something
> broken with your software.  The typical behavior is:
>
> - Screen dims after the screen-off timeout sets in preferences, and then
> turns off (and locks) a few seconds later.
> - Screen turns off and locks with you press them end call / power button.
>
> This can be changed by applications -- for example most apps that play
> videos turn on the option to keep the screen on while the video is playing,
> so then you will need to manually press the power key to make it turn off.
> Apps can also hold wake locks to impact how the device goes to sleep, though
> they need to be granted the power permission to do so.  (No permission is
> needed to simply keep the screen on while your window is in the foreground.)
>
> On Thu, Oct 1, 2009 at 12:24 PM, Richard Schilling <
>
>
>
> [email protected]> wrote:
>
> > I'm looking around and trying to find out where sleep behavior is
> > documented - and I mean in the general sense.
>
> > When the phone is left alone:
> > * Sometimes the phone screen dims and doesn't shut off.
> > * Sometimes the phone screen goes dark in five seconds
> > * Sometimes the menu lock happens.
> > * Sometimes the menu lock doesn't happen.
> > * Sometimes the only way to darken the screen is to push the power
> > button.
>
> > What's not clear is what triggers these different states.   I'm
> > looking for a complete list I can use in testing and application
> > validation.
>
> > Can anyone point me in the right direction?
>
> > Thanks.
>
> > Richard Schilling
> > Mobile Operating Systems Engineer
> > Root Wireless, Inc.
>
> --
> Dianne Hackborn
> Android framework engineer
> [email protected]
>
> 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 [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to