1. Power aware applications

Nowadays mobile devices are designed to be carried everywhere but are powered by batteries with limited energy capacity. This implies that battery lifetime for devices becomes critical in the design of the software and hardware ecosystem. The designer should consider energy efficiency across operating systems, drivers, hardware components, and applications. Applications, as key players in the mobile ecosystem, are important optimization targets for making the system energy efficient. App developers should always keep in mind energy and power consumption in the design of their applications.

Power aware applications respond to power state changes and provide different options to users to extend battery lifetime. The power state information could be system AC/DC power information, the remaining battery levels, or the hardware component power state etc. Power aware design is useful especially for certain battery hungry scenarios to preserve power with trade-offs on performance or user experiences.

In designing power aware apps, the first rule is to minimize the utilization of hardware resources in general scenarios. The second rule is to identify the battery hungry scenarios by the power state information and provide energy efficient alternatives while recognizing trade-offs of user experience or performance in order to extend battery life.

2. Use resources with less power

In general, energy/power consumption comes from hardware component utilization in the device. Energy efficiency comes from limiting hardware resource usage. Also, look carefully at your methods for utilizing hardware components, and make use of the most efficient methods.

The Android framework is designed to be energy efficient. When apps need hardware data or contents, Android provides passive event-driven mechanisms instead of prompting applications to actively poll the data. This is because active polling introduces more CPU or hardware utilization than event driven methods, which suggests we should utilize event driven mechanisms to cache the events in the app. Android provides events like intents, notifications and content observer to notify the apps on the changes of hardware components or the changes of contents. Each kind of event is managed by internal services. Once the services detect changes, the services notify the apps.

Suppose we design an app that needs location data. Android provides a location service enabling location data to multiple applications. The service allows the app developer to specify the location provider: GPS, network or passive. Deciding which provider to use is a trade-off in accuracy, speed and energy efficiency. Once an app registers itself to the location service with specified criteria, the location service sends location change notifications to the app according to the criteria.

The sample code below shows how to get accurate location data from the GPS. The code first specifies the GPS as the location provider with fine accuracy criteria. Fine accuracy criteria location services will send notifications as location data with more accuracy is changed. A location listener responds to the location change notifications. Whenever the location service detects change, the corresponding methods defined in a location listener are called. In the example, we call a dummy computation function whenever the location changed notification is received. The dummy computation computes 1000 iterations of simple operations. The more accuracy the provider criteria specifies, the more frequently the location notification is received and the more computation the app needs to respond with. Thus more accuracy criteria use more power with possibly better user experience. In the last step, the listener is registered to the location service to receive location change notifications. Whenever the registration happens, the location service utilizes the specified device provider to retrieve location data periodically and sends notifications to the apps if changes are detected.

Sample code 1: get accurate location data from GPS **

Except to utilize the GPS as a location provider with fine accuracy, we have other options that can provide location data with different accuracy. Each one has its own advantages and disadvantages. We list the major five methods as below.

We utilized the first four methods on an Android smart phone and record the average power discharged from the battery over an interval in Figure 1 (The last option with passive option relies on other location based apps to receive location data). In the experiments, the LCD display remains on with 50% brightness and the network utilizes WIFI connection. Both GPS and network are turned on all the time. We plot the average device power for the first four methods.

Figure 1: Average power comparison for location based service with different providers and different accuracy criteria.NOTE: The power consumed shown in the figure above is from one device, and will differ from one device to another

Figure 1 shows the device with the identical application utilizing GPS provider consumes more power than the one utilizing network provider. This is because the GPS hardware component can lead to higher power consumption than wifi on this platform. In this case, the app developer should consider whether the network provider helps or hinders the applications’ performance qualities. The figure also shows that the GPS/network provider with fine accuracy consumes slightly higher power than the same provider with coarse accuracy. This is because the fine accuracy criteria trigger more frequent computation in the app than the coarse accuracy criteria. In this case, the app designer should also consider whether the fine accuracy is necessary for the application performance qualities.

2. Develop power aware applications

In order to design power aware apps, the application must have the knowledge of power information or hardware power states. On Android, this requires that the app registers the corresponding power change events. Whenever the app receives the registered events, it provides alternative power saving mechanisms.

3.1. Monitor power information

Android broadcasts multiple power related events for apps through intents. We can utilize intents to receive the power information whenever there is a power change in the system or hardware components.

In order to receive the broadcasted intents, there are three steps.

Initialize an intent filter which specifies which intents the app would like to receive.

Define the broadcast message receiver class that listens to the specified intents whenever they are broadcasted.

Register a receiver instance and the intent filter.

The below are the sample codes for the step 1) and 3). We define an intent filter powerinfofilter and a broadcast message receiver instance from PowerInfoReceiver class.

Sample code 2: receive the power information **

The PowerInfoReceiver class is defined as a broadcast message receiver.

With the sample codes, the app is able to receive the intents specifying the remaining battery level, the AC/DC power, or the battery low/ok indication whenever these events happen.

