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

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
   

   View Slide

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
   

   View Slide

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]
   

   View Slide

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
   

   View Slide

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.
   

   View Slide

6. Low Power Mode
   

   View Slide

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

   View Slide

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
   

   View Slide

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
   

   View Slide

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
    

    View Slide

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

    View Slide

12. Battery-aware Transformations

    [Request Distribution]
    Deltas
    Frequency
    30.8 31.0 31.2 31.4
    0 10 20
    

    View Slide

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
    

    View Slide

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)
    

    View Slide

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
    

    View Slide

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
    

    View Slide