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 proling 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 proling 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 notications of specied 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 specic 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- signicantly 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 dierent 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 eective 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 eective, 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 dierence 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 eect due to excessive wakeups. Because this mech- highlighting energy-inecient programs, can only oer 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 oers the possibility of much ner-grained con- the components constituting a mobile app and how appli- trol