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 storyRemember 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 storyThat 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 ConfusionPower 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.
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