Selectively Taming Background Android Apps to Improve Battery

This paper is included in the Proceedings of the

2015 USENIX Annual Technical Conference (USENIC ATC ’15).

July 8–10, 2015 • Santa Clara, CA, USA

ISBN 978-1-931971-225

Open access to the Proceedings of the

2015 USENIX Annual Technical Conference

(USENIX ATC ’15) is sponsored by USENIX.

Selectively Taming Background Android Apps

to Improve Battery Lifetime

Marcelo Martins, Brown University; Justin Cappos, New York University;

Rodrigo Fonseca, Brown University

ht t ps://www.use nix.org/confere nce/atc15/technical-session/presentation/martins

USENIX Association 2015 USENIX Annual Technical Conference 563

Selectively Taming Background Android Apps to Improve Battery Lifetime

Marcelo Martins

Brown University

Justin Cappos

New York University

Rodrigo Fonseca

Brown University

Abstract

Background activities on mobile devices can cause signi-

cant battery drain with little visibility or recourse to the

user. ey c an range from useful but sometimes overly ag-

gressive tasks, such as polling for messages or updates from

sensors and online services, to outright bugs that c ause

resources to be held unnecess arily. In this paper we instru-

ment the Android OS to characterize background activities

that prevent the device from sleeping. We present Tamer,

an OS mechanism that interposes on events and signals

that cause task wakeups, and allows for their detailed mon-

itoring, ltering, and rate-limiting. We demonstrate how

Tamer can help reduce battery drain in scenarios involv-

ing popular Android apps with background tasks. We also

show how Tamer can mitigate the eects of well-known

energy bugs while maintaining most of the apps’ function-

ality. Finally, we elaborate on how developers and users can

devise their own application-control policies for Tamer

to maximize battery lifetime.

1 Introduction

e accelerated growth of sensing, computational, stor-

age, and communication capabilities of mobile devices

has enabled a rich applicat ion environment that rivals the

performance of desktop computers. Even s o, battery tech-

nology has not followed the same advancement pace and

there is little evidence that this situation will dramatically

improve. As a result, battery lifetime has become a major

usability concern, with users w illing to enjoy the latest

apps on their smartphones and tablets, but, at the same

time, worrying that their battery will not last long enough.

Since the inception of mobile computing, both indus-

try and academia have developed a sle w of techniques to

reduce power at the architecture [

], OS [

] and

application levels [

], and today’s systems draw little

power while idling. Due to its user-centric and interac-

tivenature,theowofamobileapplicationisdrivenby

events such as user ac tions, sensor I/O, and message ex-

changes. Such event-driven paradigm lets the system idle

until a new event arrives. Mobile OSes, such as Android,

iOS, and Windows Phone, take advantage of such idling

opportunities to engage in opportunistic sus pend. Upon

brief perio ds of idling, the handheld switches to the default

suspend state. Hardware blocks, including the CPU, GPU,

GPS, and network modem, shi to low-power mode and

soware state is kept in self-refreshing RAM. e same

blocks return from suspension upon interrupts emitted by

hardware or soware indicating that they have pending re-

quests. With the rise of multitasking and the multiplication

of background services and complex mobile applications,

we expect this amount of interrupts to increase, forcing

the system to spend more time active to attend requests.

Such active periods take a toll on b attery lifetime. A recent

study by Google clearly shows this impact: each second of

active use of a typical phone reduces the standby time by

two minutes [18].

is paper studies the problem of battery drain mostly

due to app-originated background operations that wake up

the mobile system. We present Tamer, an OS mechanism

we built for Android that interposes on events and signals

responsible for task wakeups – alarms, wakelocks, broad-

cast receivers, and service invocations. Like a number of

proling tools, Tamer allows us to characterize the back-

ground behavior of dierent apps installed on a device. In

§2, using Tamer’s instrumentation, we show how a set of

installed applications can dramatically aect the battery

lifetime of four dierent devices. Unlike existing proling

tools, however, Tamer canalsoselectivelyblockorrate-

limit the handling of such events and signals following

exible policies. In this way, Tamer can, for example, limit

the frequency at which an application schedules alarms or

receives notications of specied events, providing ne-

grained control over t he energy usage of apps that may be

useful, but are irresponsible or inecient with respect to

their background activities. In §5.2 we show via a few case

studies how Tamer can reduce the energy consumed by

energy bugs [

] in legitimate apps. We summarize our

contributions as follows:

•

We characterize how applications and core comp o-

nents of the Android OS use specic features to en-

able background computing, and how this computing

signicantly aects energy use. In special, we note

that Go ogle Mobile S ervices play a major role on

battery drain while the device is dormant (§2).

•

We introduce Tamer, an OS mechanism to control

the frequency at which background tasks are handled,

thereby limiting their impact on energy consumption

(§4). Tamer leverages code-injection technology and

is applicable to any Java-based Android application.

•

We demonstrate how Tamer can successful ly throt-

tle the background behavior of popular applications,

thus reducing their energy footprint (§5). We show

564 2015 USENIX Annual Technical Conference USENIX Association

how dierent policies reduce power draw in exchange

for little to no impact on functionality.

Despite being a powerful mechanism, Tamer isonlya

step towards eective control of background energy usage.

In particular, there are still challenges in helping users

dene policies that are eective, yet not disruptive to the

user experience. We discuss such challenges in §7.

2 Motivation

Smartphone and tablet users are used to being always con-

nected, expecting immediate notications of a new e-mail

or application update. Other common background oper-

ations include polling navigational sensors for location

clues and turning on the network radio for incoming mes-

sages. Especially in Android, where there is little restriction

on what apps can do in the background and de veloper’s

discipline is t he main factor prevent ing inecient applica-

tions, apps can hog resources and waste energy.

Traditionally there has been little visibility, both to app

developers and to users, on the contribution of individual

apps to energy use, especially w hile in the background. It is

even harder to know whether an app is actually running or

idling. Recent monitoring and proling tools have helped

bridge this visibility gap [

],asone

cannot optimize what cannot be measured.

Today’s average handheld contains a large amount of

third-party soware. A 2013 survey shows a global average

of 26 apps installed on a mobile device [

].Evenwiththe

best currently available tools, the end user can do little to

cope with inecient apps. Most of the tools above target

developers and provide little help for the user. Even the

friendlier ones, such as eStar [

]andCarat[

], when

highlighting energy-inecient programs, can only oer to

kill or uninstall the culprit app, perhaps suggesting replace-

ments. Unfortunately, this is too coarse-grained a solution

and some apps with irreplaceable functionality become an

inconvenience one has to live with.

Tamer oers the possibility of much ner-grained con-

trol once an energ y hog or bug is found. It provides infor-

mation on which tasks are expending the most energy and

can rate-limit their execution. Tamer detects most causes

of device wakeup that are visible at the framework level of

Android, and can lter their continuation in real time.

To demonstrate the signicant dierence that a set of

running tasks can make in a device’s battery life, we mea-

sured the battery drop of four Android devices (two smart-

phones and two tablets, cf. Table 1) running two dierent

application sets, while idling and with the screen o. Con-

servatively, we consider three scenarios: the rst testing

environment (Pure AOSP) consists of a stripped version of

the Android Open Source Project (AOSP) OS containing

a minimum number of services and apps; the s econd one

adds Google Mobi le Services (GMS) on top of Pure AOSP.

GMS consists of proprietary applications and services de-

