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

Battery-Aware Transformations in Mobile Applica...

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

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. 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
  7. 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
  8. 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
  9. 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, )
  10. 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
  11. 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)
  12. 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
  13. 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>