O.K. I'll dive into PowerManagerService then - that's a good place to look more into.
I agree this should be discussed on Android Porting as well. I'm just more worried about how applications are affected for the moment. But, I'll keep an eye on porting in the meantime. I imagine someone else has similar thoughts. Cheers, Richard Schilling On Oct 5, 3:16 pm, Dianne Hackborn <[email protected]> wrote: > Hi Richard, sorry I really don't have time to go into detail on this stuff > at this point (and don't personally know enough to cover everything > anyway). Ultimately the source code -- in particular PowerManagerService > and the keyguard interactions as start in PhoneWindowManager -- is the > ultimate specification, and these things change over time (for example in > Eclair the press menu to unlock behavior will be different at least on some > class of devices). And many parts of this are intended to be fairly easy to > customize by a manufacturer to work most appropriately for their device. > > Finally, this really sounds like the discussion should be on > android-porting; this doesn't look like stuff that is relevant to third > party developers. > > On Mon, Oct 5, 2009 at 2:21 PM, Richard Schilling < > > > > [email protected]> wrote: > > > 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. > > -- > 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 -~----------~----~----~----~------~----~------~--~---
