Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Battery-Aware Transformations in Mobile Applications

559da0ff5e64b92aaa5ae354236d1329?s=47 Jürgen Cito
December 16, 2016

Battery-Aware Transformations in Mobile Applications

Slides for the conference talk "Battery-Aware Transformations in Mobile Applications" at the 31st Automated Software Engineering (ASE) Conference in Singapore.

You can find a pre-print of the paper here: http://www.zora.uzh.ch/125315/1/battery-aware-transformation-paper.pdf

559da0ff5e64b92aaa5ae354236d1329?s=128

Jürgen Cito

December 16, 2016
Tweet

More Decks by Jürgen Cito

Other Decks in Research

Transcript

  1. Battery-aware Transformations for Mobile Applications Jürgen Cito, Julia Rubin, Phillip

    Stanley-Marbell, Martin Rinard 31st International Conference on Automated Software Engineering (ASE’16), Singapore Photo Credit: https://flic.kr/p/bXf4vw
  2. Phone batteries die way too soon Photo Credit: John Seb

    Barber, https://flic.kr/p/4KanE4 People do not like ads! Photo Credit: Andrew Mager, https://flic.kr/p/542f5v
  3. Ad Libraries Run in the background as covert communications
 [Rubin

    et al.@ASE15] Need a lot of resources 16-33% energy consumption 
 [Gui et al.@ICSE15, Pathak et al.@EuroSys12]
  4. Goal Maximize Battery Life Minimize Energy Consumption Goal Maximize Revenue

    (Ads) Maximize App Insight (Analytics) Mobile Users Photo Credit “Mobile Users”: https://flic.kr/p/nJMbfu Kyle Spradley Mobile Developers
  5. The main idea behind battery-aware transformation is to automatically identify

    recurrent ad & analytics requests in existing applications, detect their frequency and modify application binaries so that applications can adapt the frequency to the current battery state.
  6. Low Power Mode

  7. Frequency of Recurrent Requests Photo Credit: Ronan, https://flic.kr/p/agHAZE

  8. Battery-aware Transformations
 [Formalization of Recurrent Requests] We allow for a

    bit of wiggle room by modelling a threshold Given a set of positive events a series is recurrent w.r.t. threshold
  9. Frequency of Recurrent Requests
 [Method] Considered Network Connections Instrument binaries

    Using Soot to insert print statement of package/method name of network requests with a timestamp to stdout 1 Run app for 30 minutes Run app on Nexus 4 device connected to WiFi. There is no interaction with the app 2 Manual analysis Extract traces and conduct manual analysis to determine recurrent requests (ground truth) 3
  10. Subject applications [n=8, Top 30, no login, didn’t crash] Amazon

    Shopping VLC Direct The Best Life Quotes Super-Bright LED Flashlight Zedge PowerClean Mp3 Downloader FaceSwap 75% of apps have at least 1 recurrent request 6.25 of requests were identified as ads & analytics 16% of apps that have recurrent requests, have multiple recurrent requests Frequency of Recurrent Requests
 [Results] 1.7 of these requests were recurrent 49.6s is the average interval of recurrent requests
  11. Battery-aware Transformations
 [Overview] Bytecode Instrumentation Run apk' for 30 minutes

    1. Profiling apk File Annotated apk' 2. Frequency Analysis Connection Logs Automated Detection Parameter (period) 3. Battery-Aware Transformation Transformed apk'' A&A Request Rate Throttling Based on f(b, )
  12. Battery-aware Transformations
 [Request Distribution] Deltas Frequency 30.8 31.0 31.2 31.4

    0 10 20
  13. Battery-aware Transformations
 [Automated Detection] Precision: 100% Fraction of connections correctly

    identified as recurrent among 
 those reported by the automated analysis Recall: 80.5% Fraction correctly identified as recurrent from the ground truth set
  14. Battery-aware Transformations
 [Transformation Models] Based on parameters learned (recurrent requests

    + period), add a delay before recurrent requests by instrumenting binaries Linear Adaptation Low Power Mode (at 20% battery status)
  15. Case Study: Energy Savings Energy estimation based on fuel/gas gauge

    of phone In Android: Polling /sys/class/power_supply/battery/uevent Run this process 5 times each (to reduce noise) and compare results Run app before and after transformation for 30 minutes
 Extract data and calculate Average Power Dissipation Case Study App: VLC Direct 5.86% decrease in energy consumption when delaying for 30 seconds (upper bound at ~16%) 1 recurrent request (Google Ads) Original period: 30 seconds
  16. Conclusion 75% of apps have recurrent requests Automatic detection with


    100% precision and 80.5% recall 5.86% energy savings when applying battery-aware transformation (upper bound at ~16%) Inform ecosystem developers to build battery-aware APIs Gamification: “Energy Badges” (given by App stores) Multi-objective Optimization: Finding the Pareto-optimal solution Future Explorations @citostyle Jürgen Cito <cito@ifi.uzh.ch>