3.2 Power aware app design

There are multiple ways to design power aware apps. One way is to provide multiple power saving options for users, either through user-selectable UI or via hidden automated switches to alternative methodologies in different energy hungry scenarios.

3.2.1 Provide user options to save power

When the device is on and the battery level becomes low, the app designer should consider the trade-offs between the user experience and the battery life extension.

Here is an example where the application provides a display backlight control UI whenever the battery is low. In general cases, the backlight control UI is invisible to users. Whenever the battery level becomes low and the device is powered by battery, the backlight control UI shows up and allows user to lower display backlight brightness.

In terms of power, we measure the average device power of a smart phone with a LCD display when system is in idle with display on. We change the display backlight level from 10% to 100%. Figure 2 below shows the trend of the average power associated with backlight change. The figure shows, the higher the backlight brightness is, the more power the device consumes. Therefore, if the application provides the UI for the user to decrease the brightness level, the device battery can last longer. In this way, the user can trade-off some tolerable user experience to extend the battery life time.

Figure 2: the relationship between the average device idle power and the display backlight level

NOTE: The power consumed shown in the figure above is from one device, and will differ from one device to another

The sample codes below show the specified broadcast receiver that can catch the ACTION_BATTERY_LOW intent. Whenever the intent happens and the device is on battery, the backlight control seek bar becomes visible (the code in green) to users.

We can have multiple designs for the same functionalities under different energy hungry scenarios to extend battery life. When the device is connected to AC or DC power with high battery level, users may opt to have better performance or user experience. When the device battery is low with DC power, users may opt to extend battery life time with energy efficient design. These energy hungry scenarios with device battery should prompt developers to implement different methodologies for power savings.

Here we have an example about how the location based app adjusts the location service update frequency and range in order to extend battery life time.

Sample code 6: adjust the location update interval and range **

In the example, whenever the app receives a battery level change, the app adjusts the minimum time and the minimum distance interval for the location change notifications. The lower the battery level is, the longer the notification interval and the longer the transaction distance for the location service becomes. Ultimately, the developer wants to reduce the notification receiving frequency when battery levels are low. In such a way, the developer reduces the computations triggered by the notifications. For example, if a location changes, the app is going to refresh the map. The map data refresh process consumes power. If the map data refresh process happens less frequently, less power is consumed with a tradeoff of user experience.

4. External resources and reference

Many design rules and concepts of power aware apps are similar in different platforms and various OS. Even though Android based devices have different power usage of hardware components, we can still use most of the power aware app design guidance for other platforms and other OS as reference. Here we list the several links on power aware app design on other platforms. They are useful as basic guidance of power aware apps.

About the Author

Sushu Zhang is a software engineer in Intel's Software and Services Group. She is working on ISV scale enabling for Intel based platforms with Android / Windows OS. She developed Intel® Power Monitoring Tool for Android Devices. Most recently, Sushu has been involved with several energy-efficiency projects at Intel. Prior to joining Intel, Sushu worked at Microsoft on Windows energy efficiency. Sushu earned a Ph.D in Computer Science at Arizona State University. Her research area was system level power and thermal management.

Notices

INFORMATION IN THIS DOCUMENT IS PROVIDED IN CONNECTION WITH INTEL PRODUCTS. NO LICENSE, EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, TO ANY INTELLECTUAL PROPERTY RIGHTS IS GRANTED BY THIS DOCUMENT. EXCEPT AS PROVIDED IN INTEL'S TERMS AND CONDITIONS OF SALE FOR SUCH PRODUCTS, INTEL ASSUMES NO LIABILITY WHATSOEVER AND INTEL DISCLAIMS ANY EXPRESS OR IMPLIED WARRANTY, RELATING TO SALE AND/OR USE OF INTEL PRODUCTS INCLUDING LIABILITY OR WARRANTIES RELATING TO FITNESS FOR A PARTICULAR PURPOSE, MERCHANTABILITY, OR INFRINGEMENT OF ANY PATENT, COPYRIGHT OR OTHER INTELLECTUAL PROPERTY RIGHT.

UNLESS OTHERWISE AGREED IN WRITING BY INTEL, THE INTEL PRODUCTS ARE NOT DESIGNED NOR INTENDED FOR ANY APPLICATION IN WHICH THE FAILURE OF THE INTEL PRODUCT COULD CREATE A SITUATION WHERE PERSONAL INJURY OR DEATH MAY OCCUR.

Intel may make changes to specifications and product descriptions at any time, without notice. Designers must not rely on the absence or characteristics of any features or instructions marked "reserved" or "undefined." Intel reserves these for future definition and shall have no responsibility whatsoever for conflicts or incompatibilities arising from future changes to them. The information here is subject to change without notice. Do not finalize a design with this information.

The products described in this document may contain design defects or errors known as errata which may cause the product to deviate from published specifications. Current characterized errata are available on request.

Contact your local Intel sales office or your distributor to obtain the latest specifications and before placing your product order.