Yongqin Liu, LCA14, Macau

Improving Android Battery Life

Battery life can be improved by reducing power consumption via many methods• Hardware

• Improve product design, use higher capacity battery, etc.

• Software• Optimize Kernel & Drivers: like kernel PM, device drivers• Optimize framework: make use of various kernel features from user

space, and provide optimized PM mechanism or interfaces• Optimize Apps : use features of framework and focus on power

consumption from the application / user scenario.

• User • Turn off wifi/bluetooth/gps, turn down brightness, etc

Introduction

We focus on :- Optimizing framework to make use of various kernel features from user space, and provide optimized PM mechanism or interfaces

Since battery is the only source for android device, so to extend the battery life of device, we need first to know the battery and how it connects with device.

• Li-ion type battery is the main type used for android device today• Smart battery pack can help to get battery information• The capacity is the major factor that affects battery life for the

device• Battery Life = Battery Capacity * Level / 100 / Total Current

Battery

Voc: open circuit voltageRi : internal resistanceCl : load capacitanceRl : load resistanceI: total current generated

I

So, to extend the battery life, we need to control the total current generated by the battery, and that means turning off some hardware modules or make the hardware module itself draw less current

Hardware Modules that impact battery significantly

● Screen○ Strongly influenced by the brightness, the higher brightness, the more energy it will consume.○ so to reduce the consumption, we need to lower the brightness or turn it off.

● CPU○ the cpu power consumption mainly depends on it’s frequency and utilization.○ the higher frequency it is, the more energy it consumes○ the higher utilization of the cpu, the more battery it consumes○ so to make the device continue longer, it’s better to make less use of the cpu

● WIFI○ The wifi interface has four power states: low-power, high-power, ltransmit, htransmit

■ ltransmit and htransmit are states that network card briefly enters when transmitting data. After sending the data, the card returns to its previous power state

■ when the wifi interface is neither sending or receiving data at a high rate, it will enters the low power state■ when more than 15 packets are transmitted or received per second, wifi will transmit to high-power state from low-

power■ and the power consumptions order is : low-power<high-power<ltransmit/htransmit

○ to reduce the power energy consumed by WIFI, it’s better to transmit less data, or not transmit data, or even turn it off.● GPS(Location service)

○ android provides some options for Location mode on power consumption when using the Location service. ○ for the battery saving, use less location service(sync up data less times), or use the Battery Saving mode, even not use

location service.● Bluetooth

○ The BLE support with Bluetooth 4.0 would be the good choice■ http://pocketnow.com/2013/01/17/bluetooth-low-energy

○ And android supports Bluetooth Low Energy(BLE) from 4.3 (API Level 18)■ http://developer.android.com/guide/topics/connectivity/bluetooth-le.html

WakeLocks

Wake Lock Level/Flag CPU Screen Keyboard

PARTIAL_WAKE_LOCK on off off

SCREEN_DIM_WAKE_LOCK on dim off

SCREEN_BRIGHT_WAKE_LOCK on bright off

FULL_WAKE_LOCK on bright bright

ACQUIRE_CAUSES_WAKEUP no effect turn on immediately when the WakeLock is acquired no effect

ON_AFTER_RELEASE no effect cause to remain on a bit longer when WakeLock released no effect

PowerManager Locks

WakeLock is the mechanism android provides for controlling power consumption. By acquiring the wakelock, we can prevent devices from suspend, so be careful to use them. There are 2 classes provide such WakeLocks: PowerManager and WifiManager. We will only focus on PowerManager this time.

You can see that the state of cpu, screen and keyboard light can be controlled by the WakeLocks, but the utilization degrees of devices are not controlled. like the frequency of cpu, the brightness of screen, and this is where we will check later on how the degree control will affects power consumption when wakelocks are acquired.

To improve battery life is to minimize the power consumption, and according to the WakeLock mechanism provided by Android, we can categorize the power consumption into 2 types:

● Active Power Consumption○ wakelocks acquired, and some processing is on-going○ like video playback, audio playback, or graphics display

