Application Power Management for Mobility white paper · 2014-02-26 · This white paper discusses the concept of Application Power Management for Mobility. Application Power Management

Copyright © 2002 Intel Corporation

Application Power Management for Mobility White Paper

March 20, 2002

R

Application Power Management for Mobility

R

2

Contents

1. Introduction................................................................................................................................... 4 1.1. Overview.......................................................................................................................... 4 1.2. Audience.......................................................................................................................... 4

2. Application Power Management for Mobility................................................................................ 5 2.1. Extending battery life ....................................................................................................... 5 2.2. Handling system sleep/wake power transitions............................................................... 6 2.3. Preventing the system from transitioning to sleep mode ................................................ 6 2.4. Implementing Application Power Management for Mobility ............................................ 7

2.4.1. Implementation steps for extending battery life............................................. 7 2.4.2. Implementation steps for handling system sleep/wake power transitions .... 7 2.4.3. Implementation steps for preventing the system from transitioning to sleep mode 8 2.4.4. Proof-of-concept application.......................................................................... 8

3. Microsoft Windows Power Management APIs and Messages .................................................... 9 3.1. Power status.................................................................................................................... 9

3.1.1. GetSystemPowerStatus ................................................................................ 9 3.1.2. WM_POWERBROADCAST ........................................................................ 10

3.2. Power schemes ............................................................................................................. 11 3.2.1. EnumPwrSchemes...................................................................................... 11 3.2.2. GetActivePwrScheme ................................................................................. 12 3.2.3. System Power Scheme change .................................................................. 12

3.3. Execution State ............................................................................................................. 12 3.3.1. SetThreadExecutionState ........................................................................... 13

4. Intel® Mobility Application Power Demo .................................................................................... 14 4.1. Overview........................................................................................................................ 14 4.2. Implementation of Application Power Management for Mobility ................................... 15

4.2.1. Extending battery life................................................................................... 15 4.2.2. Handling system sleep/wake power transitions .......................................... 19

4.3. Installation ..................................................................................................................... 19 4.4. Source Code.................................................................................................................. 19

5. Conclusion.................................................................................................................................. 20 Appendix A: Intel® Mobility Application Power Demo Executable and Source Code....................................... 21


R

3

Acronyms API Application Programming Interface

DLL Dynamic Link Library

MFC Microsoft* Foundation Classes

MSDN Microsoft* Developer Network

UI User Interface

* Other names and brands may be claimed as the property of others


R

4

1. Introduction

1.1. Overview A good user experience and longer battery life are critical factors for the future growth of mobile systems. Application software has a key role to play in improving user experience as well as in extending battery life. This white paper discusses the concept of Application Power Management for Mobility. Application Power Management for Mobility describes how application software can improve user experience and extend battery life.

This white paper includes, steps for implementing Application Power Management for Mobility within an application, references to available Microsoft* Windows∗ Power Management Application Programming Interfaces (APIs), and an overview of the proof-of-concept application developed by Intel® software labs.

1.2. Audience The intended audience for this white paper is architects, designers and developers writing applications for Microsoft* Windows* operating systems including: Windows* 98, Windows* 98SE, Windows* ME, Windows* 2K and Windows* XP. This paper also provides a good overview of Application Power Management for Mobility for managers, validation engineers, technical-marketing engineers or anyone defining/designing an application.

∗ Other names and brands may be claimed as the property of others


R

5

2. Application Power Management for Mobility Application Power Management for Mobility identifies three distinct power management capabilities for applications to implement. These power management capabilities are: extending battery life when the system is battery powered, handling system sleep/wake power transitions, and preventing the system from transitioning to sleep mode when the application is in use.

2.1. Extending battery life When the system is battery powered, applications can extend battery life by reducing the performance/quality of features, turning off background activities, or both. Implementing these operations in an application increases the processor idle1 time. Since processor power consumption when idle is significantly lower than when active2, this results in longer battery life.

There is no pre-defined list of performance/quality features and background activities for extending battery life. The performance/quality features and background activities are specific to an application.

