$30 off During Our Annual Pro Sale. View Details »

Battery-Aware Transformations in Mobile Applications

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

More Decks by Jürgen Cito

Other Decks in Research


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

    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
    Manual analysis
    Extract traces and conduct
    manual analysis to determine
    recurrent requests (ground truth)

    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
    Mp3 Downloader
    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
    Frequency of Recurrent Requests

    1.7 of these requests
    were recurrent
    49.6s is the average
    interval of recurrent requests

    View Slide

  11. Battery-aware Transformations

    apk' for 30
    1. Profiling
    apk File
    2. Frequency Analysis
    Automated Detection
    3. Battery-Aware Transformation
    A&A Request Rate Throttling
    Based on f(b, )

    View Slide

  12. Battery-aware Transformations

    [Request Distribution]
    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
    Jürgen Cito

    View Slide