● Static Power Consumption○ all wakelocks are released, and only limited or no processing is on-

going, the system is waiting for a wakeup event. ○ like the Sleep/Standby state

Next we will see how we can minimize power consumption for these 2 types.

Category of Power Consumption

Tools for Analysis

● PowerTutorPowerTutor is an application for Google phones that displays the power consumed by major system components such as CPU, network interface, display, and GPS receiver and different applications.http://ziyang.eecs.umich.edu/projects/powertutor/

● BatteryMixReally good tools for investigations on power consumption, it will show how fast the battery is consumed along with the information of LCD/Wifi/Bluetooth/GPS.https://play.google.com/store/apps/details?id=jp.smapho.battery_mix

● Scripts○ used to collect information of battery/lcd/cpu periodically ○ battery information from: /sys/class/power_supply/battery○ lcd brightness information from: /sys/class/leds/lcd-

backlight/brightness○ cpu frequency and utilization information from:

/sys/devices/system/cpu/cpuX/cpufreq

Use Cases Analyzed

Case 1 - Video Playback

Player Time(Minutes) Power Consumption(%) Assumption Time(Hours)

Stock Player 112 10 100 / 10 * 112 / 60 = 18.7

MX Player 113 19 100 / 19 * 113 / 60 = 9.9

Player Current(mA) Brightness(Max: 255) Cpu0 Utilization(%) Cpu1 Utilization(%)

Stock Player 189.7 5 91.9 43.6

MX Player 371.9 127 92.7 43.6

Stock Player MX Player

We compared the power consumption on video playback between different video players and different android builds, and finally found that there much difference between Stock Player and MX Player. MX Player consumes about 2 times of the Stock player power consumption.

After checked the information we collected, we found that the battery current is very different, and it is mainly caused by the brightness. The Stock Player used the lowest brightness we set in the Settings, while what MX Player used is 127.

After we set the brightness to 5 while playing video via MX Player, we got the reduced current value and power consumption, similar as the Stock Player now:

Time(Minutes) Consumption(%) Current(mA) Brightness(Max:255) Assumption (Hours)

112 9 184.9 5 100/9*112/60=20.7

Case 2 - Audio Playback

Frequency(Hz) 1026000 384000 1512000

Utilization(%) 1 1 100

Current(mA) 68.5 63.7 68.7

While playing an mp3 audio file, we set to use the userspace governor policy first, we set the cpu frequency to 1026000Hz, and then changed to the lowest frequency 384000Hz, and at last changed back to the ondemand policy with highest frequency 1512000Hz. This change can be seen from the CPU-Frequency chart.Since the level change was not obvious, so we check the information of battery current. There we found the lowest frequency generates the lowest current 63.7mA, the difference 5mA(compared to the default ondemand policy) is very little, but it shows us there is the possibility we can save power enery via adjusting cpu frequency or governor policy while audio playback.

Case 3 - Graphics

2D(powersave) 2D(ondemand) 3D(powersave) 3D(ondemand)

Current(mA) 192 352 232 399

Time(Minute) 90 33 44 30

Consumption(level %) 8 6 5 5

Consumption(mAH) 288 194 170 199

we checked the effects of governor policy on power consumption with the 0xbench(2D&3D) test cases. For 3D test, powersave policy saved 29mAH than ondemand policy. For 2D test, powersave policy generated less current, but took long time to finished the tests because the reduced performance, and this make more power energy consumed finally. So we need to pay attention to the performance while we adjust governor policy to reduce power consumption.

Case 4 - Standby

● Kill as much backgrounds tasks as possible. Normally there will be much tasks running background or waiting to be resumed. Please kill them if you do not want them to consume power energy when standby. The more applications you installed, the more background services there will be.

● Android provides some options to control the background activities in Settings->Developer options

● power down the deviceThis is the most power saving method, since you are not using the battery. But by doing this you will be not able to receive messages, get in-call, connect to internet and use any function even though use it as a watch. So please consider this way when you are expected not to use it to receive message, receive phone in-call, or not to use it for some expected time.