Some examples could include:

• Reducing the quality of video and audio playback in a DVD application to extend playtime while traveling.

• Turning off automatic spell check and grammar correction within a word processing application to finish the document when the battery is low.

• Reducing the frequency of stock quote updates in web based financial applications to remain online longer.

When a system is battery powered applications can extend battery life. In addition, applications can define other criteria to determine when to extend battery life. These other criteria can be based on current battery power status, current system power scheme3, or both.

For example, an application can extend battery life when one or more conditions below are met:

• The percentage of remaining battery power is below a specific threshold.

• The remaining battery time is below a certain amount of time.

• The system is using a particular power scheme.

An application’s User Interface (UI) can provide options for specifying both how and when, to reduce performance/quality of features, to turn off background activities or both. User input is important, since users know their requirements and their environment best. User experience may not be optimal if applications predefined these settings without any options in the UI.

1 Idle refers to the processor state when the processor isn’t executing any instructions 2 Active refers to the processor state when the processor is executing instructions 3 Windows* operating systems allow users to set power settings most appropriate for their systems using power schemes. For more information on power schemes refer to the Windows* documentation.


R

6

2.2. Handling system sleep/wake power transitions In Windows* operating systems, the sleep power transition refers to switching off the system to a Stand By or a Hibernate mode, and the wake power transition refers to switching on the system from a Stand By or a Hibernate mode. The Stand by and Hibernate modes allow users to switch off and switch on systems a lot quicker than the regular shut down and boot processes.

Applications can improve user experience by handling system sleep/wake power transitions. Handling system sleep/wake power transitions means, applications should survive these power transitions without, requiring a restart, loss of data, and change in state. In addition, for a good user experience, applications should handle the power transitions transparently with no user interaction.

There is no generalized list of tasks for handling system sleep/wake power transitions. The tasks depend on the application and will vary between applications.

Some tasks for applications to consider include:

• Saving state/data prior to the sleep transition and restoring state/data after the wake transition.

• Closing all open system resource handles such as files and I/O devices prior to the sleep transition.

• Disconnecting all communication links prior to the sleep transition and re-establishing all communication links after the wake transition.

• Synchronizing all remote activity (like writing back to remote files or to remote databases) after the wake transition.

• Stopping any ongoing user activity (for example: streaming video, or file download) prior to the sleep transition and resuming the user activity after the wake transition.

2.3. Preventing the system from transitioning to sleep mode In Windows* operating systems, the system’s transition to sleep mode refers to switching off the system to a Stand By or a Hibernate mode. To conserve battery power, Windows* operating systems switch off the system to a Stand By or a Hibernate mode when they don’t detect certain activities for a specific period1 of time. The activities that Windows* operating systems don’t automatically detect are: disk activity, CPU activity and video display activity. The activities that Windows* operating systems automatically detect are: keyboard input, mouse input, server activity, and changing window focus.

Applications like video players and presentation managers display video for long periods of time without any user input and this often results in Windows* operating system switching off the system display during a video play back or a presentation. To deal with this situation, the options available for users are either to switch on the system display each time it switches off, or to delay the system transition to sleep mode by increasing the waiting period for display activity. Neither of these operations is optimal since switching on the system display each time reduces the user experience, and delaying the system transition to sleep mode wastes battery power when the system is not in use for extended periods.

When an application is performing an activity that the operating system doesn’t detect, it can prevent the system from transitioning to sleep mode by informing the operating system. This results in a better user experience as well as in better power management.

1 Windows* operating systems allow users to specify the time period using power schemes. For more information on power schemes refer to the Windows* documentation.


R

7

2.4. Implementing Application Power Management for Mobility This section outlines the steps for implementing Application Power Management for Mobility within an application.

2.4.1. Implementation steps for extending battery life The implementation steps for an application to extend battery life include:

1. Identify the application features where users may be willing to reduce performance/quality for extended battery life.

2. Identify the application background activities which users may be willing to turn off for extended battery life.

