Application Modes: A Narrow Interface for End-User Power Management in Mobile Devices Marcelo Martins Rodrigo Fonseca Brown University ABSTRACT fect, is an energy-proportional system [ ]. Although necessary, these Achieving perfect power proportionality in current mobile devices are not sucient to solve the increasing energy-decit problem, be- is not enough to prevent users from running out of battery. Given cause they have no eect when there is active demand for resources. a limited power budget, we need to control active power usage, and To reduce the active demand, there must be a prioritization of there needs to be a prioritization of activities. In the late ÔÀÀýs, Flinn functionality. In the late ÔÀÀýs, Ellis [,òÞ] recognized that the of- and Satyanarayanan showed signicant energy savings using a con- fered workload has to be changed by user-driven prioritization and cept of data delity to drive mobile application adaptation, informed lifetime goals, and Flinn and Satyanarayanan established, with the by the battery lifetime desired by the user and the OS’s evaluation Odyssey system, that application adaptation can provide substan- of energy supply and demand. In this paper we revisit and expand tial energy gains [Ôý, Ôâ]. In Odyssey, applications automatically and this approach, recognizing that with current hardware there are even dynamically change their behavior to limit their energy consump- higher potential savings, and that increased diversity in applications, tion and achieve user-specied battery lifetime, guided by the op- devices, and user preferences requires a new way to involve the user erating system. e adaptation involves a trade-o between energy to maximize their utility. We propose Application Modes, a new ab- use and application data quality, which they called delity. Fidelity straction and a narrow interface between applications and the OS is application-specic and opaque to the OS. e role of the OS is that allows for a separation of concerns between the application, the to direct the adaptation based on its evaluation of the supply and OS, and the user. Application Modes are well suited to eliciting user demand of energy, and their relation to the expected battery dura- preferences when these depend on multiple dimensions, and can tion. When the OS detects the lifetime goal as unachievable, it issues vary between users, time, and context. Applications declare modes upcalls to applications so they reduce their delity. e user inputs – bundles of functionality for graceful degradation when resource- two pieces of information: the desired lifetime, and a prioritization limited. e OS uses these modes as the granularity at which to pro- of applications to order their adaptation, whereas application devel- le and predict energy usage, without having to understand their se- opers are responsible for implementing dierent delity levels. mantics. It can combine these predictions with application-provided Flinn and Satyanarayanan were the rst to simultaneously involve descriptions, exposing to the user only the high-level trade-os that the OS, the applications, and the user in power management, and they need to know about, between battery lifetime and functionality. many factors in today’s environment make it opportune to revisit and extend their approach, which we do in this paper. Due to a combination of more complex applications, multiple devices, and 1. INTRODUCTION a diverse user base, in some cases there is no single delity metric Battery life has been a fundamental limitation in mobile devices that is common to all users in all contexts, making automated ap- for as long as they have existed, despite a vast body of literature proaches to adapt some applications ineective. Furthermore, given on power management extending back almost two decades (§â). In advances in hardware and in lower-level soware (e.g., ACPI), de- fact, increasingly demanding applications greatly exceed the aver- vices are much more ecient when idle, making higher-level ap- age power draw that would be required for batteries to last through proaches that reduce active demand much more eective now than a typical charging period [À,ò ]. a decade ago. ere is a wide spectrum of proposed solutions for power man- In [Ôý], as in [Ôò], a fundamental assumption is that there is a agement. A rst class of solutions deals with the management of well-dened trade-o between delity (or QoS) and energy use. is idle-resource power, by automatically switching hardware compo- means that an application developer knows the app congurations nents to low-power states when not in use. ese include timeout that lie in the Pareto frontier of this trade-o, enabling an automated policies for hibernation, suspending disks, displays and radios; and algorithm to decide the state based on the available energy. CPU voltage and frequency scaling. e outcome, if these are per- Even though this still holds for many applications, this is not al- ways true. As we show in §ò, two users with dierent preferences can have very dierent trade-os between energy usage and utility from an application. e key observation is that in these cases, au- Permission to make digital or hard copies of all or part of this work for tomated adaptation fails, and the runtime system must elicit prefer- personal or classroom use is granted without fee provided that copies are ences from the user. e main challenge is how to involve the user not made or distributed for profit or commercial advantage and that copies at the right time and at the right level. She should only worry about bear this notice and the full citation on the first page. To copy otherwise, to tangible aspects of the device operation, such as lifetime and func- republish, to post on servers or to redistribute to lists, requires prior specific , and not be concerned with how these are implemented or permission and/or a fee. tionality ACM HotMobile’13, February 26–27, 2013, Jekyll Island, Georgia, USA. achieved. Copyright 2013 ACM 978-1-4503-1421-3/13/02 ...$15.00. In this paper we propose Application Modes (§¥), an interface 8 Average between applications and the OS that eases this communication. Median Rather than exposing a metric, applications declare to the OS one or 7 Baseline w/ screen on Baseline w/ screen off more modes, which comprise reductions of functionality with pre- 6 sumed power savings. Modes carry a human-readable description of the resulting functionality, and the promise of switching when 5 requested by the OS. Similarly to previous works [Ôý,ò], we assume 4 that the OS can predict how long the device will last with the appli- cation in each mode, and then request its change when appropriate. Power (W) 3 1.00 However, recognizing that dierent modes may have dierent util- 2 1.32 ities for dierent users, the decision of when to switch modes in- 1.85 volves the user when necessary, by combining the description pro- 1 vided by the application with the predictions of change in lifetime 5.43 0 14.31 provided by the OS. Full Light Dark Audio Written Features Screen Screen Only Directions Figure Ô: Power draw distributions for the navigation app in dierent out- 2. MOTIVATION put/routing settings (cf. TableÔ). e vertical bars show the maximum and In this section we use power measurements with two common minimum power draw, and the boxes the Ôst and çrd quartiles, with the me- smartphone applications — a navigation and a video-recording ap- dian and average indicated. e number to the le of each bar shows the im- plication — to illustrate two main points. First, we conrm and ex- provement in battery usage relative to the “Full Features” scenario. Greater tend earlier ndings by Flinn and Satyanarayanan [Ôý] demonstrat- energy savings can be achieved by reducing the output quality. ing how changes in application behavior can substantially aect en- ergy consumption. Second, using the video-recording application, 8 we show that dierent users can have very dierent Pareto frontiers Average in the utility-energy trade-o, making globally automated decisions 7 Median Baseline w/ screen on ineective to maximize utility. Baseline w/ screen off We measure the power draw of running these applications in very 6 dierent modes, or bundles of settings. We did our measurements 5 on a Samsung Galaxy Nexus running CyanogenMod ICS ¥.Ô.ý. We measured the power draw of the entire phone connecting a Mon- 4 1.00 soon power monitor to the smartphone battery. To discriminate the Power (W) 3 1.04 1.10 energy consumed due to application, we rst measured the energy 1.25 2 consumed by the phone in the idle state, i.e., not running any ap- plications apart from the base system, and established two baselines 1 with the screen on and o. We kept the screen brightness to the same 0 15.58 level for all runs where the screen was on. For navigation, we down- HD SD HD SD Audio loaded data using the çG data connection when needed, and for the Streaming Streaming Recording Recording Recording recording application, we used the WiFi network for data upload. Figure ò: Power draw of dierent modes for the media-streaming app (cf. Tableò). Navigation System Turn-by-turn navigation exercises several hard- ware resources, including the CPU, GPU, audio, networking, and GPS. It is used in sometimes critical situations, when there is little battery le and the user is in need of orientation to arrive at her information like points of interest (POI), at the expense of a larger destination (and a charging opportunity). ere are also interest- power prole. As we reduce the number of enabled settings we can ing trade-os in functionality, utility, and energy use, depending on see a drop in energy expenditure along with a decrease in the qual- which subset of resources the application uses.