● battery saving modes

Android provides power saving options in the Advanced Wi-Fi page, like Keep Wi-Fi on during sleep, Scanning always available, Wi-Fi frequency band, Wi-Fi optimization. You can set them according to your usage requirement.

● Bluetooth: turn it off when you know you will not use it.Or only turn it on when you use it.

● This can be done with the Bluetooth Power tool.

● GPS: turn it off when you are in room or office where you can not receive the signal of satellites. Or at least turn it to use the location service from wifi.

● Android provides the options for you on the “Location mode” page.

• LCD brightness strongly influences battery life• there is room to save battery via adjusting the brightness and quality• carefully control the brightness in application

• Adjusting cpu frequency or governor policy to improve battery life• when playing audio/video or graphics applications, the main

processing will be done by DSP/GPU, but the CPU is the highest frequency which costs more power energy.

• we can adjust the cpu frequency and speed or the governor policy for our special product or application to save power energy

• but we need to consider the performance and need find the optimal point.

Conclusion

Following suggestions are collected from internet, these are experience from community. And some of them may be suitable for your product. List them here, hoping it can save you some time when you have similar problems.

● Audio Tunneling to DSP(New feature from KitKat 4.4)○ With tunneling, audio decoding and output effects are off-loaded to the DSP, waking the application processor less

often and using less battery. ○ With audio tunneling, Nexus 5 offers a total off-network audio playback time of up to 60 hours, an increase of over

50% over non-tunneled audio. ○ The downside is that not all chipsets will support the feature, and that the Nexus 5 is currently the only device to

take advantage of it● Sensor batching(New feature from KitKat 4.4)

With sensor batching, Android works with the device hardware to collect and deliver sensor events efficiently in batches, rather than individually as they are detected. This lets the device's application processor remain in a low-power idle state until batches are delivered.

● Networking○ check the network type with ConnectivityManager and TelephonyManager, and only do data update or data sync up

when connected with Wifi or 3G○ use efficient data format and parser, like the utilization of GZIPInputStream

● Carefully to use Wakelocks and make sure to release it when finished the operation, or consider using android:keepScreenOn

● Disable receiver components when no operations, or unregister receivers and listeners when in pause or stop state● Use coarse network location instead of GPS, or even consider using the Passive mode.● Use setInexactRepeating() of AlarmManager to wake up along with everyone else, and not use XXX_WAKEUP type

alarms unless necessary● Monitoring the battery level and charging state to control the operation of application, like the update operation.● Determining and monitoring the docking state and type to decide your application’s update strategy.

Suggestions For Developer

● Develop an application that can collect information as the script and show the data in a timeline based chart to help analyse the system power consumption

● Develop an intelligent policy that run in background to adjust the cpu frequency/brightness/wifi/bluetooth/sdcard accessing/sound and other things from the system level automatically, not just from the cpu level like governor, and try to integrate this policy into the power management framework to have control power consumption. Especially under cases like audio playback or video playback where GPU/DSP is busy but CPU is not busy.

● Check the improvement of autosleep comapred to earlysuspend○ Where did earlysuspend go? by John Stulz

https://plus.google.com/111524780435806926688/posts/RCV8EP3hFEm○ This supports the feasible hardware disable feature, like making the mp3

decoder device suspended before the screen off, this is not possible with the earlysuspend mechanism.

Next Steps

• Power Management from Linux Kernel to Android By Matt Hsu & Jim Huang (jserv) from 0xlab June 19, 2009

• Android Power Management by Jerrin Shaji George• Design and Testing for longer battery life in Android Devices & Applications by

Moe Tanabian• Accurate Online Power Estimation and Automatic Battery Behavior Based

Power Model Generation for Smartphones by {lide,tiwana,zhiyunq,zgw,dickrp,zmao}@umich.edu, leiyang@google.com

References

Q&A

Thanks

More about Linaro Connect: http://connect.linaro.orgMore about Linaro: http://www.linaro.org/about/

More about Linaro engineering: http://www.linaro.org/engineering/Linaro members: www.linaro.org/members