3. When a system is battery powered the application can extend battery life. In addition, the application can define other criteria to determine when to extend battery life. These other criteria can be based on current battery power status, current system power scheme, or both.

4. Review the Microsoft* Windows* Power Management APIs and Messages section in this white paper. This section outlines available Windows* operating system APIs and messages for retrieving system power information like system power source, battery status, and system power schemes.

5. Design and implement a UI so users can specify both how and when to reduce performance/quality of features, and/or to turn off background activities.

6. Implement application logic to retrieve system power information and determine when to reduce performance/quality of features, and/or to turn off background activities.

7. Implement application logic to reduce performance/quality of features, and/or to turn off background activities.

2.4.2. Implementation steps for handling system sleep/wake power transitions Windows* operating systems send messages to applications notifying them of system sleep and wake power transitions. Applications should respond to these messages and perform necessary operations to handle the power transitions.

The implementation steps for an application to handle system sleep/wake power transitions include:

1. Investigate the application behavior during system sleep/wake power transitions. In Windows operating systems, the sleep power transition refers to switching off the system to a Stand By or a Hibernate mode, and the wake power transition refers to switching on the system from a Stand By or a Hibernate mode.

2. Identify the issues causing the application to, require a restart, lose data, or change state.

3. Review the Microsoft* Windows* Power Management APIs and Messages section in this white paper. This section outlines available Windows* operating system APIs and messages for responding to system sleep/wake power transitions. In Windows* Power Management APIs terminology, the system sleep and wake power transition notifications are referred to as suspend and resume messages.

4. Implement application logic to respond to the power transition notifications and perform the necessary operations to survive the power transitions without, requiring a restart, loss of data and change in state. For a good user experience, handle the power transitions with no user interaction.


R

8

2.4.3. Implementation steps for preventing the system from transitioning to sleep mode The implementation steps for an application to prevent the system from transitioning to sleep mode include:

1. Identify application activities that the operating system doesn’t detect.

2. Review the Microsoft* Windows* Power Management APIs and Messages section in this white paper. This section outlines available Windows* operating system APIs for preventing the system from transitioning to sleep mode.

3. Implement application logic to prevent the system from transitioning to sleep mode when the application is performing activities that the operating system doesn’t detect.

2.4.4. Proof-of-concept application Intel® software labs developed the Intel® Mobility Application Power Demo as a proof-of-concept application to illustrate Application Power Management for Mobility. This proof-of-concept application simulates support for extending battery life and handling system sleep/wake power transitions.

Intel® Mobility Application Power Demo and its source code may be used as a reference for implementing Application Power Management for Mobility within your application. Refer to the Intel® Mobility Application Power Demo section for more details.


R

9

3. Microsoft Windows Power Management APIs and Messages The details covered in this section are applicable to Microsoft* Windows* operating systems including: Windows* 98, Windows* 98SE, Windows* ME, Windows* 2K and Windows* XP.

This section covers only the Microsoft* Windows* Power Management APIs and messages required for implementing Application Power Management for Mobility. For a complete reference to all Microsoft* Windows* Power Management APIs and messages refer to the Microsoft* Developer Network (MSDN) library.

Note: Most of the content is this section was taken from the MSDN library.

3.1. Power status This section covers the GetSystemPowerStatus API and the WM_POWERBROADCAST message. The GetSystemPowerStatus API is used to retrieve system power information such as system power source and current battery power status. The WM_POWERBROADCAST message is sent to notify applications of system sleep/wake power transitions and changes in system power status.

3.1.1. GetSystemPowerStatus The GetSystemPowerStatus API is used to retrieve system power information. This status indicates whether the system is running on AC or DC (battery) power, whether the battery is currently charging, and how much battery life remains.

To use this API, include the Windows.h header file and link with the Kernel32.lib library.

BOOL GetSystemPowerStatus(LPSYSTEM_POWER_STATUS pSystemPowerStatus);

