Selectively Taming Background Android Apps to Improve Battery

Selectively Taming Background Android Apps to Improve Battery Lifetime Marcelo Martins, Brown University; Justin Cappos, New York University; Rodrigo Fonseca, Brown University https://www.usenix.org/conference/atc15/technical-session/presentation/martins

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 Justin Cappos Rodrigo Fonseca Brown University New York University Brown University

Abstract blocks return from suspension upon interrupts emitted by Background activities on mobile devices can cause signi - hardware or soware indicating that they have pending re- cant battery drain with little visibility or recourse to the quests. With the rise of multitasking and the multiplication user. ey can range from useful but sometimes overly ag- of background services and complex mobile applications, gressive tasks, such as polling for messages or updates from we expect this amount of interrupts to increase, forcing sensors and online services, to outright bugs that cause the system to spend more time active to attend requests. resources to be held unnecessarily. In this paper we instru- Such active periods take a toll on battery lifetime. A recent ment the Android OS to characterize background activities study by Google clearly shows this impact: each second of that prevent the device from sleeping. We present T , active use of a typical phone reduces the standby time by an OS mechanism that interposes on events and signals two minutes []. that cause task wakeups, and allows for their detailed mon- is paper studies the problem of battery drain mostly itoring, ltering, and rate-limiting. We demonstrate how due to app-originated background operations that wake up T can help reduce battery drain in scenarios involv- the mobile system. We present T , an OS mechanism ing popular Android apps with background tasks. We also we built for Android that interposes on events and signals show how T can mitigate the eects of well-known responsible for task wakeups – alarms, wakelocks, broad- energy bugs while maintaining most of the apps’ function- cast receivers, and service invocations. Like a number of ality. Finally, we elaborate on how developers and users can pro ling tools, T allows us to characterize the back- devise their own application-control policies for T ground behavior of dierent apps installed on a device. In to maximize battery lifetime. §, using T ’s instrumentation, we show how a set of installed applications can dramatically aect the battery Introduction lifetime of four dierent devices. Unlike existing pro ling e accelerated growth of sensing, computational, stor- tools, however, T canalsoselectivelyblockorrate- age, and communication capabilities of mobile devices limit the handling of such events and signals following has enabled a rich application environment that rivals the exible policies. In this way, T can, for example, limit performance of desktop computers. Even so, battery tech- the frequency at which an application schedules alarms or nology has not followed the same advancement pace and receives noti cations of speci ed events, providing ne- there is little evidence that this situation will dramatically grained control over the energy usage of apps that may be improve. As a result, battery lifetime has become a major useful, but are irresponsible or inecient with respect to usability concern, with users willing to enjoy the latest their background activities. In §. we show via a few case apps on their smartphones and tablets, but, at the same studies how T can reduce the energy consumed by time, worrying that their battery will not last long enough. energy bugs [] in legitimate apps. We summarize our Since the inception of mobile computing, both indus- contributions as follows: try and academia have developed a slew of techniques to • We characterize how applications and core compo- reduce power at the architecture [, ], OS [, ] and nents of the Android OS use speci c features to en- application levels [, ], and today’s systems draw little able background computing, and how this computing power while idling. Due to its user-centric and interac- signi cantly aects energy use. In special, we note tivenature,theowofamobileapplicationisdrivenby that Google Mobile Services play a major role on events such as user actions, sensor I/O, and message ex- battery drain while the device is dormant (§). changes. Such event-driven paradigm lets the system idle • We introduce T , an OS mechanism to control until a new event arrives. Mobile OSes, such as Android, the frequency at which background tasks are handled, iOS, and Windows Phone, take advantage of such idling thereby limiting their impact on energy consumption opportunities to engage in opportunistic suspend. Upon (§). T leverages code-injection technology and brief periods of idling, the handheld switches to the default is applicable to any Java-based Android application. suspend state. Hardware blocks, including the CPU, GPU, • We demonstrate how T can successfully throt- GPS, and network modem, shi to low-power mode and tle the background behavior of popular applications, soware state is kept in self-refreshing RAM. e same thus reducing their energy footprint (§). We show

USENIX Association 2015 USENIX Annual Technical Conference 563 how di erent policies reduce power draw in exchange veloped by Google, such as Calendar, Google+ (social me- for little to no impact on functionality. dia), Google Now (personal assistant), Hangouts (instant Despite being a powerful mechanism, T isonlya messaging), Maps, Photos, Play Service (integrating API), step towards e ective control of background energy usage. PlayStore,andSearch.Duetotheirpopularityandadded In particular, there are still challenges in helping users value, GMS apps are included in most Android devices dene policies that are e ective, yet not disruptive to the sold today. For the third scenario, which we only ran on user experience. We discuss such challenges in §. the Galaxy Nexus phone, we also installed the ten most popularfreeappsofGoogle’sPlayStoreasofJanuary. Motivation We based all environments on the KitKat (.) version of Smartphone and tablet users are used to being always con- Android. For the experiments, we le each device unat- nected, expecting immediate notications of a new e-mail tended running with its conguration at default settings. or application update. Other common background oper- Other relevant settings include connection to a WiFi ac- ations include polling navigational sensors for location cess point, enabled location-reporting, and background clues and turning on the network radio for incoming mes- network synchronization. We expect most of the battery sages. Especially in Android, where there is little restriction drainage to stem from static-voltage leakage and eventual on what apps can do in the background and developer’s background processing. discipline is the main factor preventing inecient applica- Figure shows the time taken by each environment- tions, apps can hog resources and waste energy. device combination to deplete the battery. For all devices, Traditionally there has been little visibility, both to app Pure AOSP took the longest to completely drain the battery. developers and to users, on the contribution of individual In the case of tablets, this di erence spanned dozens of apps to energy use, especially while in the background. It is hours. To investigate why this happened, we instrumented even harder to know whether an app is actually running or the Android soware stack to timestamp the occurrence idling. Recent monitoring and proling tools have helped of background events. Additionally, we connected one of bridge this visibility gap [, , , , , , ],asone our devices (Galaxy Nexus) to a Monsoon power moni- cannot optimize what cannot be measured. tor [] and collected power traces from the battery. Finally, Today’s average handheld contains a large amount of we aligned and synchronized both the event and power third-party soware. A survey shows a global average timelines to understand their correlation. Figure depicts of apps installed on a mobile device [].Evenwiththe a six-minute slice of this combination. We observe that best currently available tools, the end user can do little to GMS triggers more events in the background and that they cope with inecient apps. Most of the tools above target arecorrelatedwiththesurgeofpowerpeaks.Weusedthis developers and provide little help for the user. Even the tracing knowledge to build a mechanism that counters the friendlier ones, such as eStar []andCarat[], when energy e ect due to excessive wakeups. Because this mech- highlighting energy-inecient programs, can only o er to anism relies on OS internals, we rst need to understand kill or uninstall the culprit app, perhaps suggesting replace- how an Android app functions while in the background. ments. Unfortunately, this is too coarse-grained a solution Background and some apps with irreplaceable functionality become an is section provides a concise description of Android’s inconvenience one has to live with. power-management system followed by an overview of T o ers the possibility of much ner-grained con- the components constituting a mobile app and how appli- trol once an energy hog or bug is found. It provides infor- cations behave while running in the background. Finally, mation on which tasks are expending the most energy and we highlight the inuence of background execution on bat- can rate-limit their execution. T detects most causes tery drain using four types of events: wakelocks, services, of device wakeup that are visible at the framework level of broadcast receivers, and alarms. § describes T , our Android, and can lter their continuation in real time. control system that adjusts the frequency at which such To demonstrate the signicant di erence that a set of events occur. running tasks can make in a device’s battery life, we measured the battery drop of four Android devices (two smart- . Mobile Power Management phones and two tablets, cf. Table ) running two di erent Android employs an aggressive form of power manage- application sets, while idling and with the screen o . Con- ment to extend battery life. By default, the entire system servatively, we consider three scenarios: the rst testing suspends itself, sometimes even when there are processes environment (Pure AOSP) consists of a stripped version of running. Opportunistic suspend is e ective in prevent- the Android Open Source Project (AOSP) OS containing ing programs from keeping the system awake and quickly a minimum number of services and apps; the second one Crossy Road, Candy Crush Soda Saga, Pandora Radio, Trivia Crack, adds Google Mobile Services (GMS) on top of Pure AOSP. Snapchat, Facebook Messenger, Facebook, Security Antivirus, Insta- GMS consists of proprietary applications and services de- gram and Super-Bright LED Flashlight.