veloped by Google, such as Calendar, Google+ (social me-

dia), Google Now (personal assistant), Hangouts (instant

messaging), Maps, Photos, Play Service (integrating API),

PlayStore,andSearch.Duetotheirpopularityandadded

value, GMS apps are included in most Android devices

sold today. For the third scenario, which we only ran on

the Galax y Nexus phone, we also inst alled the ten most

popularfreeappsofGoogle’sPlayStoreasofJanuary2015

We based all environments on the KitKat (4.4) version of

Android. For the experiments, we le each device unat-

tended running with its conguration at default settings.

Other relevant s ettings include connection to a WiFi ac-

cess point, enabled location-reporting, and background

network synchronization. We expect most of the battery

drainage to stem from static-voltage le akage and eventual

background processing.

Figure 1 shows the time taken by each environment-

device combination to deplete the battery. For all devices,

Pure AOSP took the longest to completely drain the battery.

In the case of tablets, this dierence spanned dozens of

hours. To investigate why this happened, we instr umented

the Android soware stack to timestamp the occurrence

of background events. Additionally, we connected one of

our devices (Galaxy Nexus) to a Monsoon power moni-

tor [

] and collec ted power traces from the battery. Finally,

we aligned and synchronized both the event and power

timelines to understand their correlation. Figure 2 depicts

a six-minute slice of this combination. We observe that

GMS triggers more events in the background and that they

arecorrelatedwiththesurgeofpowerpeaks.Weusedthis

tracing knowledge to build a mechanism that counters the

energy eect due to excessive wakeups. Because this mech-

anism relies on OS internals, we rst need to understand

how an Android app functions while in the background.

3 Background

is section provides a concise description of Android’s

power-management system followed by an overview of

the components constituting a mobile app and how appli-

cations behave while running in the background. Finally,

we highlight the inuence of b ackground execution on bat-

tery drain using four types of events: wakelocks, services,

broadcast receivers, and alarms. §4 describes Tamer, our

control system that adjusts the frequency at which such

events occur.

3.1 Mobile Power Management

Android employs an aggressive form of power manage-

ment to extend battery life. By default, the entire system

suspends itself, sometimes even when there are processes

running. Opportunistic suspend is eective in prevent-

ing programs from keeping the system awake and quickly

Crossy Road, Candy Crush Soda Saga, Pandora Radio, Trivia Crack,

Snapchat, Facebook Messenger, Facebook, 360 Security Antivirus, Insta-

gram and Super-Bright LED Flashlight.

USENIX Association 2015 USENIX Annual Technical Conference 565

Device Name Device Type Processor Features

Google Galaxy Nexus Smartphone Dual-core 1.2GHz ARM Cortex-A9 WiFi, GPS+A-GPS, 3G

Samsung Galaxy S4 Smartphone Quad-core 1.9GHz Qualcomm Krait 300 WiFi, GPS+A-GPS, 3G/LTE

Amazon Kindle Fire 2 Tablet Dual-core 1.2GHz ARM Cortex-A9 WiFi

ASUS MeMO Pad 7 (ME176C) Tablet Quad-core 1.83GHz Intel Atom Z3560 WiFi, GPS+A-GPS

Table 1: List of devices used for battery-drop monitoring.

100

0 20 40 60 80 100 120 140

Battery Level (%)

Hours

Pure AOSP

w/ Google M. Services

w/ GMS + Top10

(a) Galaxy Nexus

100

0 20 40 60 80 100 120 140 160

Battery Level (%)

Hours

Pure AOSP

w/ Google M. Services

(b) Galaxy S4

100

0 50 100 150 200 250 300 350

Battery Level (%)

Hours

Pure AOSP

w/ Google M. Services

100

0 50 100 150 200 250

Battery Level (%)

Hours

Pure AOSP

w/ Google M. Services

(d) MeMO Pad 7

Figure 1: Battery drop of four Android devices idling with the screen o. With G oogle Mobile Services installed, battery life decreased

to 29.5% (Fire 2) and 77.5% (MeMO Pad 7) of its initial decay (without GMS).

0 50 100 150 200 250 300 350

AlarmManager

Power (W)

Timeline (s)

(a) Pure AOSP

0 50 100 150 200 250 300 350

NlpLocationReceiverService

PendingIntentCallbackService

UlrDispatchingService

NlpWakeLock

NlpCollectorWakeLock

GeofencerStateMachine

GCoreFlp

NetworkLocationService

AlarmManager

Power (W)

Timeline (s)

(b) Pure AOSP + GMS

Figure 2: Six minutes sampled from measurements on the Galaxy

Nexus for two scenarios. For each graph, the top stack shows

dierent event occurrences over time. e bottom curve depicts

the corresponding system’s power draw during the same period.

draining the battery. To curb system suspension, Android

uses

Wakelocks

to keep the system awake. Wakelocks are

reference-counted objects, similar to concurrency locks,

that can be acquired/released by kernel and privileged

userspace code. A wakelock acquire expresses a process’s

need for the system to remain awake until run completion.

A wakelock acquire either holds a resource awake until a

release call occ urs or sets up a timer to relinquish the lock

atalatertime.

Kernel drivers use wakelocks to block the suspension of

dierent system components (e.g., CPU, network, screen),

whereas the Android application framework leverages

wakelocks for dierent levels of suspension, represented

by groups of components (e.g., keep the network radio

awake vs. keep the radio, screen, and CPU awake). As

an example of suspend-blocking by the OS, Android au-

tomatically acquires a wakelock as soon as it is notied

ofaninputeventandonlyreleasesthewakelockonce

some application handles the event or there is a timeout.

Application developers can also directly instantiate and

manipulate wakelocks using the Wakelock API. A proper

e-book reader app must acquire a wakelock to keep the

screen awake so that the user can read her favorite novel

without interruption. Wakelocks play an important role

in gu aranteeing proper background task execution in face

of default suspension, as we will see next.

3.2 Android Applic ations: Dealing with

Lifecycle Changes

Barring a few interface-less system processes, an Android

application consists of a set of

Activities

that places

the UI widgets on the screen. An application starts with

a single thread of execution attached to the foreground

UI, which is mostly responsible for dispatching interface

events. To avoid app unresponsiveness and user frustration,

a wise programmer would move other computations to

concurrent worker threads while the UI responds to input

events. Support for concurrency comes in the form of a

number of standard Java primitives, such as

Threads

and

Futures

,aswellasAndroid’sownavors:

AsyncTasks

and message

Handlers

. However, such primitives only

workwhentheapplicationisintheactive state.

As the user navigates through, out of, and back to an

application, its lifecycle transitions between dierent states

according to activity visibility. An application is active if

one of its activities receives user focus in the foreground. If

the user switches to another app or decides to turn o the

screen, the application is paused and moved to the back-

ground. Because mobile apps are multitasked, developers

must have a way to run code even when their app is not

occupying the screen.

566 2015 USENIX Annual Technical Conference USENIX Association

3.2.1 Dispatching Background Tasks

e small screen size of a smartphone or tablet prevents

multiple applications from running simultaneously. To

conserve energy, apps are frozen and stop working once

sent to the background, either due to the opening of an-

other application or a screen timeout. Context switching

opens room for opportunistic suspend – by making apps

invisible, the Android OS frees its own set of wakelocks,

opening space for hardware throttling.

Android oers application developers a small and well-

dened interface for background-task ooading that takes