Parameter: LPSYSTEM_POWER_STATUS pSystemPowerStatus – An out pointer to SYSTEM_POWER_STATUS structure that receives status information. Return Value: If the function succeeds, the return value is nonzero. If the function fails, the return value is zero. To get extended error information, call the GetLastError API (Refer to MSDN for GetLastError details).

Structure SYSTEM_POWER_STATUS typedef struct _SYSTEM_POWER_STATUS { BYTE ACLineStatus; BYTE BatteryFlag; BYTE BatteryLifePercent; BYTE Reserved1; DWORD BatteryLifeTime; DWORD BatteryFullLifeTime; } SYSTEM_POWER_STATUS, *LPSYSTEM_POWER_STATUS; The structure members are:

• ACLineStatus – Indicates AC power status. 0 for Offline (Battery/DC), 1 for Online (AC) and 255 for Unknown status.


R

10

• BatteryFlag – Indicates Battery charge status. 1 for High, 2 for Low, 4 for Critical, 8 for Charging, 128 for No system battery, and 255 for Unknown status.

• BatteryLifePercent – Percentage of battery charge remaining. The value can range from 0 to 100 and is set to 255 if the value is unknown.

• Reserved1 – Reserved, must be zero.

• BatteryLifeTime – Number of seconds of battery life remaining, or –1 if unknown.

• BatteryFullLifeTime – Number of seconds of battery life when at full charge, or –1 if unknown.

3.1.2. WM_POWERBROADCAST The WM_POWERBROADCAST message notifies applications of system sleep/wake power transitions and changes in system power status. An application window receives this message through its WindowProc function. To adhere to the API documentation and Windows* operating system terminology, in this section the term suspend refers to system sleep power transition and the term resume refers to system wake transition.

Note: Windows* operating systems do not send any notification to applications when a critical suspension occurs (for example, a battery failure). A critical resume notification (refer below to PBT_APMRESUMECRITICAL) is sent to applications after the system resumes from critical suspension. In such a scenario, an application should make a best effort attempt to restore its state and data.

To handle the message, include the Windows.h header file. LRESULT CALLBACK WindowProc( HWND hwnd, // handle to window UINT uMsg, // message id (WM_POWERBROADCAST) WPARAM wParam, // power-management event LPARAM lParam // function-specific data

);

Parameters: wParam – Specifies the power-management event. PBT_APMBATTERYLOW – Battery power is low. Not all BIOS implementations provide low battery notifications so this event may never be broadcast on some systems. PBT_APMOEMEVENT – OEM-defined BIOS signal event. The lParam specifies the OEM-defined event code and is in the range 0200h – 02FFh. Not all BIOS implementations provide OEM event notifications so this event may never be broadcast on some systems. PBT_APMPOWERSTATUSCHANGE – Power status has changed (for example, there has been a switch from battery power (DC) to AC). This message is also broadcast when the battery’s life drops to less than 5 minutes, when the remaining percentage of battery life drops below 10%, or when the battery life changes by 3%. The application should process this message by calling the GetSystemPowerStatus function to retrieve the current power status of the system. PBT_APMQUERYSUSPEND – is a request for permission to suspend the system. Applications granting permission to suspend should prepare for the suspension before returning. lParam – a DWORD value specifies action flags. If bit 0 is 1, the application can prompt for directions on how to prepare for the suspension; otherwise, the application must prepare without user intervention. All


R

11

other bits are reserved. Any operation taking longer than 20 seconds should be accomplished here, since the system allows only 20 seconds for operations to complete during PBT_APMSUSPEND. Return TRUE to grant the request for suspend and return BROADCAST_QUERY_DENY to deny the request.

