In Power to the People we learned some of the differences between how PocketPCs and Smartphones handle power.  In Power to the Developers part 1 we learned about some of the things a developer can do to manage his app's use of power.  In preparing a part 2 of the developer entry, I've realized that we need a prequel that describes the System's "Power Manager" and how it behaves. 

Half the story
Remember that what I'm about to describe here is really only half the story when it comes to power.  On CE, one millisecond after there's nothing for the CPU to do, it goes idle.  In idle the CPU is moved into an extremely low power mode and doesn't power back up again until either some piece of hardware wakes it up, or a scheduled task happens.  Also, most drivers aggressively self-manage their power.  If nothing is plugged into the USB port, for instance, the USB port isn't powered, etc.  This is moderately interesting in that it's an indication that we're doing things correctly, but to a developer or a user, all you really need to know is that apps which use the CPU unnecessarily waste power.  Hopefully you've gotten that message in my previous two entries.

The other half of the story
That brings us to Power Manager (PM).  PM manages many of the hardware drivers in the system.  It can manage all of them, but a driver must be written to take advantage of PM's control, and we haven't required that they all do so.  PM is relatively new.  It was first introduced to Windows Mobile in the 2003 edition.  And, over time, we've been migrating more and more power functionality to it.

The main job PM handles is managing drivers that can't manage themselves.  As I said above, the USB port knows when nothing is plugged into it, and can shut itself down.  But the LCD screen doesn't know if a user is looking at it, so it doesn't know when to turn itself off.  That's where PM comes in.  PM might also control USB ports, but, even if it tells them to turn on, they won't if there's no reason to. 

You should think of PM as doing stuff on a granularity that's relevant to users and developers.  You set control panel entries which say to turn off the backlight after 15 seconds and to turn the screen off after 3 minutes, etc.  Those control panels feed that information to the Power Manager.  On the other hand, you don't have much control over what happens in the millisecond granularity of idle.

State of Confusion
Power Manager uses a concept called "System Power States" to do exert its control.  The concept is pretty simple.  PM has a list of drivers it controls, and, for each state, it has list of settings for those drivers.  In one state, it turns everything on.  In another, it turns off the screen and backlight, but leaves everything else on.  In yet another, it turns off the screen, backlight, and audio, etc.  Remember that many drivers know better than PM and will stay powered off even when it says to turn on (i.e. the USB port that has nothing plugged into it).

There are a lot of these states.  Some are relevant to PocketPC, and some are relevant to Smartphone.  I'm going to list them here and give a brief description of what they do.

  • On:  The user is interacting with the device.  Everything is on.
  • BacklightOff:  There has been a brief period of user inactivity (no one has pressed any buttons or touched a touchscreen).  The backlight has been turned off, but everything else is on.  When you set the backlight timeout values in the control panel, you're setting how long the system should wait before going into this state.  (Note that this state is new for WM 5.) 
  • UserIdle:  There has been a longer period of user inactivity.  Both the backlight and LCD have been turned off.  When you set the screen timeout value on a Smartphone control panel, you're setting how long the system should wait before going into this state.  This state is generally not used on PocketPC.  There's no reason to turn the screen off when the device is about to go to sleep (sleeping turns the screen off).  However, if/when PocketPCs go to the "Always On" model, they'll start using this state.
  • ScreenOff:  You go into this state when someone specifically says to turn the screen (and backlight) off.  For instance, in Media Player you can assign a button to turn the screen off.  When you press it, we go into this state.  This state is different than UserIdle, though.  This state says, "The user wants the screen off and doesn't want it to turn back on."  UserIdle says, "The user hasn't touched any buttons in a while, so we might as well turn the screen off to save power."  In ScreenOff, pressing a button (other than the power button) doesn't turn the screen back on.  In UserIdle, pressing a button does turn the screen back on.  Both PocketPC and Smartphone use this state.
  • Unattended:  This is a confusing state in which the screen, the backlight, and the audio are off.  I won't go into too many details, other than to say that this is a PocketPC-only state that is used by applications which need to do things without alerting the user.  While the PocketPC is in this state, the user thinks the device is asleep.  For instance, ActiveSync when it syncs every 5 minutes.  It's waking up, syncing, and going back to sleep, but the user can't tell.
  • Resuming:  This is the state the PocketPC goes into when it wakes up from sleep.  In this state, the screen is off, and there is a very short (15 second) timer before it goes back to sleep.  The only way to keep the device from going back to sleep is to have something put it into one of the other states.  This is really for dealing with spurious wakeups and for giving the system a way to get into Unattended without letting the user know about it. 
  • Suspended:  This is the PocketPC "Sleep" state.  Everything is off, and the system isn't going to wake back up until some piece of hardware wakes it up.  It's not actually an official Power Manager state, the way the other six are, but I'm including it for completeness.

As you can see, things are much simpler in an "Always On" device like Smartphone (the three most complicated states don't get used). 

Next up: how to have Power Manager tell your app whenever these state transitions happen.

Mike Calligaro