564 2015 USENIX Annual Technical Conference USENIX Association Device Name Device Type Processor Features Google Galaxy Nexus Smartphone Dual-core .GHz ARM Cortex-A WiFi, GPS+A-GPS, G Samsung Galaxy S Smartphone Quad-core .GHz Qualcomm Krait WiFi, GPS+A-GPS, G/LTE Amazon Kindle Fire Tablet Dual-core .GHz ARM Cortex-A WiFi ASUS MeMO Pad (ME C) Tablet Quad-core .GHz Intel Atom Z WiFi, GPS+A-GPS

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

100 Pure AOSP 100 Pure AOSP 100 Pure AOSP 100 Pure AOSP w/ Google M. Services w/ Google M. Services w/ Google M. Services w/ Google M. Services 80 w/ GMS + Top10 80 80 80 60 60 60 60 40 40 40 40 20 20 20 20 Battery Level (%) Battery Level (%) Battery Level (%) Battery Level (%) 0 0 0 0 0 20 40 60 80 100 120 140 0 20 40 60 80 100 120 140 160 0 50 100 150 200 250 300 350 0 50 100 150 200 250 Hours Hours Hours Hours (a) Galaxy Nexus (b) Galaxy S (c) Fire (d) MeMO Pad

Figure : Battery drop of four Android devices idling with the screen o. With Google Mobile Services installed, battery life decreased to .% (Fire ) and .% (MeMO Pad ) of its initial decay (without GMS). awake vs. keep the radio, screen, and CPU awake). As 2 AlarmManager an example of suspend-blocking by the OS, Android au-

1 tomatically acquires a wakelock as soon as it is notied Power (W) 0 ofaninputeventandonlyreleasesthewakelockonce 0 50 100 150 200 250 300 350 some application handles the event or there is a timeout. Timeline (s) Application developers can also directly instantiate and (a) Pure AOSP manipulate wakelocks using the Wakelock API. A proper e-book reader app must acquire a wakelock to keep the AlarmManager NetworkLocationService GCoreFlp screen awake so that the user can read her favorite novel GeofencerStateMachine NlpCollectorWakeLock without interruption. Wakelocks play an important role NlpWakeLock UlrDispatchingService in guaranteeing proper background task execution in face PendingIntentCallbackService NlpLocationReceiverService of default suspension, as we will see next.