PBT_APMQUERYSUSPENDFAILED – the suspension request is denied. This event is broadcast when any application or driver returns BROADCAST_QUERY_DENY to a previous PBT_APMQUERYSUSPEND event. Applications should respond by resuming normal operations. PBT_APMRESUMEAUTOMATIC – is broadcast when the system wakes up automatically to handle an event. Applications should not respond unless they are handling the event without user intervention. Detection of user activity after broadcasting PBT_APMRESUMEAUTOMATIC, broadcasts a PBT_APMRESUMESUSPEND event to let applications know they can resume full user interaction. PBT_APMRESUMECRITICAL – Operation resuming after critical suspension such as a battery failure. Since a critical suspension occurs without prior notification, resources and data previously available may not be present when the application receives the event. Applications should make a best effort attempt to restore their state. PBT_APMRESUMESUSPEND – Operation resuming after suspension. Applications can receive this event only if they received the PBT_APMSUSPEND event before the system was suspended. PBT_APMSUSPEND – the system is suspending operation and the message is broadcast immediately before the system enters the suspended state. This is broadcast when all applications and drivers have returned TRUE to a previous PBT_APMSUSPENDQUERY event. Applications should process this event by completing all tasks necessary to save state and data. Applications have approximately 20 seconds to handle this and are interrupted if operations continue after the 20 seconds have expired. lParam – Event-specific data, refer to wParam information for more details. For most events, this parameter is reserved and not used. Return Value: For PBT_APMQUERYSUSPEND event - return TRUE to grant a request and return BROADCAST_QUERY_DENY to deny a request. For other events there is no return value.

3.2. Power schemes The APIs for enumerating all the power schemes installed on the system and retrieving the current system power scheme are EnumPwrSchemes and GetActivePwrScheme.

To use these APIs include Powrprof.h header file and link with Powrprof.lib library.

3.2.1. EnumPwrSchemes The EnumPwrSchemes API enumerates all power schemes installed on a system. For each enumerated power scheme, EnumPwrSchemes calls a callback function with information about the power scheme. This call to the callback function is synchronous and does not return until all schemes are enumerated.

BOOL EnumPwrSchemes(PWRSCHEMESENUMPROC lpfnPwrSchemesEnumProc, LPARAM lParam);

Parameter: PWRSCHEMESENUMPROC lpfnPwrSchemesEnumProc – A pointer to a callback function for each enumerated power scheme.


R

12

