San Francisco Android User Group hosted an event on March 30th, 2010 with Frank Maker, Eric Jung, and Yichuan Wang, a trio of very smart PhD students, who shared what they've learned about power consumption / battery life on mobile/Android devices in their years of research. Specifically, they talked about: Mobile Architecture - Talk about differences with desktop/laptop computers, where power goes, etc. Measuring Power/Energy - difference between energy and power, battery technology, why the problem isn't going away anytime soon Software Optimizations - different ideas you can use to lower the power consumption of your application. Hosted by SUPINFO Sponsored by Sun, O'Reilly, and Marakana Organized by Marakana Video by Max Walker Photography by Aleksandar Gargenta
4. How is Mobile Platform
Different?
Mobile8 Laptop9
Main Purpose Phone Calls Anything
Power Budget (Watts) 3 73
Size (cm) 11.9 x 5.98 x 1.15 2.41 x 14.35 x 9.82
Volume (cm3) 81.84 339.61
Cooling Passive Air Forced Air
5. Nexus One BOM *
* http://www.isuppli.com/News/Pages/Google-Nexus-One-Carries-$17415-Materials-Cost-iSuppli-Teardown-Reveals.aspx
7. Battery Technology[3]
• Three main problems
• Limited power density for
passive air cooled systems
• Slow battery energy density
growth
• 30-40% battery lifetime
increase
• Capacity degrades over time
[1] http://www.nexergy.com/
[2] Intel
8. Energy Budget [1]
Average Battery Size: 820 - 1150 mAh (3.7V)
Component Power Consumption
Cellular Model and RF Amplifier 1200mW
Application Processor 600mW
Memories 200mW
User Interface 300mW
Audio 300mW
Other (BT, Energy Manager, etc.) 400mW
Total ~3W
8
10. Power vs Energy
• Energy is power integrated over time
• Electic power is “the rate at which electrical energy is
transferred by an electric circuit”10
• Electric energy is the total amount of work that can
be done by electrons
• Analogy with driving a car
• MPH power
• Distance energy
11. Measuring Energy
• Use a model
• Google using this for Power
Android
Developer
Profiler Phone 1
• Battery Simulator
• Jeffrey Sharkey used Monsoon GPIB
• Digital Power Supply DC Power Supply
• Make your own!
13. User Protection in Mobile
Apps
• Mobile Apps should not drain excessive energy
• Most mobile apps considered “secondary”
• Mobile users want to protect battery life for primary uses
like phone call/sms, although this may change
• User Context should be included in App Design
• User context: Identity (user profile), Activity, Time, Location
• Programmers should have potential energy use, potential
loss of future phone use in mind
14. User Profiles Vary Greatly
• Normalized histogram of 53-day call history for 2 users
• Usage pattern varies dramatically
5
15. Different Ways to Look at
User Profile
• Based on different types of
profile measurements
• Call arrival prob (top)
• Ave remaining minutes
(bottom)
• Data, SMS use not shown
• Use user-profile to predict/
reserve battery energy
16. Energy Threshold
• For each time t, find energy level that satisfies all future
voice with some probability based on history
• Example:
85% Threshold
based on “binomial
call” assumption
• 85% probability that
calls from history
are served
• Measures how much
battery life is
needed
17. Two Example Days
• Depending on call day, different actions might be better
Light Call Heavy Call
18. Sample App – Data
Synchronization
• Created sample app that
syncs email/twitter
• Goal: Balance need for
repeated data
synchronizations (email,
Twitter) with future
energy needs
19. Energy Threshold Policy
• Policy using energy threshold:
1. Calculate remaining_syncs possible at time t:
remaining_syncs = (current battery-energy threshold)/(energy cost to sync)
2. Calculate sync_period given remaining syncs
sync_period = (next_recharge-current time)/remaining_syncs
Policy: If time since last sync > sync_period, synchronize
20. Simulation
• System Parameters:
- 16 hour discharge period (i.e. charge every night)
- Energy to synchronize measured from voltmeter
connected to phone
• Compare Markov Decision Process Policy
(considered optimal) with threshold 85%, periodic
sync policies
21. 20 Min Call Day
• Light Call Day: 20 Minutes
• On a light call day, we want to synchronize email
more often
• Dynamic adjust to
MDP1 85% type1 Period 5 Period 10
sync_both 220 220 191 95
mean_tau1 4.35 4.35 5.02 10.03 call load
dev_tau1 4.18 4.66 0.16 0.23
minutes
t(E=0)
20
960
20
960
20
960 960
20
• Remaining energy
E(T) 0.58 0.58 45.33 193.44 lower for 85%
• Note: 960 = 16 Hours in minutes threshold
• Note 2: Battery is out of 400 (instead of
100) • Syncs More
22. 121 Min Call Day
• Heavy Call Day: 121 Minutes
• On heavy day, we want to synchronize less to
ensure battery life for calls
• Dynamic adjust to
MDP1 85% type1 Period 5 Period 10 call load
sync_both 23 23 99 59
mean_tau1 39.88 41.43 5.54 11.25 • Periodic syncs too
dev_tau1 116.48 119.5 3.25 5.27 much
minutes 121 121 82 102
t(E=0) 960 960 566 668 – Battery dies
E(T) 0.43 1.52 0 0 before end of
day
– Calls not all
served
23. Things To Consider
• User Protection
• Ensure that phones reserve resources for its primary use
• Resource reserves calculated from phone usage profile
• App Specific
• Dynamically adjust app processes to user context
• What granularity of battery level reserve is needed?
• Does app have periodic or one-shot characteristic?
26. Traditional ways to do
Synchronization
• Initial effort: to make adoption as easy as possilbe
• So what are people using to sync?
• Timer
• Handler
• AsyncTask
• Make a optimized version of those APIs
27. Traditional ways to do
Synchronization (1 of 3)
• Periodically wake up
• Pull remote/local changes
• Update local/remote data
• Optionally update UI to notify user
• TimerTask fetchMail = new FetchMail();
//perform the task once a day at 4 a.m.,
//starting tomorrow morning
Timer timer = new Timer();
timer.scheduleAtFixedRate(fetchMail,
getTomorrowMorning4am(), fONCE_PER_DAY);
28. Traditional ways to do
Synchronization (2 of 3)
• Handler
• private final Handler mHandler = new Handler() {
public void handleMessage(Message msg) {
// Do the deed.
// Repeat every 1 second.
sendMessageDelayed(obtainMessage
(TICK_MSG), 3 * 1000);
}
};
29. Traditional ways to do
Synchronization (3 of 3)
• AsyncTask
private class DownTask extends AsyncTask<URL, Integer, Long> {
protected Long doInBackground(URL... urls) {
}
protected void onProgressUpdate(Integer... progress) {
setProgressPercent(progress[0]);
}
protected void onPostExecute(Long result) {
showDialog("Downloaded " + result + " bytes");
}
}
30. New SyncAdapter in
Android 2.0
• Google goes one step further
• A framework for Account, Contact and Sync
management
• The new Account&Sync settings
• A little rough around the edges
31. Authentication
• Starting point: AuthenticationService
• listen for intent: android.accounts.AccountAuthenticator
• meta-data: unique accountType and other resources
• onBind: return Authenticator's binder
• Authenticator: AbstractAccountAuthenticator
• Override methods to provide implementation
• getAuthToken; addAccount; confirmCredentials
• AuthenticatorActivity: The login Screen
32. Synchronization
• Starting point: SyncService
• listen for intent: android.content.SyncAdapter
• meta-data: info about syncAdapter and contact structure
• onBind: return SyncAdapter binder
• SyncAdapter: AbstractThreadedSyncAdapter
• onPerformSync: pull data and update using
ContactContract API
35. Parsers [11]
• Mainly two types
• Tree (ex. DOM)
• Event (ex. SAX)
• Consider how much of the information is used
• Tree pre-parses everything, but is take initial hit
• Event parses as needed, but spread out
36. Radios[11]
• Check if connectivity is available
• Reduce data
• Tradeoff computation and communication
• Bluetooth slow but, low power
• Wi-fi fast, but high power
• Can use GZip compression
37. Wake Locks / Services
• Be conservative
• Give user a choice
• Can keep phone on
longer than necessary • Consider
AlarmManager instead
• Do you really need it?
• setInexactRepeating
• Services should be to allow binning
short not daemons
38. Use the Cloud, Luke
• More scalable
• Offloads power usage
• Might be more efficient
• Communication
• energy cost could be an issue
• RESTful interface
39. Profiling
• Hit the big targets first • Traceviewer
• Consider native code • Recycle Java objects
• floating point • Hierarchyviewer
• matrices • Decrease height of
view hierarchy
• long loops
• Think like C++
40. Sensors
• Different rates available
• UI, Gaming, Normal, etc
• Almost 10x difference from Fastest and Slowest
• GPS
• Coarse location much cheaper (10x less)
• No satellites, LocationManager keeps looking
• Let LocationManager find best one for you
43. Motivation
• Industry collects est. 13 million phones each year
• Estimated to be only 10% of 130 million taken out of
service
• ReCellular found 80% were still functional
• Surveys find people replace about every 4 years
• Battery worn out
• Want something new
44. Challenges
• ReCellular received 1,100 different handset in 2008
• Heterogeneity
• Operating System
• Accelerators
• Radios
• Searching configurations for optimal energy point to
run repurposed phone at
45. Solution(s)
• Artificial Intelligence to find best operating point
• Solar panel power supply to remove worn battery
• Use offline Markov Decision Process to find optimal
point
46. References
1. Cellular Phones as Embedded Systems, Yrjö Neuvo, International Solid-State Circuits Conference
2004
2. Augmented Smartphone Applications Through Clone Cloud Execution
3. UC Davis EEC216 - Professor Rajaveen Amirtharajah
4. Powermonkey-eXplorer, https://powertraveller.com/iwantsome/primatepower/powermonkey-explorer/
5. Lumedyne V-Power Energy Harvester Technology, http://www.lumedynetechnologies.com/Energy
%20Harvester.html
6. Thermo Life, http://www.poweredbythermolife.com/thermolife.htm
7. Geared Turbine, http://www.kidwind.org/xcart/product.php?productid=42&cat=4&page=1
8. http://www.google.com/phone/static/en_US-nexusone_tech_specs.html
9. http://www.apple.com/macbookpro/specs.html
10. http://en.wikipedia.org/wiki/Electric_power
11. http://dl.google.com/io/2009/pres/W_0300_CodingforLife-BatteryLifeThatIs.pdf
12. http://www.recellular.com/images/ReCel_Sustainability.pdf
46
47. Thanks
Frank Maker
flmaker@ece.ucdavis.edu
fmaker@handycodeworks.com
Eric Jung
eajung@ucdavis.edu
Yichuan Wang
yicwang@ucdavis.edu
48. Binomial Call Energy
Threshold
: probability of call arrival based on call profile
: random variable denoting call arrival at time t
• Assume each call minute is a binomial variable with
probability
: CDF of remaining call time after time t
• Energy threshold :
