Resource: LCA14 Name: LCA14-507: Improving Android Battery Life Date: 07-03-2014 Speaker: Yongqin Liu Video: https://www.youtube.com/watch?v=aqqDHSheuaI Website: http://www.linaro.org/ Linaro Connect: http://connect.linaro.org/ Slide: https://www.slideshare.net/linaroorg/lca14-507-improvingandroidbatterylife

1. Yongqin Liu, LCA14, Macau
Improving Android Battery Life

2. 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

3. 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 voltage
Ri : internal resistance
Cl : load capacitance
Rl : load resistance
I: 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

4. 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

5. 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.

6. 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

7. Tools for Analysis
● PowerTutor
PowerTutor 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/
● BatteryMix
Really 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

8. Use Cases Analyzed

9. 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

10. 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.

11. 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.

12. 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 device
This 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.

13. • 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

14. 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

15. ● 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

16. • 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

17. Q&A
Thanks

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