LPARAM lParam – A user-defined value passed to the callback function. Return Value: When the function succeeds, the return value is ERROR_SUCCCESS. When the function fails, the return value is zero. To get extended error information, call GetLastError API. Callback function: typedef BOOLEAN (CALLBACK* PWRSCHEMESENUMPROC)( UINT uiIndex, // power scheme index DWORD dwName, // size of the sName string, in bytes LPTSTR sName, // name of the power scheme DWORD dwDesc, // size of the sDesc string, in bytes LPTSTR sDesc, // description string PPOWER_POLICY pp, // receives the power policy LPARAM lParam // user-defined value ); The name and description strings are null-terminated strings, and pp is a pointer to a POWER_POLICY structure containing the power policy scheme. The POWER_POLICY structure contains power policy settings unique to each scheme. Since power policy settings aren’t used in Application Power Management for Mobility, information on the POWER_POLICY structure is omitted from this paper. Refer to the MSDN library for details on POWER_POLICY structure.

3.2.2. GetActivePwrScheme The GetActivePwrScheme API retrieves the active power scheme (current system power scheme) index.

BOOL GetActivePwrScheme(PUINT puiID);

Parameter: PUINT puiID – A pointer to a variable that receives the index of the active power scheme. Return Value: If the function succeeds, the return value is nonzero, and if the function fails, the return value is zero. To get extended error information, call the GetLastError API.

3.2.3. System Power Scheme change

Windows* operating systems do not notify applications when the system power scheme is changed either programmatically or by the user. To handle a system power scheme change, the Intel® Mobility Application Power Demo relies on Windows* Timer messages to retrieve system power scheme information (using the GetActivePwrScheme API) at regular intervals. For details on Windows* Timer messages refer to the MSDN library.

3.3. Execution State

This section covers the SetThreadExecutionState API, which is used to prevent the system from transitioning to sleep mode.


R

13

3.3.1. SetThreadExecutionState The SetThreadExecutionState API enables applications to inform the operating system when they are in use and thereby preventing the system from transitioning to sleep mode.

To use this API, include the Windows.h header file and link with the Kernel32.lib library.

EXECUTION_STATE SetThreadExecutionState(EXECUTION_STATE esFlags);

Parameter: EXECUTION_STATE esFlags – Specifies the thread's execution requirements. This parameter can be one or more of the following values:

ES_SYSTEM_REQUIRED - Informs the system that the thread is performing some operation that is not normally detected as activity by the system.

ES_DISPLAY_REQUIRED - Informs the system that the thread is performing some operation that is not normally detected as activity by the system.

ES_USER_PRESENT - Informs the system that a user is present. If a user is present, the system will use the power policy settings set by the user. Otherwise, the system does not wake the display device and will return to the sleeping state as soon as possible.

ES_CONTINUOUS - When this flag is used with one or more of the other state flags it informs the system that the state being set should remain in effect indefinitely. To reset or clear the indefinite condition, call SetThreadExecutionState again with just the ES_CONTINUOUS flag.

Return Value: If the function succeeds, the return value is previous thread execution state, and if the function fails, the return value is NULL.

For example, a presentation application should call SetThreadExecutionState with ES_SYSTEM_REQUIRED, ES_DISPLAY_REQUIRED and ES_CONTINUOUS flags prior to a slide show, and when the slide show is complete the presentation application should call SetThreadExecutionState with just the ES_CONTINIOUS flag.


R

14

4. Intel® Mobility Application Power Demo Intel® software labs developed the Intel® Mobility Application Power Demo as a proof-of-concept application to illustrate Application Power Management for Mobility. The Mobility Application Power Demo and its source code may be used as a reference for implementing Application Power Management for Mobility within your application.

This section includes, an overview of the Mobility Application Power Demo, a description on how the Mobility Application Power Demo simulates support for Application Power Management for Mobility, and how to access the Mobility Application Power Demo and its source code.

4.1. Overview The Mobility Application Power Demo, like Microsoft’s Notepad is a simple word processing application allowing users to open, edit and save text documents. The application simulates support for extending battery life and for handling system sleep/wake power transitions. It does not simulate support for preventing the system from transitioning to sleep mode.

Other application features include:

• Creating new or opening existing documents in plain text format.

• Copying, cutting and pasting text.

• Undoing changes made to the document.

• Saving changes to an existing document.

• Writing to a new document in plain text format.

• Printing and print previewing the document.

• Tracking the most recently opened documents.

• Viewing battery status and battery details like name, type, and manufacturer’s name.

• Selecting save options like directory to save to and prompting for unsaved data.

The application’s main UI shown in Figure 1 includes, a menu/tool bar for accessing application features, a status bar indicating application status, and an edit window for writing/editing text documents.

The menu items provides access to the following application features:

• Use the File menu for creating, opening, saving and printing text files.

• Use the Edit menu for cutting, copying and pasting text.

• Use the View menu for viewing the battery status information, and to show or hide the status/tool bars.

• Use the Options menu for selecting the save and the power options.

• Use the Help menu for viewing the about box and the overview of the Mobility Application Power Demo.


R

15

4.2. Implementation of Application Power Management for Mobility The Mobility Application Power Demo’s implementation of the Application Power Management for Mobility concepts is just a simulation. The application’s options and UI used to simulate the concepts are for illustration purposes only and should not be considered a design guideline.

4.2.1. Extending battery life To extend battery life, the Mobility Application Power Demo implements the following:

• Two modes of operation: Normal mode and Low Power mode.

• A Power Options UI, so users can specify how and when to extend battery life.

Normal mode versus Low Power mode

The Mobility Application Power Demo switches from Normal mode to Low Power mode for extending battery life and switches back to Normal mode when not extending battery life. Switching of the modes is for illustrative purposes only and has no effect on the application performance. The application’s status bar displays the current mode of operation (shown in Figure 2).


R

16

Power Options UI

The Mobility Application Power Demo’s Power Options UI provides options so users can specify when the application should switch to Low Power mode and how it should perform in Low Power mode. The power options UI is a property sheet with a Settings tab and a Low Power tab. This property sheet is accessible from Options\Power menu as shown in Figure 3 below.


R

17

Settings Tab

The Settings tab shown in Figure 4 below allows users to set conditions on when to switch the application to Low Power mode. The application switches to Low Power mode when the system is battery powered and when all the conditions in this tab are met.

The conditions are:

• Switch the application to Low Power mode when the current battery power level falls below a specified threshold.

• Switch the application to Low Power mode either for all power schemes or when the current system power scheme matches a selected power scheme.

In addition, the Settings tab displays system power status information like current power source, percentage of remaining battery power, remaining battery time, and current power scheme.


R

18

Low Power Tab

The Low Power tab shown in Figure 5 below allows users to specify how the application should perform in Low Power mode. The options in this tab are the performance/quality of features to reduce and the background activities to turn off for extending battery life. The options are for illustrative purposes only and have no effect on the performance of the Mobility Application Power Demo.

The Low Power tab options include:

• In Low Power mode, the option to reduce video playback quality.

• In Low Power mode, the option to increase the time interval for information updates from the Web.

• In Low Power mode, the option to turn off specific application features.


R

19

4.2.2. Handling system sleep/wake power transitions

The Mobility Application Power Demo simulates support for handling system sleep/wake power transitions by displaying status messages (shown in figures 6 & 7 below) indicating preparation for suspend and resume operations. The status messages are for illustrative purposes only, for a good user experience applications should handle system sleep/wake power transitions transparently without displaying any messages.

4.3. Installation The link for downloading the Mobility Application Power Demo is available in Appendix A. The download includes the Mobility Application Power Demo executable (pwrdemo.exe) and its Readme file (Read Me.htm). Install the Mobility Application Power Demo on the target system and double click the executable to start the application. No additional libraries or DLLs are required.

The system requirement for running the Mobility Application Power Demo is: • A battery powered notebook1 running on Windows* (98, 98SE, ME, 2K or XP) operating system.

4.4. Source Code The link for downloading the Mobility Application Power Demo’s source code is in Appendix A. The download includes all the source files and the design notes (Design Notes.htm) for the application. The design notes provide a brief overview on the contents of the source files.

The Mobility Application Power Demo is written in C++ and uses the Microsoft* Foundation Classes (MFC) application framework library. To build the application use Visual Studio 6.0 IDE.

1 [Note - The application does run on desktops and notebooks without battery, but you will not be able to see how the application switches between Normal and Low Power modes.]


R

20

5. Conclusion As outlined in this white paper, it is fairly straightforward to implement Application Power Management for Mobility within applications. Remember the following steps when implementing Application Power Management for Mobility: • Identify the application performance/quality features to reduce and the application background

activities to turn off for extended battery life. • Identify the issues causing the application to, require a restart, lose data or change state during system

sleep/wake power transitions. • Identify application activities that the operating system doesn’t detect. • Review the Microsoft* Windows* Power Management APIs and Messages section in this white

paper. • Use the Intel® Mobility Application Power Demo application and its source code as a reference

during your design and development. • Implement a UI so users can specify when and how to reduce performance/quality of features and /or

turn off background activities for extended battery life. • Implement application logic to extend battery life, to handle system sleep/wake power transitions,

and to prevent the system from transitioning to sleep mode when the application is performing activities that the operating system doesn’t detect.


R

21

Appendix A: Intel® Mobility Application Power Demo Executable and Source Code

Intel® Mobility Application Power Demo executable is available at: http://www.intel.com/design/mobile/platform/la_power_demo.htm

Intel® Mobility Application Power Demo source code is available at: http://www.intel.com/design/mobile/platform/la_power_demo_source.htm

http://www.intel.com/design/mobile/platform/la_power_demo.htm

http://www.intel.com/design/mobile/platform/la_power_demo_source.htm

Documents

Application Power Management for Mobility white paper · 2014-02-26 · This white paper discusses the concept of Application Power Management for Mobility. Application Power Management