careofschedulinglatenttasks[

]. is interface compr ises

a handful of components including services, broadcast

receivers, and alarms. e internal implementation of such

components also leverages wakelocks to keep the device

awake while executing tasks.

Services

are application components that run asyn-

chronously on background threads or processes and do

not directly interact with the user. Instead,

Activities

dispatch services to perform long-duration operations or

to access resources on behalf of users, such as download-

ing remote les or synchronizing data with a cloud-based

storage. An advantage of running services separately is that

their running persists even aer closing the owner’s inter-

face. Apps and widgets rely on services being operational

withoutneedofmanualrestart.

BroadcastReceiver

isareactivemechanismthatper-

mits programs to asynchronously respond to specied

events. An application registers a

BroadcastReceiver

along with an event-subscription list – the

IntentFilter

– that is used to determine if the application is eligible to

respond to a given event. Events can be predened by the

system (e.g., “battery fully charged”) or developer-dened

(e.g., “backup nished”). Receiver threads remain dormant

until a matched event arrives and respond by running a

callback function. A le-hosting app could, for instance,

covers that a s cheduled data synchronization has nished.

Another common programming pattern is the ability to

perform time-based operations outside the lifetime of an

application. For instance, checking for incoming e-mails

every so oen is a recurrent user operation that could

be automatized. e Android SDK oers developers the

AlarmManager

mechanism to fulll the scheduling of pe-

riodic tasks at set points. At each alarm trigger, the system

wakes up and executes the scheduled callback function,

whose contents can take various forms: a UI update, a ser-

vice call, an I/O operation, scheduling a new alarm, etc.

Alarmsareagoodtforopportunisticsuspend:appsare

onlyactivatedwhenthereisworktodo.

In summary, Android uses at least three types of asyn-

chronous mechanisms to perform background tasking:

services, broadcast receivers, and alarms. Aligned with

wakelocks, we have a powerful collection of events that can

keep the system awake. In the next section, we introduce

Tamer, a system that acts on this small and well-dened

interface to throttle the rate at which background events

are handled in exchange for energy savings.

4 Tamer

4.1 Design

Having seen that background events can noteworthily af-

fect the sleeping pattern of mobile devices, we consider

the possibility of regulating their frequency to improve

battery life. We introduce a conguration mechanism for

declaring thresholds to the frequency of these events. We

model this regulat ion process using three sequential steps:

(1) observation; (2) comparison; and (3) action.

Event-frequency regulation works based on the speci-

cation of occurrence limits. We establish a policy mecha-

nism that lets users dene how oen the running system

should per mit a given background event to proceed. A pol-

icy is a contract that declares the conditions for an event ex-

ecution. is contract species the event type as well as its

identier; an optional list of aected apps, in case we want

to restrict such enforcement to a subset of event dispatch-

ers or receivers; whether the policy enforcement also takes

place when the event owner (app) is in the foreground; and

therateatwhichtheyareallowedtoexecute.Fromthis

denition, an energy-savvy user could program her smart-

phonetopermitcallsto

WeatherUpdateService

from a

weather-forecast app at most once every six hours, whereas

calls to

LocationUpdateService

fromthesameapp

would remain unlimited.

To enforce user-dened policies, we outline a controller

comprising three agents: observer, arbiter and actuator.

e obser ver intercepts every event occurrence and book-

keeps its frequency. e arbite r veries whether the mea-

sured event rate is above the policy-dened threshold, if it

exists, and noties the actuator, which hijacks the event

continuation to articially reduce its occurrence rate. Fig-

ure 3 illustrates our control sequence.

Observer Arbiter

Actuator

Event rate

Policy

Decision

Event Action

Figure 3: Sketch of our event-control system as a three-stage

pipeline.

ere are two ways to fulll event throttling: canceling

or delaying. An event cancel denies the continuation of its

call,withanearlyreturnthatpreventsthepayloadorthe

event callback from running. An event delay, on the other

hand,postponesthecontinuationoftheeventcallfora

limited time. In this work, we opt for canceling the event

handling. We discuss the pros and cons of each choice

in §7.Itisimportanttounderstandthataneventcancel

USENIX Association 2015 USENIX Annual Technical Conference 567

does not result in a crash. Alarms, services and broadcast

receivers all run asynchronously. Wakelock requests, on

the other hand, are synchronous and their denial will result

in a sleeping system when a waiting task is expected to run.

Still,thetaskisneveraborted,butrunsinchunkswhen

the system wakes up. Our method prevents the triggering

of unwanted events. When it is not possible, we abort the

event continuation at the earliest opportunity to reduce the

energy cost of the e vent payload.

To drive the implementation of our system, we establish

a few requisites and considerations:

Comprehensive support for events.

e control system

should be inclusive. While app-specic solutions are eec-

tive, they do not scale to other programs. e stage pipeline

should monitor and, if necessary, actuate on every event

instance. Particulars about a specied event should be con-

ned to its policy and not aect the controller. It is the

responsibility of the policy designer to dene a sane event

frequency, considering, perhaps, the context and the im-

pact of an event hijack. To implement an all-encompassing

monitor system, we target an OS-level solution.

Support for power-oblivious applications.

Users shoul d

not abstain from using their favorite apps even if they are

power hogs. Uninstal ling or suggesting alternative apps

for the same purp ose should not be acceptable. e system

should cope with the existence of ill-behaved apps and act

upon their misbehavior if directed by the policy designer.

Compatibility.

Many solutions that rely on deep sys-

tem introspection require extensive rewr ites of system

components [

] or even wr iting systems from

scr atch [

]. Although tempting, stray ing from the main-

line can severely limit the userbase, espe cially in the case of

consumer-oriented OSes. With that in mind, our solution

should exhibit high compatibility and keep a minimum

amount of changes to the underlying OS.

Eciency.

Mobile apps must cope with limited computa-

tional and energy resources. e control system should

avoid high computational overhead to prevent high battery

drain and system slowdown.

4.2 Implementation

To avoid reimplementing OS components to regulate event

handling, Tamer uses the Xposed framework [

] to en-

able system modications at runtime.

While requiring the device to be rooted, Xposed enables

deep system modications with no need to decompile ap-

plications nor ash the device

. Xpos ed intercepts Java

methods and temporarily diverts the execution ow to

function-hook callbacks for inspection and modication.

Developers dene these callbacks and compile them as sep-

arate modules. Function-call hooking happens by match-

ingthemethod’snameandsignatureofthedeclaredcall-

For brevity reasons, we refer readers to [41]foranexplanationonhow

such thing is p ossible.

back with the running code. Callb acks run on the context

of the intercepted application. Xposed allows for changing

the parameters of a method call, modifying its return value

or terminating it early. We leverage the hooking mecha-

nism to intercept function calls originating from or di-

rected at our events of interest. Finally, function hooks can

be distributed as separate programs in self-contained APK

les. ey are not bound to a specic Android version and

work wit hout changes on the majority of customized An-

droid releases, including those from Samsung, HTC, Sony,

