Learn about energy consumption and battery life on Android devices

Mobile Energy Consumption Frank Maker Eric Jung Yichuan Wang University of California, Davis

Outline • Mobile Platform • Measuring Power / Energy • User Proﬁles (Eric Jung) • Synchronization Manager (Yichuan Wang) • Optimizations • Research • Q&A

Mobile Platform

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

Nexus One BOM * * http://www.isuppli.com/News/Pages/Google-Nexus-One-Carries-$17415-Materials-Cost-iSuppli-Teardown-Reveals.aspx

Apple iPhone

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

Energy Budget [1] Average Battery Size: 820 - 1150 mAh (3.7V) Component Power Consumption Cellular Model and RF Ampliﬁer 1200mW Application Processor 600mW Memories 200mW User Interface 300mW Audio 300mW Other (BT, Energy Manager, etc.) 400mW Total ~3W 8

Measuring Power/Energy

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

Measuring Energy • Use a model • Google using this for Power Android Developer Proﬁler Phone 1 • Battery Simulator • Jeffrey Sharkey used Monsoon GPIB • Digital Power Supply DC Power Supply • Make your own!

User Proﬁles Eric Jung

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 proﬁle), Activity, Time, Location • Programmers should have potential energy use, potential loss of future phone use in mind

User Proﬁles Vary Greatly • Normalized histogram of 53-day call history for 2 users • Usage pattern varies dramatically 5

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

Energy Threshold • For each time t, ﬁnd energy level that satisﬁes 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

Two Example Days • Depending on call day, different actions might be better Light Call Heavy Call

Sample App – Data Synchronization • Created sample app that syncs email/twitter • Goal: Balance need for repeated data synchronizations (email, Twitter) with future energy needs

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

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

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

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

Things To Consider • User Protection • Ensure that phones reserve resources for its primary use • Resource reserves calculated from phone usage proﬁle • App Speciﬁc • Dynamically adjust app processes to user context • What granularity of battery level reserve is needed? • Does app have periodic or one-shot characteristic?

Synchronization Manager Yichuan Wang

Motivation • 'Internet device' • Direct Interaction vs Data Synchronization • Data Synchronization as a system service

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

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);

Traditional ways to do Synchronization (2 of 3) • Handler • private ﬁnal Handler mHandler = new Handler() { public void handleMessage(Message msg) { // Do the deed. // Repeat every 1 second. sendMessageDelayed(obtainMessage (TICK_MSG), 3 * 1000); } };

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"); } }

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

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; conﬁrmCredentials • AuthenticatorActivity: The login Screen

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

Internal • ContentService -> SyncManager • ServiceManager->"Content Manager"

Optimizations

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

Radios[11] • Check if connectivity is available • Reduce data • Tradeoff computation and communication • Bluetooth slow but, low power • Wi-ﬁ fast, but high power • Can use GZip compression

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

Use the Cloud, Luke • More scalable • Ofﬂoads power usage • Might be more efﬁcient • Communication • energy cost could be an issue • RESTful interface

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++

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 ﬁnd best one for you

GPS Acquisition Time

Research

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 ﬁnd people replace about every 4 years • Battery worn out • Want something new

Challenges • ReCellular received 1,100 different handset in 2008 • Heterogeneity • Operating System • Accelerators • Radios • Searching conﬁgurations for optimal energy point to run repurposed phone at

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

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

Thanks Frank Maker ﬂmaker@ece.ucdavis.edu fmaker@handycodeworks.com Eric Jung eajung@ucdavis.edu Yichuan Wang yicwang@ucdavis.edu

Binomial Call Energy Threshold : probability of call arrival based on call proﬁle : 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 :

GPS Power Cycling

Learn about energy consumption and battery life on Android devices

by Marakana Inc. on May 05, 2010

Accessibility

Categories

Tags

Upload Details

Usage Rights

2 Embeds 3

Statistics

Learn about energy consumption and battery life on Android devices — Presentation Transcript

http://www.slideshare.net	2
http://static.slidesharecdn.com	1