Power (W) 3 2 . Android Applications: Dealing with 1 0 Lifecycle Changes 0 50 100 150 200 250 300 350 Timeline (s) Barring a few interface-less system processes, an Android (b) Pure AOSP + GMS application consists of a set of Activities that places the UI widgets on the screen. An application starts with Figure : Six minutes sampled from measurements on the Galaxy a single thread of execution attached to the foreground Nexus for two scenarios. For each graph, the top stack shows UI, which is mostly responsible for dispatching interface dierent event occurrences over time. e bottom curve depicts events. Toavoid app unresponsiveness and user frustration, the corresponding system’s power draw during the same period. a wise programmer would move other computations to concurrent worker threads while the UI responds to input draining the battery. To curb system suspension, Android events. Support for concurrency comes in the form of a uses Wakelocks to keep the system awake. Wakelocks are number of standard Java primitives, such as Threads and reference-counted objects, similar to concurrency locks, Futures,aswellasAndroid’sownavors:AsyncTasks that can be acquired/released by kernel and privileged and message Handlers. However, such primitives only userspace code. A wakelock acquire expresses a process’s workwhentheapplicationisintheactive state. need for the system to remain awake until run completion. As the user navigates through, out of, and back to an A wakelock acquire either holds a resource awake until a application, its lifecycle transitions between dierent states release call occurs or sets up a timer to relinquish the lock according to activity visibility. An application is active if atalatertime. one of its activities receives user focus in the foreground. If Kernel drivers use wakelocks to block the suspension of the user switches to another app or decides to turn o the dierent system components (e.g., CPU, network, screen), screen, the application is paused and moved to the back- whereas the Android application framework leverages ground. Because mobile apps are multitasked, developers wakelocks for dierent levels of suspension, represented must have a way to run code even when their app is not by groups of components (e.g., keep the network radio occupying the screen.

USENIX Association 2015 USENIX Annual Technical Conference 565 .. Dispatching Background Tasks keep the system awake. In the next section, we introduce e small screen size of a smartphone or tablet prevents T , a system that acts on this small and well-dened multiple applications from running simultaneously. To interface to throttle the rate at which background events conserve energy, apps are frozen and stop working once are handled in exchange for energy savings. sent to the background, either due to the opening of an- T other application or a screen timeout. Context switching opens room for opportunistic suspend – by making apps . Design invisible, the Android OS frees its own set of wakelocks, Having seen that background events can noteworthily af- opening space for hardware throttling. fect the sleeping pattern of mobile devices, we consider Android oers application developers a small and well- the possibility of regulating their frequency to improve dened interface for background-task ooading that takes battery life. We introduce a conguration mechanism for careofschedulinglatenttasks[]. is interface comprises declaring thresholds to the frequency of these events. We a handful of components including services, broadcast model this regulation process using three sequential steps: receivers, and alarms. e internal implementation of such () observation; () comparison; and () action. components also leverages wakelocks to keep the device Event-frequency regulation works based on the speci- awake while executing tasks. cation of occurrence limits. We establish a policy mecha- Services are application components that run asyn- nism that lets users dene how oen the running system chronously on background threads or processes and do should permit a given background event to proceed. A pol- not directly interact with the user. Instead, Activities icy is a contract that declares the conditions for an event ex- dispatch services to perform long-duration operations or ecution. is contract species the event type as well as its to access resources on behalf of users, such as download- identier; an optional list of aected apps, in case we want ing remote les or synchronizing data with a cloud-based to restrict such enforcement to a subset of event dispatch- storage. An advantage of running services separately is that ers or receivers; whether the policy enforcement also takes their running persists even aer closing the owner’s inter- place when the event owner (app) is in the foreground; and face. Apps and widgets rely on services being operational therateatwhichtheyareallowedtoexecute.Fromthis withoutneedofmanualrestart. denition, an energy-savvy user could program her smart- BroadcastReceiver isareactivemechanismthatper- phonetopermitcallstoWeatherUpdateService from a mits programs to asynchronously respond to specied weather-forecast app at most once every six hours, whereas events. An application registers a BroadcastReceiver calls to LocationUpdateService fromthesameapp along with an event-subscription list – the IntentFilter would remain unlimited. – that is used to determine if the application is eligible to To enforce user-dened policies, we outline a controller respond to a given event. Events can be predened by the comprising three agents: observer, arbiter and actuator. system (e.g., “battery fully charged”) or developer-dened e observer intercepts every event occurrence and book- (e.g., “backup nished”). Receiver threads remain dormant keeps its frequency. e arbiter veries whether the mea- until a matched event arrives and respond by running a sured event rate is above the policy-dened threshold, if it callback function. A le-hosting app could, for instance, exists, and noties the actuator, which hijacks the event register a receiver to display a notication box once it dis- continuation to articially reduce its occurrence rate. Fig- covers that a scheduled data synchronization has nished. ure illustrates our control sequence. Another common programming pattern is the ability to

perform time-based operations outside the lifetime of an Policy application. For instance, checking for incoming e-mails every so oen is a recurrent user operation that could Event Event rate Decision Action Observer Arbiter Actuator be automatized. e Android SDK oers developers the AlarmManager mechanism to fulll the scheduling of periodic tasks at set points. At each alarm trigger, the system Figure : Sketch of our event-control system as a three-stage wakes up and executes the scheduled callback function, pipeline. whose contents can take various forms: a UI update, a ser- ere are two ways to fulll event throttling: canceling vice call, an I/O operation, scheduling a new alarm, etc. or delaying. An event cancel denies the continuation of its Alarmsareagoodtforopportunisticsuspend:appsare call,withanearlyreturnthatpreventsthepayloadorthe onlyactivatedwhenthereisworktodo. event callback from running. An event delay, on the other In summary, Android uses at least three types of asyn- hand,postponesthecontinuationoftheeventcallfora chronous mechanisms to perform background tasking: limited time. In this work, we opt for canceling the event services, broadcast receivers, and alarms. Aligned with handling. We discuss the pros and cons of each choice wakelocks, we have a powerful collection of events that can in §.Itisimportanttounderstandthataneventcancel

566 2015 USENIX Annual Technical Conference USENIX Association does not result in a crash. Alarms, services and broadcast back with the running code. Callbacks run on the context receivers all run asynchronously. Wakelock requests, on of the intercepted application. Xposed allows for changing the other hand, are synchronous and their denial will result the parameters of a method call, modifying its return value in a sleeping system when a waiting task is expected to run. or terminating it early. We leverage the hooking mecha- Still,thetaskisneveraborted,butrunsinchunkswhen nism to intercept function calls originating from or di- the system wakes up. Our method prevents the triggering rected at our events of interest. Finally, function hooks can of unwanted events. When it is not possible, we abort the be distributed as separate programs in self-contained APK event continuation at the earliest opportunity to reduce the les. ey are not bound to a specic Android version and energy cost of the event payload. work without changes on the majority of customized An- To drive the implementation of our system, we establish droid releases, including those from Samsung, HTC, Sony, a few requisites and considerations: LG, and the CyanogenMod open-source community []. Comprehensive support for events. e control system Figure shows how T relates to the Android OS. should be inclusive. While app-specic solutions are eec- T sits, along with Xposed, between user applications tive, they do not scale to other programs. e stage pipeline and the Java-based application framework, which serves should monitor and, if necessary, actuate on every event as the foundation for the Android SDK. Events have direc- instance. Particulars about a specied event should be con- tions, which helps us dene how to write the interception ned to its policy and not aect the controller. It is the payload. While service and wakelock calls originate from responsibility of the policy designer to dene a sane event appsandareforwardedtotheframework,alarmsand frequency, considering, perhaps, the context and the im- broadcast receivers work in the opposite direction. pact of an event hijack. To implement an all-encompassing T consists of a series of function hooks that inter- monitor system, we target an OS-level solution. pose on the background-processing interface and act as Support for power-oblivious applications. Users should a controller mechanism to enforce user-dened policies. not abstain from using their favorite apps even if they are To implement T ’s event-canceling mechanism, we power hogs. Uninstalling or suggesting alternative apps leverage Xposed’s introspection API to explore, monitor, for the same purpose should not be acceptable. e system intercept and modify public and private classes, methods should cope with the existence of ill-behaved apps and act and members of the framework (Table ). We used our upon their misbehavior if directed by the policy designer. knowledge on the Android SDK aligned with the source Compatibility. Many solutions that rely on deep sys- code of Android’s framework stack to decide where to tem introspection require extensive rewrites of system place the instrumentation points that would constitute components [, , ] or even writing systems from our controller. We analyzed the source code stemming scratch []. Although tempting, straying from the main- from each event call on the SDK’s public interface. Model- line can severely limit the userbase, especially in the case of ing the relationships between subroutines as a call graph, consumer-oriented OSes. With that in mind, our solution we considered each interface function as a leaf node. In should exhibit high compatibility and keep a minimum some occasions, we had to backtrack the call graph to nd amount of changes to the underlying OS. a proper instrumentation point. is was necessary for E ciency. Mobile apps must cope with limited computa- three reasons: () the public interface did not oer enough tional and energy resources. e control system should context to feed our monitoring system (e.g., missing re- avoid high computational overhead to prevent high battery ceiver name, unclear caller-callee relationship, etc.); () in drain and system slowdown. the case of receiving events, it was better to interpose on a . Implementation call as early as possible to avoid unnecessary operations beforeacancellation;()aneventcallmayhavemorethan To avoid reimplementing OS components to regulate event one function signature, therefore we looked for a converg- handling, T uses the Xposed framework [] to en- ing function node. We found one exception to the last rule able system modications at runtime. when handling broadcast receivers. Applications can de- While requiring the device to be rooted, Xposed enables clare receivers in two ways: statically via a Manifest le deep system modications with no need to decompile ap- or dynamically using the Android SDK API. Since the An- plications nor ash the device . Xposed intercepts Java droid framework keeps separate data structures for each methods and temporarily diverts the execution ow to case, we had to instrument them separately. function-hook callbacks for inspection and modication. T ’s interception can suppress wakeups due to ser- Developers dene these callbacks and compile them as sep- vice invocations, wakelock acquires, and intent broadcasts. arate modules. Function-call hooking happens by match- Because of the way Android handles alarms, our imple- ingthemethod’snameandsignatureofthedeclaredcall- mentation can only curtail the alarm’s callback payload.

For brevity reasons, we refer readers to []foranexplanationonhow e system will still periodically wake up according to the such thing is possible. alarm’s schedule, but will immediately return to sleep. Our

USENIX Association 2015 USENIX Annual Technical Conference 567 Event Class Method Instrumentation Payload Searchforpolicy.Iffound,earlyreturn in case call happens before grace acquireWakeLockInternal period. Else, let acquire proceed; Wakelock com.android.server.PowerManagerService bookkeep wakelock and start grace-period timer. Only called if there was no block; releaseWakeLockInternal report how long wakelock was held. Searchforactivepolicy.Proceedasin Service com.android.server.am.ActivityManagerService startServiceLocked wakelock case. Add reference to API-registered registerReceiverInternal android.app.ContextImpl receiver. BroadcastReceiver Remove reference to API-registered unregisterReceiverInternal receiver. Add reference to receiver registered addActivity com.android.server.pm.PackageManagerService statically. Remove reference to receiver removeActivity unregistered statically. Search for active policy. Temporarily remove receiver from framework index com.android.server.am.ActivityManagerService broadcastIntentLocked to prevent event broadcasts. Update stats. Searchforactivepolicy.Proceedasin Alarm com.android.server.AlarmManagerService triggerAlarmsLocked wakelock case. requestLocationUpdates Enable GPS throttling for calling app. android.location.LocationRequest GPS (See § .) removeUpdate Disable GPS throttling for calling app. Search for active policy. Let callback report incoming location, but com.android.server.LocationManagerService reportLocation temporarily switch off GPS sensor for blocking period.

Table : A brief description of T ’s instrumentation points. controller implementation covers all versions of Android life of the GMS-based installation. We then investigate ranging from Ice Cream Sandwich to KitKat.Inahand- how T can eectively mitigate energy bugs, a sys- ful of occasions, we resorted to dierent instrumentation tem behavior that causes unexpected heavy use of energy points for a given event, mostly due to small dierences not intrinsic to the desired functionality of an applica- in the function signatures between OS versions. Because tion. Next, we show how to use code injection to create the framework interface is fairly stable, covering future specialized versions of controllers for situations that our versions of Android should not require major changes. four-event toolset cannot handle. Last, we measure the overhead caused by T on performance and energy. . Dealing With Google Mobile Services In §, we saw how the inclusion of GMS into the baseline Wakelock

Service AOSP signicantly reduced the battery life of all tested Tamer devices. Nonetheless, GMS adds a series of services and Alarm Intent applications that truly enhance the user’s mobile experience. In fact, most users do not even have the option of Application Framework uninstalling them, as GMS comes pre-installed as a system package in the majority of handhelds. We show how Libraries Android Runtime T 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. Kernel

Event Name Type Count Duration (s) Figure : T sits between apps and the framework stack and NlpWakelock W . NlpCollectorWakelock W . interposes on events between these two. Lower system layers are LocationManagerService W . oblivious to our system. NlpLocationReceiverService S - NetworkLocationService S - Evaluation We evaluate T in four ways. First, we revisit our moti- Table : Top event occurrences for the Galaxy Nexus’ battery vating scenario (§)anduseT to extend the battery drain due to GMS. A handful of events are responsible for the major impact on the battery. W signies a wakelock event, whereas This limitation is due to Xposed’s limited OS support. Support for S stands for service invocation. Android’s latest release (Lollipop) is not stable enough to cover our needs. With the control mechanism established, our next

568 2015 USENIX Annual Technical Conference USENIX Association 100 Pure AOSP 100 Pure AOSP 100 Pure AOSP 100 Pure AOSP w/ Google M. Services w/ Google M. Services w/ Google M. Services w/ Google M. Services w/ GMS + Tamer-15 w/ GMS + Tamer-15 w/ GMS + Tamer-15 w/ GMS + Tamer-15 80 w/ GMS + Tamer-45 80 w/ GMS + Tamer-45 80 w/ GMS + Tamer-45 80 w/ GMS + Tamer-45 60 60 60 60 40 40 40 40 20 20 20 20 Battery Level (%) Battery Level (%) Battery Level (%) Battery Level (%) 0 0 0 0 0 20 40 60 80 100 120 140 0 20 40 60 80 100 120 140 160 0 50 100 150 200 250 300 350 0 50 100 150 200 250 Hours Hours Hours Hours (a) Galaxy Nexus (b) Galaxy S (c) Fire (d) MeMO Pad

Figure : Battery drop for the four devices while idling with the screen o. Aer 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- causesucherrorsmaynotresultinacrash,userswillonly pact of events originating from or destined to GMS. Ta- notice their eect when it is too late: an early dead battery. ble ranks the top triggered events reported by T ’s Dierently from previous research which identied and monitoring module. For wakelocks, we also report the characterized energy bugs [ , ], in our evaluation we time they were held. We use event frequency as an focus on mitigating them at runtime. T allows users heuristic to guide policy conguration. We note that to run the oending applications without the adverse ef- NlpCollectorWakelock was primarily responsible for fects of the bugs. Finding ebugs is not trivial and the lack keeping the system awake in the background. Online re- of a centralized repository of updated samples prevents ports [ , ] indicate that NlpCollectorWakelock is re- us from testing our controller more extensively. We suc- lated to Location Reporting, an Android feature to cessfully reproduced and circumvented three application estimate and report the current location based on WiFi ebugs described in []. For the other described cases, we APs and cell-tower signals. Apps that use this feature in- could not conrm the existence of bugs. We assume these clude Google Now and Google Maps, among others. e defects have been xed by developer updates. other frequently reported events are also related to the Next, we present two detailed case studies of new ebugs same feature. Disabling location reporting on the device’s that we found. To identify them, we used eStar [], a tool Settings menu would be a logic solution to increase sleep that ranks the contribution of apps to battery depletion. We time, if dependent apps did not stop working. rst selected apps that display poor energy eciency and e problem with NlpCollectorWakelock and asso- ltered them based on high popularity at the Google Play ciated events is the frequency they wake up the system and Store (our two selections featured on the top- ranking of keep it awake, which sums to a substantial period of non- their respective categories: Games and Health & Fitness). sleepiness. During a discharge period of hours for the Although eStar ranks energy-inecient apps, we still had Galaxy Nexus smartphone, NlpWakelock was called once to manually verify whether such ineciency was due to a minute on average, whereas NlpCollectorWakelock foreground or background activity. For each application, contributed to keeping the system awake for more than we simulated a user interaction consisting of a short-length one hour. Such a high battery impact coming from a single active session followed by a long period in the background. package does not justify the benet of having GMS run- Bejeweled Blitz [] is an award-winning puzzle game ning as it is in the background. For this reason, we devised with over million installs from Google Play Store. Aer two policies for GMS, targeting NlpCollectorWakelock a -minute play session on the Galaxy S smartphone, and its associated events, to alleviate this wakeup burden. T reported that our game generated a single back- For each wakelock and service in Table ??,therstpol- ground event – the acquire of the AudioIn wakelock. Be- icy (Tamer-) allows a single call every minutes. e cause games are resource-hungry apps, this event call ini- second policy (Tamer- ) allows one call every min- tially did not instigate any suspicion. We discovered a red utes. Deciding on an appropriate rate is a subjective matter. ag, though, aer switching Bejeweled to the background: Our setup tries to reach a balance between informing sub- AudioIn was not released aer the game suspension. To ordinate apps of location updates and increasing battery mitigate this bug, we wrote a simple policy targeting Bejew- lifetime. Figure shows that our policies substantially re- eled Blitz that blocks the renewal of the culprit wakelock duced the battery-drain rate of all tested devices. during background time. Figure depicts the battery drop of a -hour session with Bejeweled loaded in the back- . Chasing Energy Bugs ground before and aer applying our policy. We see a An energy bug, or ebug, is a system error either in an improvement on battery drain. Figure conrms the eect application, OS, rmware or hardware that causes an un- of releasing the ill-behaved wakelock: before being tamed×, expected amount of high energy consumption []. Such the smartphone spent approximately % of the time with errors occur due to a variety of reasons such as program- an awake CPU. With T ’s interposition, most of the ming mistakes, faulty hardware, malicious intent, etc. Be- residency ratio was converted to deep sleep.

USENIX Association 2015 USENIX Annual Technical Conference 569 100 100

80 80

60 60

40 40

Battery Level(%) 20 Battery Level(%) 20 Normal Normal Tamed Tamed 0 0 0 2 4 6 8 10 12 0 1 2 3 4 5 6 7 8 Hours Hours

Figure : Battery drain over hours for Bejeweled Blitz without Figure : Battery drain over hours for Nike+ Running without T (Normal) and with a T policy blocking the AudioIn T (Normal) and with a T policy that blocked all ve wakelock. In both cases, the game was started and the phone held wakelocks. In both curves, the app was started and the phone switchedtoidlemodewiththescreeno. switchedtoidlemodewiththescreeno. 100 100 Normal Normal 80 Tamed 80 Tamed 60 60 40 40 20 20 % of Time Spent % of Time Spent 0 0

384 MHz486 MHz594 MHz702 MHz810 MHz918 MHz1.03 1.13GHz 1.24GHz 1.35GHz 1.46GHz 1.57GHz 1.67GHz 1.78GHz 1.89GHz GHz 350 MHz 700 MHz 920 MHz 1.2 GHz Deep Sleep Deep Sleep CPU Frequency CPU Frequency

Figure : CPU residency time for the original and tamed versions Figure : CPU residency time for the original and tamed versions of Bejeweled Blitz on the Galaxy S. e tamed version spent of Nike+ Running on the Galaxy Nexus. e tamed version spent % of the time in Deep Sleep. .% of the time in Deep Sleep.

Nike+ Running []isatnessappfortrackingruns. continuation. One can say that T focusesontheef- Nike+ relies on the GPS sensor, the accelerometer, and fect of an event. Still, there are situations in which the barometer to estimate distance and speed. According to energy cost of its cause is signicant. A user could write a T , Nike+ acquired ve wakelocks while running: policy targeting an instant messenger’s broadcast receiver AudioMix, FullPower Acc Sensor, FullPower to throttle the eect of a message arrival – a notication Pressure Sensor, FullPower Recording and intheformofsoundorvibration.However,shecannot NlpWakeLock. Judging from the wakelock names, we block the message arrival itself, the major contributor to can assume a few hardware components remained awake energy consumption in this case, as the remote sender is to prevent device-sleeping. We found an ebug when not covered by T . pausing our running session and switching Nike+ to the Actingonthecauseofaneventiscomplicatedbecause background. In this case, we expected the application to its originator, when known, can take various shapes, like release all wakelocks. Like Bejeweled Blitz, Nike+ forgot a disk or network I/O operation. Consequently, nding to relinquish the locks upon leaving the foreground. Our a converging instrument point in the source code that policy was also equivalent: block the culprit wakelocks encompasses all such shapes is complex. In parallel, we during background time. Figure shows the battery drop shouldavoidpointsolutionsthatonlytoneapp.Between aer an eight-hour session before and aer applying our these two extremes, we can reach a balance by instrument- policy.Weseea improvement on battery drainage. ing code that abstracts common functionality and gener- Figure displays the CPU residency on both scenarios: ates events used by a subset of applications. We consider CPU deep-sleep residency× jumped from a % to .%. the case of navigation apps to illustrate such scenario. We also acknowledge a major contribution of the GPS rottling Localization. Android applications that rely and sensors to battery decay. eir duty cycle is equivalent on the GPS sensor follow a basic model: () they register a to the time the homonymous wakelocks were held. position listener and () they periodically receive location updates from a provider proxy, the only interface to the . Looking at the Other Side of Events localization system []. A provider proxy serves as an T can block events at their imminent arrival or dis- interface to various location sources, including the GPS patch, thus saving energy that would be consumed by their sensor, WiFi APs, and cell towers.

570 2015 USENIX Annual Technical Conference USENIX Association Given that the GPS is an energy-hungry resource, we 800 consider a throttling mechanism for its duty cycle. Paek et 700 al. [ ] successfully demonstrated the potential energy sav- 600 ings of duty cycling by creating a rate-adaptive positioning system that switches the GPS sensor on and o and uses 500 1s-rate Policy alternative location sources based on position accuracy. 400 5s-rate Policy 15s-rate Policy As a demonstration, we consider a simpler GPS-throttling 300 implementation sans secondary sources. An advantage of Total Energy (J) 200 our approach is the dispensing of OS recompilation, keeping it compatible with the majority of Android devices. 100 0 e GPS sensor provides periodic position xes (every Maps Nike+ second) to the OS. Some of these xes are not relayed by the Android framework to the navigation app as they are not signicantly dierent. We can reach a more energy- Figure : Total energy consumed by Google Maps and Nike+ ecient navigation by directing the GPS duty cycle. We Running aer applying three dierent duty-cycle policies to the inject code into internal classes related to the framework’s GPS provider. For both apps, the update rate is inversely propor- GPS provider and open a direct communication channel tional to energy savings. between the GPS device and our throttling mechanism. T does not acquire any wakelocks, but freeloads the is direct channel permits our controller to switch the system’s active state from other wakeup sources. GPS on and o. Table summarizes our instrumentation. Evaluation. We consider two location-based apps, Google Related Work Maps and Nike+ Running. We ran these two applications Wearenotthersttoproposecontroloffunctionalityin separately on the Galaxy Nexus phone and applied three exchange for battery savings. T builds upon a number dierent throttling policies to the GPS duty cycle: location of contributions to mobile power management. updates every one, ve and een seconds. e rate choice Collateral Related Work. Ecient power management in depends on the user’s purpose. For pedestrian navigation, mobile platforms is a challenging research problem due a slower update rate does not aect the estimated position to the multitude of hardware congurations and power asmuchasinthecaseofahighwaycartrip.Paeketal.’s states. To improve energy consumption, we need to under- work includes a thorough tradeo analysis between posi- stand how hardware components draw power on behalf tion accuracy and energy savings. We, on the other hand, ofapplications.ereisamyriadoftoolsthathelpquan- only report the potential savings. For each scenario, we tify a device’s energy expenditure. PowerScope []isone programmed a pedestrian route lasting ten minutes. We oftherstworksinthemobiledomaintomapenergy turned the screen o while running the application in the to a program’s structure. PowerScope employs linear re- background. Because of the small timespan, we compare gression and statistical sampling to apportion energy to the energy dispensed instead of battery-level drop. We hardware and applications. A series of recent prolers for usedtheMonsoonmonitortomeasuretheenergycon- smartphones complements PowerScope, including Power- sumption. Figure portrays the savings per application. Tutor [], ARO [ ], AppScope [], WattsOn [] and Weobserveanupperboundof.%onsavingsforthe eprof [ ]. Sesame [] and V-edge [] go a step further Nike+ Running application when reducing the location- and propose self-calibrating models that dispense the use update rate to :s. Although a lower update rate increases of external power monitors, relying instead on internal the energy savings, position accuracy is penalized. battery data to model energy expenditure. Our analysis mainly adopts battery-drop rate as a proxy for energy con- . Performance Impact sumption, but we expect such advanced contributions to Just like a network rewall, T intercepts every event- be integrated by OEMs in future devices. happening, inspects it, evaluates the corresponding policy Saving Energy From Background Tasking. Android task criterion, and nally actuates to fulll the policy’s condi- killers once were the solution for background power tions. Because T diverts the normal ow of applica- savings, but their eectiveness is now a point of con- tions, it should incur as little performance overhead and tention []. Task killers force background applications energy burden as possible. We instrumented T to to quit, assuming that their removal from memory will measure the time taken to hijack an event and perform its reduce the energy footprint of released resources. Such blockage. For the longest diverted execution ow, T assumption is incorrect as there is little correlation be- took, on average, µs to execute on the Galaxy Nexus tween memory and CPU usage in Android []. Excessive device. With regards to energy consumption, T is task killing may lead to the opposite eect: by discarding activated only when other applications generate events. cached data, Android must reload apps from storage. A

USENIX Association 2015 USENIX Annual Technical Conference 571 killed app may restart itself immediately a er being killed, possible to determine whether the energy used by an appli- using up CPU time and draining even more battery. cation deviates from its expected consumption. ese tools Rather than killing background tasks, popular apps like are conservative in controlling energy expenditure, with JuiceDefender [] and Easy Battery Saver [] can cong- both systems suggesting users to kill or uninstall culprit ure the access to power-greedy components, such as the apps. eStar further recommends energy-ecient alterna- radio and GPS, on a schedule basis. Although eective in tives to power-hog apps, if they exist. T let users keep many cases, some apps do not behave properly when they their apps while modifying the culprit’s behavior to reduce cannot, for instance, connect to the Internet. Some apps energy consumption. may even produce more energy overhead as they insist on accessing a resource made unavailable. T circum- Discussion vents such problems by mainly throttling asynchronous As any prototype, T has limitations. T ’s main actions: the expecting app does not block while waiting utility comes from policy denition, which, at its current for an event arrival or dispatch. Greenify []isanAn- state,willnotappealtotheenduser.Inthefollowing,we droid tool for hibernating apps, preventing the arrival or elaborate on how to circumvent this usability issue. We dispatch of events once an app switches to background. also suggest improvements that are le as future work. e original functionality is only restored when the app returns to the foreground. Greenify is eective in block- . Policy Guidelines ing misbehaving and start-at-boot apps, but its treatment In §, we demonstrated how a wise policy selection can of background computing is coarse and not applicable partially inhibit the surge of energy-hungry events. Our to notication-based apps that mostly run in the back- experience dening policies arose from intuition, reading ground (e.g., mail readers, instant messengers, calendars, source code (when available) and, in some cases, multiple etc.) T is applicable in such cases as it throttles, but attempts. At its current state, T would better serve does not completely eliminate, background functionality. as a backend for higher-level power management tools Android also includes its own controls for background- than as an end-user app. With such limitations in mind, a task management. e AutoSync feature controls the au- user willing to run T asitis,wouldbenetfromthe tomatic data synchronization between client apps and on- following guidelines to explore the event space and dene line accounts. With a mere tap, users can choose between eective policies. disabling the synchronization of a specic feature of a Choosing events to control. Handhelds may carry tens selected account (e.g., photo uploads for Google+) or to- or even hundreds of applications that generate thousands tally prevent any background synchronization for all reg- of events. We should not imply that policy denition must istered accounts. AutoSync is mostly applicable to apps consider all of them equally. First, users prefer some apps adopting Google Cloud Messaging (GCM), an API piece over others. Second, event triggering does not follow a uni- from Google Mobile Services. GCM provides a lightweight form distribution. As a rule of thumb, users should start mechanism that third-party servers can use to notify mo- with policies targeting the most frequent events. T ’s bile applications of available content to be fetched. As long monitoring module periodically outputs an event sum- as the application is subscribed to receive GCM messages, marythatcanassistinsuchcases. the Android device does not need to run continuously. Cutting the red wire. Even a er selecting the most promi- Instant messengers, for instance, use GCM to receive noti- nent events for policy testing, there are no guarantees that cations of new incoming messages. T complements the policy will work without side eects. Side eects may this service by oering a similar control to applications include an increase in the frequency of correlated events, that do not adopt the GCM approach. Moreover, T the rise of unexpected events, and abnormal application be- allows for the management of a variety of background havior. Blocking alarm events recklessly could, for instance, events, whereas AutoSync focuses mainly on networking. totally defeat the purpose of a calendar app. Because most Partial inspiration for deep event monitoring stems apps are only available in binary form, understanding the from applications such as BetterBatteryStats [] and purpose of an event is not always clear and neither is un- Wakelock Detector []. Both apps report wakelock-usage covering its dependencies. Techniques used in black-box statistics that developers can use to understand the root testing, such as cause-eect graphs can help. Events may cause of battery drainage. T complements such apps also show a temporal correlation with others. To uncover by empowering users to take action a er they pinpoint the temporal dependency, we generated event timelines from origin of abnormal energy consumption. T ’s monitoring output. Carat [] and eStar [] use data collected from thou- Use common sense. e Android OS denes two cate- sands of smartphone and tablet users to model the battery gories of applications: system and user. e former in- drainage of applications. By combining rich context infor- cludes programs that are deemed critical, are deeply in- mation of multiple devices with energy awareness, it is tegrated into the OS, and cannot be uninstalled. Exam-

572 2015 USENIX Annual Technical Conference USENIX Association ples include the dialer, browser, and network manager, to ing their processing in chunks aer the device wakes up name a few. Users apps are replaceable programs that can to handle phone calls, noti cations and other interrup- befreelyremovedandinstalledfromtheappstore.As tions. Windows Phone enforces background tasks to be part of T ’s design, we adopted the support of generic lightweight by applying quotas to resources like CPU, mem- events. Consequently, system- and user-app events are ory, and network usage while apps are running behind the treated equally. Policies that alter the frequency of sys- scenes []. Event-frequency control may not produce tem events may result in unwanted or abnormal behavior. the same gains on Apple’s and Microso’s mobile devices Users should be mindful when de ning policies involving given their stricter stance on deploying background tasks critical events to avoid such situations. Removing support (mainly in the name of battery savings). for system events would prevent such unfortunate occa- Feedback control. T works as an open-loop con- sions, but the de nition of a system app is blurry. GMS, troller, not using feedback to gauge whether the system for example, comes pre-installed as a system package on needs more adjustments. During the design stage of this many devices. Carriers also sell devices with bloatware project, we discarded the closed-loop approach as it would installed as system apps. As demonstrated, systems apps require knowledge of application semantics as well as user present great opportunities for energy savings. perception of performance degradation. Modeling these two elements are hard problems beyond our scope. . Potential Improvements Conclusion Event batching over cancellation. Our current implementation dismisses event continuation if there is a need is paper presented T , an OS mechanism that infor throttling. Alternatively, we could reschedule the asyn- terposes on task wakeups in Android and allows event chronous delivery of such events to coalesce multiple wake- handling to be monitored, ltered, and rate-limited. We ups into one, saving even more energy. Although promis- demonstrated that T substantially reduces the back- ing, event coalescing may lead to unexpected results that ground energy use in popular Android applications. With require deeper investigation. Some apps assume a xed fre- T , a device spends more time in low-power mode, quency of events. A pedometer may use the time dierence which increases the battery lifetime signi cantly. between position xes to estimate speed. Batching multi- While this work shows T ’s eectiveness as a mech- ple xes into one delivery may create havoc if the tracker anism, future work is needed to understand how to best does not discard outdated values. Nevertheless, coalescing construct policies that improve battery life while preserv- has found its way in other domains. e Linux tickless ing application functionality. In future work, we will in- kernel [] reduced the precision of soware timers to al- vestigate techniques for determining if functionality is low the synchronization of process wakeups, minimizing negatively impacted when exploring user visible elements the number of CPU power-state transitions. From its Lol- (e.g., UI dierences) between runs of an application with lipoprelease,Androidstartedtobatchalarmsthatoccur dierent policies. We will also explore which policies are at reasonably similar times, turning them inexact. Xu et most likely to have substantial battery savings in practice. al.’s recent work on coalescing events to save energy in the With the combination of such techniques, we will strive context of email synchronization [] is another success- to devise policies that improve battery life while retaining ful example of careful event-handling for mobile devices. normal application functionality. As long as developers do not assume guarantees on event Acknowledgements delivery and commutativity, we believe coalescing should We thank Tim Nelson, Hammurabi Mendes, the anony- supersede cancellation as an energy-saving feature. mous reviewers, and our shepherd, Lin Zhong, for their Native code support. T controls applications by feedback. Marcelo was funded in part by a generous gi wrapping function calls from the Android Java API. Ap- from Intel Corporation. plications that make heavy use of native code, like games, multimedia apps and ELF libraries, could acquire wakelocks, spawn threads and perform background tasks using C/C++ code, thus bypassing our control system. Extend- ing support to native code would require a similar eort on analyzing and instrumenting libc function calls. Support for other mobile OSes. Background processing is not exclusive to Android, although handled dierently by other mobile OSes. Apple’s iOS + regards background processing as a privilege []. Other than network trans- fers, common background tasks have limited time to completion and must respect the device’s will to sleep, do-

USENIX Association 2015 USENIX Annual Technical Conference 573 References [ ] E , W.,G , P.,C , B.-G., C, L. P.,J , [ ] E T. Easy Battery Saver. http://www. J., MD, P., S , A. N. TaintDroid: 2easydroid.com. An information-ow tracking system for realtime privacy monitoring on smartphones. In USENIX [] A D. Best practices for back- OSDI’ . https://developer.android.com/ ground jobs. [ ] F , O. Greenify. https://play.google.com/store/ training/best-background.html . apps/details?id=com.oasisfeng.greenify. [] A D. Location strategies. [ ] F, J., S, M. Energy-aware https://developer.android.com/guide/topics/ adaptation for mobile applications. In ACM SOSP’. location/strategies.html. [ ] F, J., S, M. PowerScope: [] A D. Managing your app’s A tool for proling the energy usage of mobile appli- memory. https://developer.android.com/training/ cations. In IEEE WMCSA’. articles/memory.html. [ ] G . Google’s killer Android L feature: Up [] AC.. Google Services battery to % more battery life thanks to Project Volta. drain. http://forums.androidcentral.com/google- http://gigaom.com/2014/07/02/googles-killer- nexus-4/302559-google-services-battery- android-l-feature-up-to-36-more-battery-life- drain.html. thanks-to-project-volta. [ ] G . Battery Historian. https://github.com/ [] A, J., D, C., H, A. V. H., L, O., google/battery-historian. N , J. Cells: A virtual mobile smartphone architecture. In ACM SOSP’ . [] G . Our mobile planet. http://think. withgoogle.com/mobileplanet/en. [] A I. App programming guide for iOS. https://developer.apple.com/ [ ] H, H., S , S., C , M., M- library/ios/documentation/iPhone/ , S., A , A R, M. Conceptual/iPhoneOSProgrammingGuide/ Dynamic knobs for responsive power-aware comput- BackgroundExecution/BackgroundExecution. ing. In ASPLOS’ . html. [] J , W., K , C., Y, C., D , K., [] ARM L. big.LITTLE technology: e future C , H. AppScope: Application energy metering of mobile. http://www.arm.com/ﬁles/pdf/big_ framework for Android smartphone using kernel ac- LITTLE_Technology_the_Futue_of_Mobile. tivity monitoring. In USENIX ATC’ . pdf. [] K, K., C , H. WakeScope: Runtime wakelock anomaly management scheme for Android plat- [] AT&T. Application resource optimizer (ARO). form. In ACM EMSOFT’ . http://developer.att.com/application-resource- optimizer. [] K, W., G, M. S., W, G.-Y., B , D. System level analysis of fast per-core DVFS using [ ] C M C. http: on-chip switching regulators. In IEEE HPCA’. //www.cyanogenmod.org. [] K, S. BetterBatteryStats. https: [ ] D , M., S , S., P , Y., S , A., //play.google.com/store/apps/details?id= W , D. S. QUIRE: Lightweight provenance com.asksven.betterbatterystats. for smart phone operating systems. In USENIX Secu- [] L. JuiceDefender – battery saver. http: rity’ . //www.juicedefender.com. [ ] D , M., Z , L. Self-constructive high- [] LH .. Android task killers explained: rate system energy modeling for battery-powered Whattheydoandwhyyoushouldn’tusethem.http: mobile systems. In ACM MobiSys’ . //lifehacker.com/5650894. [ ] E A I. Bejeweled Blitz. [] M. Supporting your app with background http://play.google.com/store/apps/details? tasks. https://msdn.microsoft.com/en-us/library/ id=com.ea.BejeweledBlitz_na. windows/apps/xaml/hh977056.aspx.

574 2015 USENIX Annual Technical Conference USENIX Association [ ] M , R., K, A., C, R. Empow- Android/comments/1rvmlr/nlpwakelock_and_ ering developers to estimate app energy consumption. nlpcollectorwakelock_discussion/. In ACM MobiCom’ . [] . Xposed development tutorial. [] M E LCC. eStar: Because mobile https://github.com/rovo89/XposedBridge/ devices are not mobile if they are plugged in. http: wiki/Development-tutorial. //mobileenerlytics.com. [ ] . Xposed module repository. http://repo. [] M S I. Power monitor. http:// xposed.info. www.msoon.com/LabEquipment/PowerMonitor.

[ ] N , I. Nike+ Running. http://play.google.com/ [] R, A., R , S. M., S , R., L , P., store/apps/details?id=com.nike.plusgps. M , D., Z , N. Energy management in mobile devices with the Cinder operating [] O , A. J., I, A. P., S , I., L , system. In EuroSys’ . E., T , S. Carat: Collaborative energy [] S , S., P , V., V D V, A. Get- diagnosis for mobile devices. In ACM SenSys’ . ting maximum mileage out of tickless. In Ottawa Linux Symposium’. [] P, J., K , J., G , R. Energy- ecient rate-adaptive GPS-based positioning for [] U A. Wakelock Detector. https: smartphones. In ACM MobiSys’ . //play.google.com/store/apps/details?id= [] P, A., H, Y. C., Z, M. Bootstrap- com.uzumapps.wakelockdetector. ping energy debugging on smartphones: A rst look at energy bugs in mobile devices. In ACM HotNets’ . [] V , P., J, R., L, S., A, Y. Towards verifying android apps for the absence of [] P, A., H, Y. C. H., Z, M. Fine no-sleep energy bugs. In HotPower’ . grained energy accounting on smartphones with eprof. In EuroSys’ . [] X, F.,L , Y.,L , Q., Z, Y. V-edge: Fast self- constructive power modeling of smartphones based [] P, A., J , A., H, Y. C., M , S. P. on battery voltage dynamics. In USENIX NSDI’ . What is keeping my phone awake? characterizing and detecting no-sleep energy bugs in smartphone apps. [] X, F., L , Y., M , T., C, R., J , In ACM MobiSys’ . L., Z, Y., L , Q. Optimizing background email sync on smartphones. In ACM MobiSys’ . [] Q , F., W, Z., G, A., M, Z., S, S., S, O. Proling resource usage for [] Z, H., E , C. S., L, A. R., V- mobile applications: a cross-layer approach. In ACM , A. ECOSystem: Managing energy as a rst class MobiSys’ . operating system resource. In ASPLOS’. [] Q . Trepn Proler. http://developer. qualcomm.com/mobile-development/increase- [] Z, L., T , B., Q , Z., W, Z., D , app-performance/trepn-proﬁler. R. P., M, Z. M., Y, L. Accurate online power estimation and automatic battery behavior [] R . NlpWakeLock and NlpCollectorWake- based power model generation for smartphones. In Lock discussion. https://www.reddit.com/r/ CODES+ISSS’ .

USENIX Association 2015 USENIX Annual Technical Conference 575