LG, and the CyanogenMod open-source community [

Figure 4 shows how Tamer relates to the Android OS.

Tamer sits, along with Xposed, between user applications

and the Java-based application framework, which serves

as the foundation for the Android SDK. Events have direc-

tions, which helps us dene how to write the interception

payload. While service and wakelock calls originate from

appsandareforwardedtotheframework,alarmsand

broadcast receivers work in the opposite direction.

Tamer consists of a series of function hooks that inter-

pose on the background-processing interface and act as

a controller mechanism to enforce user-dened policies.

To implement Tamer’s event-canceling mechanism, we

leverage Xposed’s introspection API to explore, monitor,

intercept and modify public and pr ivate classes, methods

and members of the framework (Table 2). We used our

knowledge on the Android SDK aligned with t he source

code of Android’s framework stack to decide where to

place the instrumentation points that would constitute

our controller. We analyzed the source code stemming

from each event call on the SDK’s public interface. Model-

ing the relationships between subroutines as a call graph,

we considered each interface function as a leaf node. In

some occasions, we had to backtrack the call graph to nd

a proper instrumentation point. is was necessary for

three reasons: (1) the public interface did not oer enough

context to feed our monitoring system (e.g., missing re-

ceiver name, unclear caller-callee relationship, etc.); (2) in

the case of receiving events, it was better to interpose on a

call as early as possible to avoid unnecessary operat ions

beforeacancellation;(3)aneventcallmayhavemorethan

one function signature, therefore we lo oked for a converg-

ing function node. We found one exception to the last rule

when handling broadcast receivers. Applications can de-

clare receivers in two ways: statically via a

Manifest

le

or dynamically using the Android SDK API. Since the An-

droid framework keeps separate dat a structures for each

case, we had to instrument them separately.

Tamer’s interception can suppress wakeups due to ser-

vice invocations, wakelock acquires, and intent broadcasts.

Because of the way Android handles alarms, our imple-

mentation can only curtail the alarm’s callback payload.

e system will still periodically wake up according to the

alarm’s schedule, but will immediately return to sleep. Our

568 2015 USENIX Annual Technical Conference USENIX Association

Event Class Method

Instrumentation Payload

Wake l o c k com.android.server.PowerManagerService

acquireWakeLockInternal

Searchforpolicy.Iffound,earlyreturn

in case call happens before grace

period. Else, let acquire proceed;

bo okkeep w akelock and start

grace-period timer.

releaseWakeLockInternal

Only called if there was no block;

report how long wakelock was held.

Service com.android.server.am.ActivityManagerService startServiceLocked

Searchforactivepolicy.Proceedasin

wakelock case.

BroadcastReceiver

android.app.ContextImpl

registerReceiverInternal

Add reference to API-registered

receiver.

unregisterReceiverInternal

Remove reference to API-registered

receiver.

com.android.server.pm.PackageManagerService

addActivity

Add reference to receiver registered

statically.

removeActivity

Remove reference to receiver

unregistered statically.

com.android.server.am.ActivityManagerService broadcastIntentLocked

Search for active policy. Temporarily

remove receiver from framework index

to prevent event broadcasts. Update

stats.

Alarm com.android.server.AlarmManagerService triggerAlarmsLocked

Searchforactivepolicy.Proceedasin

wakelock case.

GPS (See §5.3)

android.location.LocationRequest

requestLocationUpdates

Enable GPS throttling for calling app.

removeUpdate

Disable GPS throttling for calling app.

com.android.server.LocationManagerService reportLocation

Search for active policy. Let callback

report incoming location, but

temporarily switch off GPS sensor for

blocking period.

Table 2: A brief description of Tamer’s instrumentation points.

controller implementat ion covers all versions of Android

ranging from Ice Cream Sandwich to KitKat

.Inahand-

ful of occasions, we resorted to dierent instrumentation

points for a given event, mostly due to sma ll dierences

in the function signatures between OS versions. Because

the framework interface is fairly stable, covering future

versions of Android should not require major changes.

Libraries

Application Framework

Android Runtime

Kernel

Tamer

Wakelock

Service

Intent

Alarm

Figure 4: Tamer sits between apps and the framework stack and

interposes on events between these two. Lower system layers are

oblivious to our system.

5 Evaluation

We eva lu ate Tamer in four ways. First, we revisit our moti-

vating scenario (§2)anduseTamer to extend the battery

This limitation is due to Xposed’s limited OS support. Support for

Android’s latest release (Lollipop) is not stable enough to cover our needs.

life of the GMS-based installation. We then investigate

how Tamer can eectively mitigate energ y bugs, a sys-

tem behavior that causes unexpected heavy use of energy

not intrinsic to the desired functionality of an applica-

tion. Next, we show how to use code injection to create

specialized versions of cont rollers for situations that our

four-event toolset cannot handle. Last, we measure the

overhead caused by Tamer on performance and energy.

5.1 Dealing With Google Mobile Ser vices

In §2, we saw how the inclusion of GMS into the baseline

AOSP signicantly reduced the battery life of all tested

devices. Nonetheless, GMS adds a series of services and

applications that truly enhance the user’s mobile experi-

ence. In fact, most users do not even have the option of

uninstalling them, as GMS comes pre-installed as a sys-

tem package in the majority of handhelds. We show how

Tamer can reach a tradeo between GMS’s functionality

and battery savings. We aim to keep the added value of

GMS without the cost of a silent battery depletion.

Event Name Type Count Duration (s)

NlpWakelock W 5963 1662.71

NlpCollectorWakelock W 2121 3926.63

LocationManagerService W 2030 67.12

NlpLocationReceiverService S 1159 -

NetworkLocationService S 579 -

Table 3: Top event occurrences for the Galaxy Nexus’ battery

drain due to GMS. A handful of events are responsible for the ma-

jor impact on the battery. W signies a wakelock event, whereas

S stands for service invocation.

With the control mechanism established, our next

USENIX Association 2015 USENIX Annual Technical Conference 569

100

0 20 40 60 80 100 120 140

Battery Level (%)

Hours

Pure AOSP

w/ Google M. Services

w/ GMS + Tamer-15

w/ GMS + Tamer-45

(a) Galaxy Nexus

100

0 20 40 60 80 100 120 140 160

Battery Level (%)

Hours

Pure AOSP

w/ Google M. Services

w/ GMS + Tamer-15

w/ GMS + Tamer-45

(b) Galaxy S4

100

0 50 100 150 200 250 300 350

Battery Level (%)

Hours

Pure AOSP

w/ Google M. Services

w/ GMS + Tamer-15

w/ GMS + Tamer-45

100

0 50 100 150 200 250

Battery Level (%)

Hours

Pure AOSP

w/ Google M. Services

w/ GMS + Tamer-15

w/ GMS + Tamer-45

(d) MeMO Pad 7

Figure 5: Battery drop for the four devices while idling with the s creen o. Aer applying our policies to GMS, battery life improved

in dozens of hours for all devices.

step is to design a policy that reduces the battery im-

pact of events originating from or destined to GMS. Ta-

ble 3 ranks the top triggered events reported by Tamer’s

monitoring module. For wakelocks, we also report the

time they were held. We use event frequency as an

heuristic to guide policy conguration. We note that

NlpCollectorWakelock

was primarily responsible for

keeping the system awake in the background. Online re-

ports [

] indicate that

NlpCollectorWakelock

is re-

lated to

Location Reporting

, an Android feature to

estimate and report the current location based on WiFi

APs and cell-tower signals. Apps that use this feature in-

clude Google Now and Google Maps, among others. e

other frequently reported events are also related to the

same feature. Disabling location reporting on the device’s

Settings menu would be a logic solution to increase sleep

time, if dependent apps did not stop working.

e problem with

NlpCollectorWakelock

and asso-

ciated events is the frequency they wake up the system and

keep it awake, which sums to a substantial period of non-

sleepiness. During a discharge period of 80 hours for the

Galaxy Nexus smartphone,

NlpWakelock

was called once

a minute on average, whereas

NlpCollectorWakelock

contributed to keeping the system awake for more than

one hour. Such a high battery impact coming from a single

package does not justify the benet of having GMS run-

ning as it is in the background. For this reason, we devised

two policies for GMS, targeting

NlpCollectorWakelock

and its associated events, to alleviate this wakeup burden.

For each wakelock and service in Table

,therstpol-

icy (Tamer-15) allows a single call every 15 minutes. e

second policy (Tamer-45) allows one call every 45 min-

utes. Deciding on an appropriate rate is a subjective matter.

Our setup tries to reach a balance b etween informing sub-

ordinate apps of location updates and increasing battery

lifetime. Figure 5 shows that our policies substantially re-

duced the battery-drain rate of all tested devices.

5.2 Chasing Energy Bugs

An energy bug, or ebug, is a system error either in an

application, OS, rmware or hardware that causes an un-

expected amount of high energy consumption [

]. Such

errors occur due to a variety of reasons such as program-

ming mistakes, faulty hardware, malicious intent, etc. Be-

causesucherrorsmaynotresultinacrash,userswillonly

notice their eect when it is too late: an early dead battery.

Dierently from previous research which identied and

characterized energy bugs [

], in our evaluation we

focus on mitigating them at runtime. Tamer a llows users

to run the oending applications without the adverse ef-

fects of the bugs. Finding ebugs is not trivial and the lack

of a centralized repository of updated samples prevents

us from testing our controller more extensively. We suc-

cessfully reproduced and circumvented three application

ebugs describ ed in [

]. For the other described cases, we

could not conrm the existence of bugs. We assume these

defects have been xed by developer updates.

Next, we present two detailed case studies of new ebugs

that we found. To identify them, we used eStar [

], a tool

that ranks the contribution of apps to battery depletion. We

rst selected apps that display poor energy eciency and

ltered them based on high popularity at the Google Play

Store (our t wo selections featured on the top-20 ranking of

their respect ive categories: Games and Health & Fitness).

Although eStar ranks energy-inecient apps, we still had

to manually verify whether such ineciency was due to

foreground or background activity. For each application,

we simulated a user interaction consisting of a short-length

active session followed by a long period in the background.

Bejeweled Blitz

[

] is an award-winning puzzle game

with over 10 million installs from Google Play Store. Aer

a 15-minute play session on the Gal axy S4 smartphone,

Tamer reported that our game generated a single back-

ground event – the acquire of the

AudioIn

wakelock. Be-

cause games are resource-hungry apps, this event call ini-

tially did not instigate any suspicion. We discovered a red

ag, though, aer switching Bejeweled to the background:

AudioIn

was not released aer t he game suspension. To

mitigate this bug, we wrote a simple policy targeting Bejew-

eled Blitz that blocks the renewal of the culprit wakelock

during background time. Figure 6 depicts the b attery drop

of a 12-hour session with Bejeweled loaded in the back-

ground before and aer applying our policy. We see a 4

improvement on battery drain. Figure 7 conrms the eect

of releasing the ill-behaved wakelock: before being tamed,

the smartphone spent approximately 95% of the time with

an awake CPU. With Tamer’s interposition, most of the

residency ratio was converted to deep sleep.

570 2015 USENIX Annual Technical Conference USENIX Association

100

0 2 4 6 8 10 12

Battery Level(%)

Hours

Normal

Tamed

Figure 6: Battery drain over 12 hours for Bejeweled Blitz without

Tamer (Normal) and with a Tamer policy blocking the

AudioIn

wakelock. In both cases, the game was started and the phone

switchedtoidlemodewiththescreeno.

100

Deep Sleep

384 MHz

486 MHz

594 MHz

702 MHz

810 MHz

918 MHz

1.03 GHz

1.13 GHz

1.24 GHz

1.35 GHz

1.46 GHz

1.57 GHz

1.67 GHz

1.78 GHz

1.89 GHz

% of Time Spent

CPU Frequency

Normal

Tamed

Figure 7: CPU residency time for the original and tamed versions

of Bejeweled Blitz on the Galaxy S4. e tamed version spent

94% of the time in Deep Sleep.

Nike+ Running

[

]isatnessappfortrackingruns.

Nike+ relies on the GPS sensor, the accelerometer, and

barometer to estimate distance and speed. According to

Tamer, Nike+ acquired ve wakelocks while running:

AudioMix

FullPower Acc Sensor

FullPower

Pressure Sensor

FullPower Recording

and

NlpWakeLock

. Judging from the wakelock names, we

can assume a few hardware comp onents remained awake

to prevent device-sleeping. We found an ebug when

pausing our running session and switching Nike+ to the

background. In this case, we expected the applic ation to

release all wakelocks. Li ke Bejeweled Blitz, Nike+ forgot

to relinquish the locks upon leaving the foreground. Our

policy was also equivalent: block the culprit wakelocks

during background time. Figure 8 shows t he battery drop

aer an eight-hour session before and aer applying our

policy.Weseea5

improvement on battery drainage.

Figure 9 displays the CPU residency on both scenarios:

CPU deep-sleep residency jumped from a 0% to 89.8%.

We also acknowledge a major contribution of the GPS

and sensors to battery decay. eir duty cycle is equivalent

to the time the homonymous wakelocks were held.

5.3 Looking at the Other Side of Events

Tamer can block events at their imminent arrival or dis-

patch, thus saving energy that would be consumed by t heir

100

0 1 2 3 4 5 6 7 8

Battery Level(%)

Hours

Normal

Tamed

Figure 8: Battery drain over 8 hours for Nike+ Running without

Tamer (Normal) and with a Tamer policy that blocked all ve

held wakelocks. In both curves, the app was started and the phone

switchedtoidlemodewiththescreeno.

100

Deep Sleep

350 MHz

700 MHz

920 MHz

1.2 GHz

% of Time Spent

CPU Frequency

Normal

Tamed

Figure 9: CPU residency time for the original and tamed versions

of Nike+ Running on the Galaxy Nexus. e tamed version spent

89.4% of the time in Deep Sleep.

continuation. One can say that Tamer focusesontheef-

fect of an event. Still, there are situations in which the

energy cost of its cause is signic ant. A user could write a

policy targeting an instant messenger’s broadcast receiver

to throttle the eect of a message arrival – a noticat ion

intheformofsoundorvibration.However,shecannot

block the message arr ival itself, the major contributor to

energy consumption in this c ase, as the remote sender is

not covered by Tamer.

Actingonthecauseofaneventiscomplicatedbecause

its originator, when known, can take various shapes, like

a disk or network I/O operation. Consequently, nding

a converging instrument point in the source code that

encompasses all such shapes is complex. In parallel, we

shouldavoidpointsolutionsthatonlytoneapp.Between

these two extremes, we can reach a balance by instrument-

ing code that abstracts common functionality and gener-

ates events used by a subset of applications. We consider

the case of navigation apps to illustrate such scenario.

rottling Localization.

Android applications that rely

on the GPS sensor follow a basic model: (1) they register a

position listener and (2) they periodical ly receive location

updates from a provider proxy, the only interface to the

localization system [

]. A provider proxy serves as an

interface to various location sources, including the GPS

sensor, WiFi APs, and cell towers.

USENIX Association 2015 USENIX Annual Technical Conference 571

Given that the GPS is an energy-hungry resource, we

consider a throttling mechanism for its duty cycle. Paek et

al. [

] successfully demonstrated the potential energy sav-

ings of duty cycling by creating a rate-adaptive positioning

system that switches the GPS sensor on and o and uses

alternative location sources based on position accuracy.

As a demonstration, we consider a simpler GPS-throttling

implementation sans secondary sources. An advantage of

our approach is the dispensing of OS recompilation, keep-

ing it compat ible with the majority of Android dev ices.

e GPS sensor provides periodic position xes (every

second) to t he OS. Some of these xes are not relayed by

the Android fr amework to the navigation app as they are

not signicantly dierent. We can reach a more energy-

ecient navigation by directing the GPS duty cycle. We

inject code into internal classes related to the framework’s

GPS provider and open a dire ct communication channel

between the GPS de vice and our thrott ling mechanism.

is direct channel permits our controller to switch the

GPS on and o. Table 2 summarizes our instrumentation.

Evaluation.

We consider two location-based apps, Google

Maps and Nike+ Running. We ran these two applications

separately on the Galaxy Nexus phone and applied three

dierent throttling policies to the GPS duty cycle: location

updates every one, ve and een seconds. e rate choice

depends on the user’s purpose. For pedestrian navigation,

a slower update rate does not aect the estimated position

asmuchasinthecaseofahighwaycartrip.Paeketal.’s

work includes a thorough tradeo analysis between posi-

tion accuracy and energy savings. We, on the other hand,

only report the potential savings. For each scenario, we

programme d a pedestrian route lasting ten minutes. We

turned the screen o while running the application in the

background. Because of the small timespan, we compare

the energy dispensed instead of battery-level drop. We

usedtheMonsoonmonitortomeasuretheenergycon-

sumption. Figure 10 portrays the savings per application.

Weobserveanupperboundof27.7%onsavingsforthe

Nike+ Running application when reducing the location-

update rate to 1:15s. Although a lower update rate increases

the energy savings, position accuracy is penalized.

5.4 Performance Impact

Just like a network rewall, Tamer intercepts every event-

happening, inspects it, evaluates the corresponding policy

criterion, and nally actuates to ful ll the policy’s condi-

tions. Be cause Tamer diver ts the normal ow of applica-

tions, it should incur as little performance overhead and

energy burden as possible. We instrumented Tamer to

measure the time taken to hijack an event and perform its

blockage. For the longest diverted execution ow, Tamer

took, on average, 320

s to execute on the Galaxy Nexus

device. With regards to energy consumption, Tamer is

activated only when other applications generate events.

100

200

300

400

500

600

700

800

Maps

Nike+

Total Energy (J)

1s-rate Policy

5s-rate Policy

15s-rate Policy

Figure 10: Total energy consumed by Google Maps and Nike+

Running aer applying three dierent duty-cycle policies to the

GPS provider. For b oth apps, the update rate is inversely propor-

tional to energy savings.

Tamer does not acquire any wakelocks, but freeloads the

system’s active state from other wakeup sources.

6 Related Work

Wearenotthersttoproposecontroloffunctionalityin

exchange for battery savings. Tamer builds upon a number

of contributions to mobile power management.

Collateral Related Work.

Ecient power management in

mobile platforms is a challenging research problem due

to the multitude of hardware congurations and power

states. To improve energy consumption, we need to under-

stand how hardware components draw power on behalf

ofapplications.ereisamyriadoftoolsthathelpquan-

tify a device’s energy expenditure. PowerScope [

]isone

oftherstworksinthemobiledomaintomapenergy

to a program’s structure. PowerScope employs linear re-

gression and statistical sampling to apportion energy to

hardware and applications. A series of recent prolers for

smartphones complements PowerScope, including Power-

Tutor [

], ARO [

], AppScope [

], WattsOn [

] and

eprof [

]. Sesame [

] and V-edge [

] go a step further

and propose self-calibrating models that dispense the use

of external power monitors, relying instead on internal

battery data to model energy expenditure. Our analysis

mainly adopts battery-drop rate as a proxy for energy con-

sumption, but we exp ect such advanced contributions to

be integrated by OEMs in future devices.

Saving Energy From Background Tasking.

Android task

killers once were t he solution for background power

savings, but their eectiveness is now a point of con-

tention [

]. Task killers force background applications

to quit, assuming that their removal from memory will

reduce the energy footprint of released resources. Such

assumption is incorrect as there is little correlation be-

tween memor y and CPU usage in Android [

]. Excessive

task killing may lead to the opposite eect: by discarding

cached data, Android must reload apps from storage. A

572 2015 USENIX Annual Technical Conference USENIX Association

killed app may restart itself immediately aer being killed,

using up CPU time and draining even more battery.

Rather than killing background tasks, popular apps like

JuiceDefender [

] and Easy Battery Saver [

] can cong-

ure the access to power-greedy components, such as the

radio and GPS, on a schedule basis. Although eect ive in

many case s, some apps do not behave properly when they

cannot, for instance, connect to t he Internet. Some apps

may even produce more energy overhead as they insist

on accessing a resource made unavailable. Tamer circum-

vents such problems by mainly throttling asynchronous

actions: the exp ecting app does not block while waiting

for an event arrival or dispatch. Greenify [

]isanAn-

droid tool for hibernating apps, preventing the arrival or

dispatch of events once an app switches to background.

e original functionality is only restored when the app

returns to the foreground. Greenify is eect ive in block-

ing misbehaving and start-at-boot apps, but its treatment

of background computing is coarse and not applicable

to notication-based apps that mostly run in the back-

ground (e.g., mail readers, instant messengers, calendars,

etc.) Tamer is applicable in such cases as it throttles, but

does not completely eliminate, background functionality.

Android also includes its own controls for background-

task management. e

AutoSync

feature controls the au-

tomatic data synchronization between client apps and on-

line accounts. With a mere tap, users can choose between

disabling the synchronization of a specic feature of a

selected account (e.g., photo uploads for Google+) or to-

tally prevent any background synchronization for all reg-

istered accounts.

AutoSync

is mostly applicable to apps

adopting Google Cloud Messaging (GCM), an API piece

from Google Mobile Serv ices. GCM provides a lightweight

mechanism that third-party servers can use to notify mo-

bile applications of available content to be fetched. As long

as the application is subscribed to receive GCM messages,

the Android device does not need to run continuously.

Instant messengers, for instance, use GCM to receive noti-

cations of new incoming messages. Tamer complements

this service by oering a similar control to applications

that do not adopt the GCM approach. Moreover, Tamer

allows for the management of a variety of background

events, whereas

AutoSync

focuses mainly on networking.

Partial inspiration for deep event monitoring stems

from applications such as BetterBatteryStats [

] and

Wakelock Detector [

]. Both apps report wakelock-usage

statistics that developers can use to understand the root

cause of battery drainage. Tamer complements such apps

by empowering users to take action aer they pinpoint the

origin of abnormal energy consumption.

Carat [

] and eStar [

] use data colle cted from thou-

sands of smartphone and tablet users to model the battery

drainage of applications. By combining r ich context infor-

mation of multiple devices with energy awareness, it is

possible to determine whether the energy used by an appli-

cation deviates from its expected consumption. ese tools

are conservative in controlling energy expenditure, with

both systems suggesting users to kill or uninstall culprit

apps. eStar further recommends energy-ecient a lterna-

tives to power-hog apps, if they exist. Tamer let users keep

their apps while modifying the culprit’s behavior to reduce

energy consumption.

7 Discussion

As any prototype, Tamer has limitations. Tamer’s main

utility comes from policy denition, which, at its current

state,willnotappealtotheenduser.Inthefollowing,we

elaborate on how to circumvent this usability issue. We

also suggest improvements that are le as future work.

7. 1 Policy Guidelines

In §5, we demonstrated how a wise policy selection can

partially inhibit the surge of energy-hungry events. Our

experience dening policies arose from intuition, reading

source code (when available) and, in some cases, multiple

attempts. At its current state, Tamer would better serve

as a backend for higher-level power management tools

than as an end-user app. With such limitations in mind, a

user willing to run Tamer asitis,wouldbenetfromthe

following guidelines to explore the event space and dene

eective policies.

Choosi ng events to control.

Handhelds may carry tens

or even hundreds of applications that generate thousands

of events. We should not imply that policy denition must

consider all of them equally. First, users prefer some apps

over others. Second, event triggering does not follow a uni-

form distribution. As a r ule of thumb, users should start

with policies target ing the most frequent events. Tamer’s

monitoring mo dule periodically outputs an event sum-

marythatcanassistinsuchcases.

Cutting the red wire.

Even aer selecting the most promi-

nent events for policy testing, there are no guarantees that

the policy will work without side eects. Side eects may

include an increase in the frequency of correlated events,

the rise of unexpected events, and abnormal application be-

havior. Blocking alarm events recklessly could, for instance,

totally defeat the purpose of a calendar app. Because most

apps are only available in binary form, understanding the

purpose of an event is not always clear and neither is un-

covering its dependencies. Techniques us ed in black-box

testing, such as cause-eec t graphs can help. Events may

also show a temporal correlation with others. To uncover

temporal dependency, we generated event timelines from

Tamer’s monit oring output.

Use common sense.

e Android OS denes two cate-

gories of applications: system and user. e former in-

cludes prog rams that are deemed critical, are deeply in-

tegrated into the OS, and cannot be uninstalled. Exam-

USENIX Association 2015 USENIX Annual Technical Conference 573

ples include the dialer, browser, and network manager, to

name a few. Users apps are replaceable programs t hat c an

befreelyremovedandinstalledfromtheappstore.As

part of Tamer’s design, we adopted the support of generic

events. Consequently, system- and user-app events are

treated equally. Policies that alter the frequency of sys-

tem events may result in unwanted or abnormal behavior.

Users should be mindful when dening policies involv ing

critical events to avoid such situat ions. Removing support

for system events would prevent such unfortunate occa-

sions, but the denition of a system app is blurry. GMS,

for example, comes pre-installed as a system package on

many devices. Carriers also sell devices with bloatware

installed as system apps. As demonstrated, systems apps

present great opportunities for energy savings.

7. 2 Potential Improvements

Event batching over cancellation.

Our current imple-

mentation dismisses event continuation if there is a need

for throttling. Alternatively, we could reschedule the asyn-

chronous delivery of such events to coalesce multiple wake-

ups into one, saving even more energy. Although promis-

ing, event coalescing may lead to unexpected results that

require deeper investigation. Some apps assume a xed fre-

quency of events. A pedometer may use the time dierence

between position xes to estimate speed. B atching multi-

ple xes into one delivery may create havoc if the tracker

does not discard outdated values. Nevertheless, coalescing

has found its way in other domains. e Linux tickless

kernel [

] reduced t he precision of soware timers to al-

low the synchronization of process wakeups, minimizing

the number of CPU power-state transitions. From its Lol-

lipoprelease,Androidstartedtobatchalarmsthatoccur

at reasonably similar times, turning them inexact. Xu et

al.’s recent work on coalescing events to save energy in the

context of email synchronization [

] is another success-

ful example of careful event-handling for mobile devices.

As long as developers do not assume guarantees on event

delivery and commutativity, we believe coalescing should

supersede cancellation as an energy-saving feature.

Native code support.

Tamer controls applications by

wrapping function calls from the Android Java API. Ap-

plications that make heavy use of native code, like games,

multimedia apps and ELF libraries, could acquire wake-

locks, spawn threads and perform background tasks using

C/C++ code, thus bypassing our control system. Extend-

ing support to native co de would require a similar eort

on analyzing and instrumenting libc function calls.

Support for other mobile OSes.

Background processing

is not exclusive to Android, although handled dierently

by other mobile OSes. Apple’s iOS 7+ regards background

processing as a privilege [

]. Other than network trans-

fers, common background tasks have limited time to com-

pletion and must respect the device’s will to sleep, do-

ing their processing in chunks aer the device wakes up

to handle phone calls, notications and other interrup-

tions. Windows Phone enforces background tasks to be

lightweight by applying quotas to resources like CPU, mem-

ory, and network usage while apps are running behind the

scenes [

]. Event-frequency control may not produce

the same gains on Apple’s and Microso’s mobile devices

given their stricter stance on deploying background tasks

(mainly in t he name of battery savings).

Feedback control.

Tamer works as an open-loop con-

troller, not using feedback to gauge whether the system

needs more adjustments. During the design stage of this

project, we discarded the closed-loop approach as it would

require knowledge of application semantics as well as user

perception of performance degradation. Modeling these

two elements are hard problems beyond our scope.

8 Conclusion

is paper presented Tamer, an OS mechanism that in-

terposes on task wakeups in Android and allows event

handling to be monitored, ltered, and rate-limited. We

demonstrated that Tamer substantially reduces the back-

ground energy use in popular Android applications. With

Tamer, a device spends more time in low-power mode,

which increases the battery lifetime signicantly.

While this work shows Tamer’s eectiveness as a mech-

anism, future work is needed to understand how to best

construct policies that improve battery life while preserv-

ing application functionality. In future work, we will in-

vestigate techniques for determining if functionality is

negatively impacted when exploring user visible elements

(e.g., UI dierences) between runs of an application with

dierent policies. We will also explore which policies are

most likely to have substantial battery savings in practice.

With the combination of such techniques, we will strive

to devise policies that improve battery life w hile retaining

normal application functionality.

Acknowledgements

We thank Tim Nelson, Hammurabi Mendes, the anony-

mous reviewers, and our shepherd, Lin Zhong, for their

feedback. Marcelo was funded in part by a generous gi

from Intel Corpor ation.

574 2015 USENIX Annual Technical Conference USENIX Association

References

[1]

2Easy Team. Easy Battery Saver. http://www.

2easydroid.com.

[2]

Android Developers. Best practices for back-

ground jobs. https://developer.android.com/

training/best-background.html.

[3]

Android Developers. Location strategies.

https://develop er.android.com/guide/topics/

location/strategies.html.

[4]

Android Developers. Managing your app’s

memory. https://developer.android.com/training/

articles/memory.html.

[5]

AndroidCentral.com. Google Services battery

drain. http://forums.androidcentral.com/google-

nexus-4/302559-google-services-battery-

drain.html.

[6]

Andrus, J., Dall, C., Hof, A. V. H., Laadan, O.,

and Nieh, J. Cells: A virtual mobile smar tphone

architecture. In ACM SOSP’11.

[7]

Apple Inc. App programming guide

for iOS. https://developer.apple.com/

library/ios/documentation/iPhone/

Conceptual/iPhoneOSProgrammingGuide/

BackgroundExecution/BackgroundExecution.

html.

[8]

ARM Limited. big.LITTLE technology: e future

of mobile. http://www.arm.com/ﬁles/pdf/big_

LITTLE_Technology_the_Futue_of_Mobile.

pdf.

[9]

AT&T. Application resource optimizer (ARO).

http://developer.a tt.com/application-resource-

optimizer.

[10]

CyanogenMod Community. http:

//www.cyanogenmod.org.

[11]

Dietz, M., Shekhar, S., Pisetsky, Y., Shu, A., and

Wallach, D. S. QUIRE: Lightweight provenance

for smart phone operating systems. In USENIX Secu-

rity’11.

[12]

Dong, M., and Zhong, L. Self-constr uctive high-

rate system energy modeling for battery-powered

mobile systems. In ACM MobiSys’11.

[13]

Electronic Arts Inc. Bejeweled Blitz.

http://play.google.com/store/apps/details?

id=com.ea.BejeweledBlitz_na.

[14]

Enck, W., Gilbert, P., Chun, B.-G., Cox, L. P., Jung,

J., McDaniel, P., and Sheth, A. N. TaintDroid:

An information-ow tracking system for realtime

privacy monitoring on smartphones. In USENIX

OSDI’10.

[15]

Feng, O. Greenify. https://play.google.com/store/

apps/details?id=com.oasisfeng.greenify.

[16]

Flinn, J., and Satyanarayanan, M. Energy-aware

adaptation for mobile applications. In ACM SOSP’99.

[17]

Flinn, J., and Satyanarayanan, M. PowerScope:

A tool for proling the energy us age of mobile appli-

cations. In IEEE WMCSA’99.

[18]

Gigaom. Google’s killer Android L feature: Up

to 36% more battery life thanks to Project Volta.

http://gigaom.com/2014/07/02/go ogles-killer-

android-l-feature-up-to-36-more-battery-life-

thanks-to-project-volta.

[19]

Google. Battery Historian. https://github.com/

google/battery-historian.

[20]

Google. Our mobile planet. http://think.

withgoogle.com/mobileplanet/en.

[21]

Hoffmann, H., Sidiroglou, S., Carbin, M., Mis-

ailovic, S., and Agarwal, Anant ad Rinard, M.

Dynamic knobs for responsive power-aware comput-

ing. In ASPLOS’11.

[22]

Jung, W., Kang, C., Yoon, C., Dongwon, K., and

Cha, H. AppScope: Applicat ion energ y metering

framework for Android smartphone using kernel ac-

tivity monitoring. In USENIX AT C’12.

[23]

Kim, K., and Cha, H. WakeScope: Runtime wake-

lock anomaly management scheme for Android plat-

form. In ACM EMSOFT’13.

[24]

Kim, W., Gupta, M. S., Wei, G.-Y., and Brooks,

D. System level analysis of fast per-core DVFS using

on-chip switching regulators. In IEEE HPCA’08.

[25]

Knispel, S. BetterBatteryStats. https:

//play.google.com/store/apps/details?id=

com.asksven.betterbatterystats.

[26]

Latedroid. JuiceDefender – battery saver. http:

//www.juicedefender.com.

[27]

LifeHacker.com. Android task killers explained:

Whattheydoandwhyyoushouldn’tusethem.http:

//lifehacker.com/5650894.

[28]

Microsoft. Supporting your app with background

tasks. https://msdn.microsoft.com/en-us/library/

windows/apps/xaml/hh977056.aspx.

USENIX Association 2015 USENIX Annual Technical Conference 575

[29]

Mittal, R., Kansal, A., and Chandra, R. Empow-

ering developers to estimate app energ y consumption.

In ACM MobiCom’12.

[30]

Mobile Enerlytics LCC. eStar: Because mobile

devices are not mobile if they are plugged in. http:

//mobileenerlytics.com.

[31]

Monsoon Solutions Inc. Power monitor. http://

www.msoon.com/LabEquipment/PowerMonitor.

[32]

Nike, Inc. Nike+ Running. http://play.google.com/

store/apps/details?id=com.nike.plusgps.

[33]

Oliner, A. J., Iyer, A. P., Stoica, I., Lagerspetz,

E., and Tarkoma, S. Carat: Collaborative energy

diagnosis for mobile devices. In ACM SenSys’13.

[34]

Paek, J., Kim, J., and Govindan, R. Energy-

ecient rate-adaptive GPS-based positioning for

smartphones. In ACM MobiSys’10.

[35]

Pathak, A., Hu, Y. C., and Zhang, M. Bootstrap-

ping energy debugging on smartphones: A rst look

at energy bugs in mobile devices. In ACM HotNets’11.

[36]

Pathak, A., Hu, Y. C. H., and Zhang, M. Fine

grained energy accounting on smartphones with

eprof. In EuroSys’12.

[37]

Pathak, A., Jindal, A., Hu, Y. C., and Midkiff, S. P.

What is keeping my phone awake? characterizing and

detecting no-sleep energy bugs in smartphone apps.

In ACM MobiSys’12.

[38]

Qian, F., Wang, Z., Gerber, A., Mao, Z., Sen, S.,

and Spatscheck, O. Proling resource usage for

mobile applications: a cross-layer approach. In ACM

MobiSys’11.

[39]

Qualcomm. Trepn Proler. http://developer.

qualcomm.com/mobile-development/increase-

app-performance/trepn-proﬁler.

[40]

Reddit. NlpWakeLock and NlpCollectorWake-

Lock discussion. https://www.reddit.com/r/

Android/comments/1rvmlr/nlpwakelock_and_

nlpcollectorwakelock_discussion/.

[41]

rovo89. Xposed development tutorial.

https://github.com/rovo89/XposedBridge/

wiki/Development-tutorial.

[42]

rovo89. Xposed module repository. http://repo.

xposed.info.

[43]

Roy, A., Rumble, S. M., Stutsman, R., Levis, P.,

Mazières, D., and Zeldovich, N. Energy manage-

ment in mobile devices with the Cinder operating

system. In EuroSys’11.

[44]

Siddha, S., Pallipadi, V., and Van De Ven, A. Get-

ting maximum mileage out of tickless. In Ottawa

Linux Symposium’07.

[45]

UzumApps. Wakelock Detector. https:

//play.google.com/store/apps/details?id=

com.uzumapps.wakelockdetector.

[46]

Vekris, P., Jhala, R., Lerner, S., and Agarwal, Y.

Towards verifying android apps for the absence of

no-sleep energ y bugs. In HotPower’12.

[47]

Xu, F., Liu, Y., Li, Q., and Zhang, Y. V-edge: Fast self-

constructive power modeling of smartphones based

on battery voltage dynamics. In USENIX NSDI’13.

[48]

Xu, F., Liu, Y., Moscibroda, T., Chandra, R., Jin,

L., Zhang, Y., and Li, Q. Optimizing background

email sync on smartphones. In ACM MobiSys’13.

[49]

Zeng, H., Ellis, C. S., Lebeck, A. R., and Vah-

dat, A. ECOSystem: Managing energy as a rst class

operating system resource. In ASPLOS’02.

[50]

Zhang, L., Tiwana, B., Qian, Z., Wang, Z., Dick,

R. P., Mao, Z. M., and Yang, L. Accurate online

power estimation and automatic battery behavior

based power model generation for smartphones. In

CODES+ISSS’10.