Embed Size (px)
Citation preview
APE: An Annotation Language and Middleware forEnergy-Efficient Mobile Application Development
Nima NikzadDept of Computer Science
and EngineeringUniv. of California, San Diego
La Jolla, CA [email protected]
Octav ChiparaDept of Computer Science
University of IowaIowa City, IA USA
William G. GriswoldDept of Computer Science
and EngineeringUniv. of California, San Diego
La Jolla, CA [email protected]
ABSTRACTEnergy-efficiency is a key concern in continuously-runningmobile applications, such as those for health and contextmonitoring. Unfortunately, developers must implement com-plex and customized power-management policies for eachapplication. This involves the use of complex primitives andwriting error-prone multithreaded code to monitor hardwarestate. To address this problem, we present APE, an annota-tion language and middleware service that eases the devel-opment of energy-efficient Android applications. APE anno-tations are used to demarcate a power-hungry code segmentwhose execution is deferred until the device enters a statethat minimizes the cost of that operation. The executionof power-hungry operations is coordinated across applica-tions by the APE middleware. Several examples show theexpressive power of our approach. A case study of usingAPE annotations in a real mobile sensing application showsthat annotations can cleanly specify a power managementpolicy and reduce the complexity of its implementation. Anempirical evaluation of the middleware shows that APE in-troduces negligible overhead and equals hand-tuned code inenergy savings, in this case achieving 63.4% energy savingscompared to the case when there is no coordination.
Categories and Subject DescriptorsD.2.2 [Software Engineering]: Design Tools and Tech-niques—Computer-aided software engineering (CASE);D.3.3 [Programming Languages]: Language Constructsand Features—Constraints
General TermsExperimentation, Languages, Performance
KeywordsMobile applications, energy-efficiency, hardware monitoring,annotations, programming
Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.ICSE ’14, May 31 - June 7, 2014, Hyderabad, IndiaACM 978-1-4503-2756-5/14/06 ...$15.00.
1. INTRODUCTIONThe rapidly advancing capabilities of modern smartphones
have enabled the development of a new generation of con-tinuously-running mobile (CRM) applications, such as thosefor personal health and user-context monitoring. Such appli-cations may periodically wake to collect and process sensordata, check with a remote server for updates, or provide re-ports to a user. Examples include CenceMe [17], Surround-Sense [6], AudioSense [12], and CitiSense [21]. Even thoughthese applications operate at low duty cycles, cumulativelythey have a large impact on the battery life of a device due totheir periodic use of power-hungry system resources, such asthe cellular radio for networking or the GPS for localization.
Even though mobile operating systems like Android pro-vide control over these power-hungry resources, developingan energy-efficient CRM application is challenging. Beyondthe expected algorithmic and systems challenges of design-ing a power management policy (see Section 2), there arealso significant software engineering challenges:
• The code for power management tends to be complex.Not just because the application must actively man-age which resources are required or not, but also be-cause it must manage nuanced tradeoffs between theavailability of resources and desired battery life. Usersare often willing to accept delays in processing or ap-proximations in measurement to increase battery life.Additionally, as will be seen in Section 5.1, power man-agement code is often event-driven and multithreaded.
• Power management optimizations should be postponeduntil the application’s requirements are set. Mobile de-velopers often depend on tight, “agile” developmentcycles in order to elicit feedback from early adopterson basic application behavior. Developing (and cycli-cally revising) complex power management code early-on would slow this cycle.
Thus, while many power-management techniques have beendeveloped, there is no high-level way to access these as lan-guage primitives to specify or implement an application-specific policy for a new application. This paper makes threecontributions:
• We present our system, Annotated Programming forEnergy-efficiency (APE) — a small declarative anno-tation language with a lightweight middleware runtimefor Android (Sections 3.2 and 4). APE enables thedeveloper to demarcate power-hungry code segments
(e.g., method calls) using annotations. The executionof these code segments is deferred until the device en-ters a state that minimizes the cost of that operation.Policies have a declarative flavor, allowing the devel-oper to precisely trade-off delay or adapt sensing al-gorithms to reduce power. The policies abstract awaythe details of event and multi-threaded programmingrequired for resource monitoring.
• We introduce an abstract model of the APE approachbased on timed automata. With this model, a wide va-riety of existing power management techniques can bedescribed, demonstrating both the scope and simplic-ity of the approach (Section 3.1). The model guidedboth our language and middleware design.
• We provide a first evaluation of the APE approach. Weevaluate the expressiveness of the language through (a)a series of policy examples (Section 3.2), and (b) a casestudy of introducing power management into the Ci-tiSense CRM application, both without and with APE(Section 5.1). For the middleware runtime, we showthat an APE-annotated implementation of CitiSensesaves as much power as the hand-tuned implemen-tation, while requiring fewer changes to the originalsource code and having negligible runtime performanceoverhead (Section 5.2).
2. BACKGROUND AND RELATED WORKIn recent years, energy-saving optimizations for mobile de-
vices have been an active area of research. Such work typi-cally falls into one of two categories: low-level optimizationsand system-level optimizations.
Low-level optimizations save energy by judiciously con-trolling the power state of hardware components such as theCPU, radio, flash memory, and sensors (see [7] for a review).Low-level optimizations are implemented as part of devicedrivers, or even in hardware, to ensure that they interactwith the device at time scales comparable to the transi-tion times between power states (typically sub-millisecond).Examples of such policies include dynamic voltage and fre-quency scaling (see [28] for a review), tickless kernel im-plementations [27], low-power listening [24] and scheduledtransmissions for radios [8, 31], and batching of I/O opera-tions for devices such as flash [30].
System-level optimizations interact with the hardware com-ponents on longer time scales and, as a consequence, maybe implemented as part of applications or middleware ser-vices. Three common approaches to system-level optimiza-tions include workload shaping, sensor fusion, and filtering.An example of workload shaping is that of delaying largenetwork operations until a Wi-Fi connection is available, asWi-Fi is typically more efficient than cellular data transmis-sion. Such a policy is found in applications such as GooglePlay Market, Facebook, and Dropbox. Sensor fusion is usedto combine data from multiple potentially heterogeneoussources that have diverse energy costs. Sensor fusion hasfound applications in state-of-the-art localization techniquesthat combine information from GPS, cell towers, Wi-Fi, andBluetooth (e.g., [15]). Power savings are achieved by shift-ing the sensing burden from the high-power GPS sensor tothe other sensors that consume significantly less energy. Inthe same vein, context-recognition frameworks adapt sensing
and networking operations based on the user’s context. Op-timizations found in such frameworks include adjusting theamount of processing applied to sensor data [16], selectinga minimal set of sensors to power [29], and avoiding sens-ing altogether by inferring context based on already-knowninformation [20]. Recent techniques for environmental anduser-context sensing have examined the use of models to fil-ter out collected data, incurring the high cost of processingand transmitting collected measurements only if they devi-ate from expected values [19, 22].
Challenges. In spite of the significant progress madein developing power management policies, energy-efficientapplications remain difficult to develop. A one-size-fits-allapproach fails to yield desirable results as minute differencesin hardware specifications or quality of service requirementsmakes power management policies suboptimal or, in patho-logical cases, leads to energy being spent ineffectively. Thisreality leads developers to include highly customized powermanagement code in their applications. Unfortunately, suchcode is prone to errors [23] because, even when written atthe application level, the developer must still use complex,low-level power management primitives and handle the con-currency required by hardware monitoring code.
What is needed is a general mechanism of encoding powermanagement policies that allows a developer to easily cus-tomize them for new applications. A general model for spec-ifying power management policies may be difficult to deriveas it must encode complex trade-offs between quality of ser-vice and energy consumption. We will show that a timedautomata model meets these criteria: (1) The model allowssimple policies to be composed into more complex ones. (2)More importantly, the complex trade-offs in quality of ser-vice can be effectively expressed as state transitions in thetimed automaton which are triggered by hardware eventsand the passage of time.
Our Approach and Related Work. APE employs anannotation language and middleware runtime that allowsdevelopers to annotate their code to declaratively composepower-management policies from low-level primitives. APEis not a replacement for existing power-saving techniques,but rather facilitates the design and implementation of suchtechniques in real-world applications. APE targets the im-plementation of system-level power optimizations.
The design of APE was inspired by OpenMP [10], an APIand library that facilitates the development of parallel C,C++, and Fortran applications. As an alternative to low-level thread management, OpenMP allows a developer tospecify—using preprocessor directives placed directly in thecode—how tasks should be split up and executed by a poolof threads.
Several other projects have examined the use of annota-tions for code generation [1, 2, 4], verification [14], and driv-ing optimizations [11, 25]. Energy Types allows developersto specify phased behavior and energy-dependent modes ofoperation in their application using a type system, dynam-ically adjusting CPU frequency and application fidelity atruntime to save energy [9]. However, this approach requiresdevelopers to structure their application into discrete phasesand would likely require significant effort to apply to anexisting application later in the development cycle. EnerJallows a developer to specify which pieces of data in theirapplication may be approximated to save energy and guar-antees the isolation of precise and approximate components
[26]. These systems are complementary to our own and maybe used alongside APE. APE is, to our knowledge, the firstsuch system to provide a general and highly-programmableway of expressing runtime power-management policies formobile applications without the need for significant refac-toring.
3. APE DESIGN OVERVIEWAPE is designed to provide developers a simple yet ex-
pressive mechanism for specifying power management poli-cies for CRM applications. Three basic principles underlinethe design of APE:
• APE separates the power management policies (ex-pressed as Java annotations) from the code that im-plements the functional requirements of an applica-tion. This enables developers to focus on correctlyimplementing the functionality of an application priorto performing any power optimizations.
• APE does not propose new power management poli-cies, but rather it allows developers to compose simplepower management policies into more complex onesusing an extensible set of Java Annotations. APE an-notations are both simple and sufficiently flexible tocapture a wide range of power management policies.
• APE insulates the developer from the complexities ofmonitoring hardware state and provides a middlewareservice that coordinates the execution of power man-agement policies across multiple applications for in-creased power savings (compared to when power man-agement is not coordinated across applications).
APE includes an annotation preprocessor and a run-timeenvironment. The preprocessor validates the syntax of anno-tations and translates them into Java code. The generatedcode makes calls to the run-time environment that coordi-nates the execution of power management policies acrossmultiple APE-enabled applications.
The remainder of the section is organized as follows. First,we will introduce the formal model that is used by APE.Then, we present the set of Java Annotations that APEprovides to the developer.
3.1 The APE Policy ModelAPE builds on the following key insight: power manage-
ment policies defer the execution of expensive operations un-til the device enters a state that minimizes the cost of thatoperation. For example, CRM applications reduce the costof networking operations by deferring their data uploads un-til another application turns on the radio. If no connectionis established within a user-defined period of time, the ap-plication turns on the radio and proceeds with the data up-loads. Similarly, an application that maps road conditions(e.g., detect potholes) would collect data only when it de-tects the user to be driving. An energy-efficient mechanismfor detecting driving may be to first use the inexpensive ac-celerometer to detect movement and then filter out possiblefalse positives by using the power-hungry GPS sensor.
To our surprise, this insight holds across diverse power-management policies that involve different hardware re-sources and optimization objectives, as illustrated by theexamples in this section. Nevertheless, the examples also il-lustrate the difficulties associated with developing a general
model for expressing power-management policies. (1) Themodel must capture both static properties of hardware re-sources that may be queried at run-time (e.g., radio on/off)as well as user-defined states that must be inferred usingcomplex algorithms (e.g., driving). Henceforth, we refer tochanges in hardware states or in inference results as applica-tion events. (2) The model must also incorporate a notionof time. The first example illustrates the use of timeoutsto trigger a default action. More interestingly, the secondexample defines a policy where the application should mon-itor for potholes [18] as a sequences of application events(evolving over time): first the accelerometer must detectmovement that is then confirmed by GPS.
APE adopts a restricted form of timed automata to spec-ify power management policies. The automaton encodes theprecondition when an operation O should be executed as asto minimize energy consumption. At a high level, a powermanagement policy is encoded by the states and transitionsof the timed automaton. The timed automaton starts in thestart state and performs transitions in response to applica-tion events and the passage of time. Eventually, a timedautomaton reaches an accepting state that triggers the exe-cution of O.
Formally, APE’s restricted timed automata is a tuple:
TA = (Σ, S, s0, SF , C,E) (1)
where,
• Σ is a finite set of events,
• S is a finite set of states, state s0 ∈ S is the start state,SF ⊆ S is a set of accepting states,
• C is a finite set of clocks, and
• E is a transition function.
The transition e ∈ E is a tuple (c, σ) where c is a clockconstraint and σ is a boolean expression consisting of ap-plication events. The automaton transitions from state sito sj (si
c:σ−−→ sj) when both c and σ hold. In contrast tostandard timed automata [5], in our model, transitions fromthe current state are taken as soon as the required clockconstraints and inputs are satisfied. Additionally, we alsorestrict the expressiveness of clock constraints. Clock con-straints can only refer to a single global clock cG or to asingle local clock cL that is reset each time a transition istaken to a new state. The local clock can be used to im-pose constraints on transitions outgoing from a state, whilethe global clock can be used to impose a time constraint onthe total delay before an operation O is allowed to execute.The above restrictions ensure that the automaton can beexecuted efficiently on resource constraint devices such asmobile phones.
To clarify our APE’s formal model, let us return to theexamples introduced in the beginning of the section.
Example 1: Defer uploads, for up to 30 minutes, untilthe Wi-Fi radio has connected to a network. Figure 1 showsthe automaton associated with this policy. It includes onlytwo states: a start state and an accepting state. Transitionsfrom the start state to the accepting state occur in two cases:(1) when the radio is connected and the global clock is lessthan 30 minutes or (2) the global clock exceeds 30 minutes.Note the expressive power of the automaton to compactly
start
true : WiFi.Connected
cG ≥ 30min : true
Figure 1: Defer uploads, for up to 30 minutes, untilthe Wi-Fi radio has connected to a network.
capture conditions that depend both on applications eventsand time constraints.
Example 2: Defer sensor sampling until the user is driv-ing. Driving is detected by first verifying movement usingthe accelerometer and then waiting for up to 30 secondsfor driving to be confirmed using GPS. Figure 2 shows theautomaton associated with this policy. The automaton in-cludes three states, transitioning from the start state to stateAcc when movement is detected based on readings from theaccelerometer, which is captured by predicate Accel.Move.The automaton transitions to the accepting state from Accwhen driving is confirmed based on readings from the GPS,which is captured by the predicate GPS.Drive.
start Acc
true : Accel.Move
cAcc ≥ 30sec : true
true:GPS.Drive
Figure 2: Defer sensor sampling until movement isfirst detected by the accelerometer and driving isconfirmed using the GPS.
The described formal model allows us to capture a widerange of power management policies. However, a disadvan-tage of using timed automatons as a specification languageis that they are hard to define using simple literals thatmay be included in Java annotations. While experiment-ing with expressing power management policies in APE,we observed that most of policies have a regular structurethat can be captured using a simpler model. The execu-tion of an operation O is deferred until a finite sequence(σ1, t1), (σ2, t2)...(σn, tn) of states holds:
P = ({(σ1, t1), (σ2, t2)...(σn, tn)}, tMaxDelay) (2)
Sequences of conditions (when n > 1) are resolved in order,optionally rolling back and rechecking the previous condition(σi−1, ti−1) if the current condition being checked, (σi, ti),is not satisfied before ti time has passed. Additionally, apolicy may provide an upper bound, tMaxDelay, on the delayintroduced by the policy. Constructing a timed automatonfrom the simple model is a straight-forward process that weomit due to space limitations.
Using this concise notation, the previous two policies canbe expressed as:
P1 = ({(WiFi.Connected,∞)}, 30 min)
P2 = ({(Accel.Move,∞), (GPS.Drive, 30 sec)},∞)
Most policies found in literature and real-world applicationscan also be expressed using APE’s simplified model. For ex-ample, a policy implemented by applications such as Ever-note, Google Play Market, and YouTube, is to delay syncingdata and downloading updates until a Wi-Fi connection isavailable and the device is charging:
({(WiFi.Connected AND Battery.Charging,∞)},∞).
While advertisements in mobile applications are typicallyfetched over the network whenever one is required, an adver-tisement framework could instead display ads from a locallystored corpus that is updated periodically [13]. The policythat manages when updates to the corpus are fetched couldbe described as:
({(Ads.NeedUpdate,∞),
(Net.Active AND WiFi.Connected,∞)},∞).
Batching write requests to flash memory is yet another ex-ample of a power-saving technique for mobile applications.An email client may store newly received emails in memory,writing them out to flash in batches periodically or whenthe number of emails in memory exceeds some threshold[30]. Such a policy could be described as:
({(Batch.Threshold,∞)}, 60 min).
While these examples show that the simplified timed au-tomata model of Equation 2 is able to express a diverse setof real-world policies, this model is not as expressive as thefull model of Equation 1. For example, consider an exten-sion of the driving detection policy in example 2 (See Fig-ure 3). In the extended policy, driving is still detected byfirst monitoring for movement using the accelerometer andthen verifying that the user is driving by using the GPS.However, the policy additionally requires that driving be ob-served continuously for 30 seconds before allowing executionto continue. During this 30 second period, if the accelerom-eter fails to detect motion or the GPS to detect driving, thepolicy immediately returns to the initial state of checking theaccelerometer for motion. This policy cannot be expressedin the simplified model because the transition from the stateAcc to the start state occurs on an event (¬Accel.MoveOR ¬GPS.Drive) rather than on a timeout, as required bythe simplified model.
APE annotations, further discussed in the next section,build on the simplified model as it has a simple textual repre-sentation and captures most of the policies we have encoun-tered. APE may be further extended in the future to providea more complex syntax for expressing power-managementpolicies using general timed automata.
3.2 The APE Annotation LanguageAPE realizes the above model in a small and simple lan-
guage implemented using Java annotations. A preprocessortranslates the annotations at compile time into Java codethat makes calls to the APE middleware runtime (Section 4).
start Acc
true : Accel.Move
true :¬Accel.Move OR ¬GPS.Drive
c Acc≥
30sec:GPS.Drive
Figure 3: Defer sensor sampling until the user isdriving. Driving is detected by first verifying move-ment using accelerometer for 30 seconds and thenconfirmed using GPS.
APE WaitUntil: The APE WaitUntil annotation is thedirect realization of the model syntax and semantics spec-ified above in Equation 2. As such, it prefaces a code seg-ment, and specifies the sequence of application events thatmust be satisfied before execution proceeds to the prefacedcode. For example, the policy from example 1 can be ex-pressed as:
while(true) {@APE_WaitUntil("(WiFi.Connected, inf)", MaxDelay=1800)uploadSensorData();
}
WiFi.Connected is an APE-recognized application eventthat APE monitors on behalf of the application; inf saysthat the local clock constraint is true, i.e., cs < infinity;and MaxDelay=1800 asserts global clock constraint as cG ≥1800 seconds. The parentheses can be dropped when thereis no local clock constraint:
while(true) {@APE_WaitUntil("WiFi.Connected", MaxDelay=1800)uploadSensorData();
}
Similarly, the policy from example 2 can be expressed as:
void startDrivingLogging() {@APE_WaitUntil("({accMove()},inf),({gpsDrive()},30)",MaxDelay=inf)beginSensorSampling();
}
where accMove() and gpsDrive() are local functionsthat encompass logic specific to the application.
With APE_WaitUntil, it is also possible to designateJava code that must be executed before the thread beginswaiting or after waiting has ended:
while(true) {@APE_WaitUntil("WiFi.Connected", MaxDelay=1800PreWait="log(’Started waiting for Wi-Fi...’)",PostWait="log(’Finished waiting for Wi-Fi!’)")
uploadSensorData();}
The optional PreWait and PostWait parameters are usefulwhen an application has to prepare for, or recover from,blocking the annotated thread.
APE If, APE ElseIf, and APE Else: Example 1 canbe further extended to conditionally wait up to 30 minutesfor a Wi-Fi connection if the battery level is greater than70%, or otherwise to wait up to two hours:
while(true) {@APE_If("Battery.Level > 70%")
@APE_WaitUntil("WiFi.Connected", MaxDelay=1800)@APE_Else()
@APE_WaitUntil("WiFi.Connected", MaxDelay=7200)uploadSensorData();
}
The APE If, APE ElseIf, and APE Else annotations allowdevelopers to specify multiple energy-management policiesfor the same segment of code, selecting one at run-time basedon application and device state at time of execution. UnlikeAPE WaitUntil expressions, which block until they evaluatetrue, any expressions provided to an APE If or APE ElseIfannotation are evaluated immediately by the APE runtime,and the selected branch is taken to invoke the appropriatepolicy.
State Expressions and Transitions: TheAPE WaitUntil, APE If, and APE ElseIf annotationseach take as a parameter a boolean expression, consistingof application events, that represents a potential stateof the application and device. Each term used in anexpression must be either a recognized primitive in theAPE language or a valid Java boolean expression. AnAPE term refers to a property of a hardware resource. Forexample, WiFi.Connected refers to the status of Wi-Ficonnectivity. A Java expression included in an annotationis surrounded by curly braces. Terms are joined using ANDand OR operators. As an example:
{requestsPending() > 0} AND
(WiFi.Connected OR Cell.3G)
describes the state where the client application has requestspending and it is either connected to a Wi-Fi or 3G network.The requestsPending() method must be in scope at thelocation of the annotation.
Each of the expressions provided to an APE WaitUntilannotation is a predicate controlling the transition to thenext state in a timed automaton. Consistent with Android’sevent-driven model, APE treats these predicates as events:When in a given state, APE monitors the events necessaryto trigger a transition to the next state. As events arrive,their containing predicate (expression) is reevaluated, and iftrue, it triggers a transition to the next state. Arriving in anew state causes APE to unregister for the last expression’sevents, and to register for the events required to trigger thenext transition. Likewise, event triggers are set up for astate’s local clock; the global clock is its own event trigger,set up when the automaton enters the start state.
The APE compiler must handle two special cases whencompiling an APE annotation, both related to the di-chotomy between events and method calls. (1) When anAPE expression includes a local method call, the methodis periodically polled until its containing expression eval-uates to true, or until the evaluation becomes irrelevantdue to another event trigger. For example, in the case ofthe expression {requestsPending() > 0}, the methodrequestsPending() is periodically polled until its con-taining boolean expression evaluates to true. (2) WhenAPE initially registers for an event, it also makes a di-rect query to the resource of interest to determine if theresource is already in the desired state. For the expres-sion WiFi.Connected, for example, APE both registers forevents regarding changes in Wi-Fi status, and queries Wi-Fito determine if it is already connected. If so, APE imme-
diately evaluates the expression to true. Otherwise, APEwaits for a callback from the system regarding a change inWi-Fi status and rechecks for the Connected condition.
The APE preprocessor performs syntactic checking anderror reporting, with APE terms being checked against anextensible library of terms. The device state primitives sup-ported by APE are specific to each device, but there is astandardized core that encompass the display, cellular, Wi-Fi, and power subsystems of a device and their various fea-tures and states.1 Additional details regarding the efficientimplementation of timed automata semantics and the eval-uation of state expressions are discussed in the next section.
APE DefineTerm: The APE DefineTerm annotationallows a developer to define a new term that can be usedin APE annotations throughout the application. Definingnew terms not only provides for reuse, but also allows non-experts to utilize policies constructed by others. For exam-ple, a new term MyTerm may be defined by:
@APE_DefineTerm("MyTerm", "Battery.Charging AND(WiFi.Connected OR Cell.4G)")
and used to construct APE annotations, such as
@APE_WaitUntil("{requestsPending()} AND MyTerm", MaxDelay=3600)
Any APE recognized primitive or valid Java boolean expres-sion may used in the definition of a new term. Terms do notencode any notion of timing, and are thus not complete poli-cies in themselves, but rather building blocks for higher-levelpolicies.
APE DefinePolicy In addition to defining new terms,developers may define reusable, high-level policies with theuse of the APE DefinePolicy annotation. The difference be-tween a term, defined using APE DefineTerm, and a policyis that a policy may encode timing constraints and transi-tions. Unlike terms, which can be joined together with otherterms to form state expressions, a defined policy represents acomplete state expression. Transitions may be used to chainpolicies together. For example, a new policy MyPolicy maybe defined by:
@APE_DefinePolicy("MyPolicy", "(Display.Off,inf),(MyTerm,10)")
and used to contruct APE annotations, such as
@APE_WaitUntil("MyPolicy,({dataReady()},30)", MaxDelay=3600)
The timing parameters in a defined policy act as defaultsand may be optionally replaced when referencing a policy:
@APE_WaitUntil("MyPolicy(inf,60),({dataReady()},30)",MaxDelay=3600)
For many power-management policies, such as those withouttransitions, simply defining a new term is sufficient.
Annotations are translated at compile-time into runtimerequests to the APE middleware service, discussed in Section4, which is responsible for monitoring device state and re-solving policies on behalf of APE-enabled applications. Javaannotations are simply a form of metadata added to sourcecode, and thus have no impact on application behavior with-out the relevant processor interpreting them during the buildprocess. This feature of annotations means that a devel-oper can experiment with a power-management policy andthen quickly disable it during testing by simply removingthe APE annotation processor from the build process.1APE builds upon Android’s Java hardware API specifica-tion, which standardizes the names and low-level states ofmany components.
4. THE APE RUNTIME SERVICEThe APE runtime is responsible for executing APE anno-
tations from multiple APE-enhanced applications. In thissection we focus on the key design decisions behind the ser-vice and discuss optimizations made to reduce the overheadof executing APE annotations.
The runtime consists of a client library and a middlewareservice. A single instance of the middleware services, imple-mented as an Android Service component, runs on a device.The middleware service is responsible for (1) monitoring forchanges in hardware state and (2) (re)evaluating APE ex-pressions in response to these changes. APE applicationscommunicate with the middleware through remote proce-dure calls (RPCs). The details of RPC, including binding tothe service, parameter encoding, and error handling, are en-capsulated in the client library. Having a single middlewareservice instance has the advantage of amortizing the over-head associated with policy evaluation over multiple appli-cations. More importantly, this approach allows the middle-ware to coordinate the activities of multiple clients for addedenergy savings (shown experimentally in Section 5.2.2).
APE annotations are translated into Java code by theAPE preprocessor prior to compilation. Each policy isconverted into an equivalent integer array representationso as to avoid string processing at runtime. The gen-erated code relies on three functions provided by theclient library: registerPolicy, ifExpression, andwaitForExpression. The registerPolicy function isexecuted during the initialization of the application and reg-isters each APE policy with the middleware through RPCcalls. The middleware service returns a policy handler thatcan be used by ifExpression and waitForExpressionto refer to a particular policy at runtime. RPCs to the mid-dleware are synchronous, blocking the execution of the call-ing application thread until they return. Consistent with themodel described in Section 3.1, each policy is represented asa timed automaton that is executed by the middleware. AnRPC completes when the automaton reaches an acceptingstate. This triggers the return of the RPC and, subsequently,the execution of the deferred application code.
The generated code is split into initialization seg-ments (registerPolicy calls) and policy segments(ifExpression and waitForExpression calls) in orderto reduce runtime overhead. As the overhead associatedwith RPC is dependent on the size of the request, the poten-tially large representations of policies are only transmittedonce to the middleware using registerPolicy calls dur-ing initialization. Runtime policy segments utilize policyhandlers so as to avoid uploading policies to the middlewaremultiple times. As policy handlers are implemented as inte-gers, they add only four bytes to the size of a RPC request,thus minimizing runtime overhead. The overhead associatedwith RPC is further discussed in Section 5.2.1.
For the middleware to execute the timed automatons ef-ficiently, it must track changes in hardware state and up-date the APE expressions in response in an efficient man-ner. The monitoring of low-level device state primitivesis implemented as components called device state moni-tors. Aside from requiring concurrent programming, devicestate monitors are challenging to write because they mustglean information through somewhat ad hoc mechanisms.For example, the connectivity of the cellular radio is deter-mined by periodically polling the ConnectivityManager.
Figure 4: The boolean expression tree representa-tion of a particular APE WaitUntil request. All leafnodes in the tree represent primitives in the expres-sion, while all non-leaf nodes represent operators.
However, to determine whether data is transmitted/re-ceived, the device monitor must register callbacks with theTelephonyManager. Additional connectivity informationmay also be extracted from sysfs – the Linux’s standardmechanism for exporting kernel-level information. Our de-vice monitors provide clean APIs that hide the idiosyncrasiesof monitoring hardware resources.
In response to a registerPolicy call, the middlewaregenerates an equivalent boolean expression tree for each ex-pression. The tree is constructed such that leaves representterms in the expression and non-leaves are AND or OR oper-ators. A node maintains a reference to its parent and anychildren. In addition, a node also maintains a boolean rep-resenting the evaluation of its subtree expression. At a highlevel, the expression trees are evaluated from leaves to theroot. The leaves involve low-level states monitored using thedevice state monitors. These values are propagated up thetree and combined based on the boolean operator (AND orOR). This approach reduces the cost of evaluating expres-sions as changes in low-level state often do not require theentire tree to be reevaluated.
Figure 4 provides an example of a simple boolean expres-sion tree in APE. The arrows indicate the flow of informa-tion during the evaluation of the boolean expression rep-resented by the tree. The tree is evaluated in one of twoways. In the case of ifExpression, the APE service callsa method of the same name on the head node of the tree.When ifExpression is called on a non-leaf node, the nodecalls ifExpression on each of its children and applies itsoperator to the returned values. When ifExpression iscalled on a leaf node, the device monitor associated with thenode returns the current state of the hardware device. Thevalue returned by the method call on the head node is in turnreturned back to the client application, where the result isused to select which policy, if any, should be applied.
In the case of waitForExpression, the APE serviceagain calls a method of the same name on the head node
of the tree. Rather than evaluating all nodes immediately,waitForExpression notifies all leaf nodes to begin mon-itoring changes in device state and starts any necessarytimers. Leaf nodes register for callbacks from the relevantdevice monitor about changes regarding the node’s term. Ifnecessary, threads are created in the client application toperiodically evaluate any local Java code used as part ofan annotation and to communicate the result to the APEservice. Whenever a node receives information that wouldchange the evaluation of its term or operator, it notifies itsparent node of the change. This lazy evaluation of the ex-pression tree from the bottom up ensures that each term andoperator in a state expression is only reevaluated when newinformation that may affect its result is present. To avoidunnecessary message passing and computational overhead,device state monitors only actively monitor the hardwarecomponents necessary to resolve all pending requests fromleaf nodes. When the head of the expression tree evaluatesto be true, or if the tree’s timer expires, all leaf nodes arenotified to stop monitoring changes by unregistering fromtheir corresponding device state monitor. In the case thata policy consists of multiple expressions, the trees are eval-uated in the order that they appear, moving forward to thenext tree once the current tree evaluates true, or returningto a previous tree if the current expression times out. Giventhe synchronous nature of the remote procedure calls, callsto waitForExpression will block the calling thread of ex-ecution in the client application until the call returns, thusensuring the costly operation that follows is not executeduntil the desired conditions have been satisfied.
5. EVALUATIONIn this section we evaluate APE from two perspectives.
First, we present a case study of introducing power manage-ment into the CitiSense CRM application, both with andwithout the use of APE. We then examine the performanceof the middleware runtime and show that APE effectivelyreduces power-consumption by coordinating the workloadsof multiple applications, while requiring fewer changes tothe original source code and having negligible runtime per-formance overhead.
5.1 Case Study: CitiSenseThe authors have developed a variety of CRM appli-
cations, notably CitiSense, which monitors, records, andshares a user’s exposure to air pollution using their smart-phone and a Bluetooth enabled sensor device [21]. Buildingan application that performed all the required tasks withoutdepleting the smartphone’s battery proved challenging, asthe application depended heavily on the use of GPS for local-ization, Bluetooth for sensor readings, and cellular commu-nication to upload measurements to a server for further pro-cessing. Much of the challenge in improving CitiSense arosefrom adding, evaluating, and iteratively revising the appli-cation’s already-complex code base to implement energy-management policies. In this section, we share our expe-rience in implementing a policy for uploading sensor datafrom the CitiSense mobile application to a remote server,providing both hand-coded and APE implementations.
The initial implementation of the CitiSense mobile appli-cation cached air quality measurements on the user’s de-vice and attempted to upload all stored readings once everytwenty minutes. If the loss of connectivity caused a trans-
Thread uploadThread = new Thread(new Runnable() {while(true) {try {Thread.sleep(120000);} catch(InterruptedException e) {}attemptUpload();
}});uploadThread.start();
Figure 5: Example of a naive implementation of sen-sor reading uploading in CitiSense. A thread threadwakes every twenty minutes to attempt uploadingany stored sensor readings before returning to sleep.
Thread uploadThread = new Thread(new Runnable() {while(true) {Intent batt = context.registerReceiver(null,
new IntentFilter(Intent.ACTION_BATTERY_CHANGED));int lvl = batt.getIntExtra(BatteryManager.EXTRA_LEVEL,-1);int scl = batt.getIntExtra(BatteryManager.EXTRA_SCALE,-1);float batteryPct = lvl / (float) scl;try {if(batteryPct > 70){ Thread.sleep(120000); }else{ Thread.sleep(360000); }
} catch(InterruptedException e) {}attemptUpload();
}});uploadThread.start();
TelephonyManager teleManager = (TelephonyManager)context.getSystemService(Context.TELEPHONY_SERVICE);
TransListener transListener = new TransListener();teleManager.listen(transListener,PhoneStateListener.LISTEN_DATA_ACTIVITY);
private class TransListener extends PhoneStateListener {public void onDataActivity(int act) {if(act == TelephonyManager.DATA_ACTIVITY_IN
|| act == TelephonyManager.DATA_ACTIVITY_OUT|| act == TelephonyManager.DATA_ACTIVITY_INOUT) {
uploadThread.interrupt();}
}}
Figure 6: An improved implementation of uploadingin CitiSense that is both battery-life and cellularradio state aware.
mission to fail, then the data would be preserved until thenext upload window. Although timed batching saves energy,the approach still has several drawbacks. Uploads attemptedwhile a user’s phone had a weak cellular network signal oftenfailed, but still incurred high energy consumption during thefailed attempt. Additionally, even if connectivity was avail-able nineteen out of every twenty minutes, the lack of con-nectivity at the twentieth minute mark meant the uploadwould be delayed until the next attempt. For some userswith unreliable cellular coverage, it often took hours beforetheir data was uploaded successfully to the server.
To improve the energy-efficiency and reliability of Ci-tiSense uploads, the application was modified to attempta transmission whenever the phone’s cellular radio was de-tected to already be transmitting or receiving data (See Fig-ure 6). The equivalent timed automaton for this policy ispresented in Figure 7. The concept is that if the phone de-tects that another application on the phone has successfullysent or received data over the cellular radio, then CitiSensewould also likely succeed. Additionally, with radio alreadybeing active, CitiSense would no longer be forcing the ra-dio out of a low-power idle state: the application is taking
start
true:Battery.Level>70%
true:Battery.Level
≤70%
true:Network.Active
cG
>20m
in:tru
e
c G>
60min
:true
true:Network.Active
Figure 7: The equivalent timed automaton for thepolicy implemented in Figure 6.
advantage of other workloads waking the radio, reducing itsimpact on device battery life. In the event that no other ap-plication wakes the radio in a timely manner, CitiSense at-tempts to upload any stored readings after a timeout. How-ever, unlike the static twenty-minute timer used in the firstimplementation, this one varies timeout length based on theremaining battery life of the device. If remaining batterylife is greater than 70% the application waits up to twentyminutes for the radio to become active; otherwise, CitiSensewill wait up to one hour.
Unfortunately, what was once a simple, nine-line imple-mentation now requires querying the Android system forthe status of the battery, registering the application for call-backs regarding changes in cellular data activity in the sys-tem, and implementing a custom PhoneStateListener tohandle callbacks and to interrupt the sleeping upload threadif data activity is detected. Further extending the imple-mentation to be dependent on the state or availability ofother resources, such as a Wi-Fi connection, would requireimplementing additional listeners to handle callbacks andadditional concurrency management. Given the large num-ber and complexity of changes required, prototyping andexperimenting with a variety of potential policies becomestime consuming and burdensome. Even a well-thought-outpolicy can perform poorly in practice and require tweaks ormajor changes.
When we reimplemented this policy in APE, the code col-lapses back to nine lines, with the 19 lines of policy codebeing reduced to three lines of APE annotations:
Thread uploadThread = new Thread(new Runnable() {while(true) {@APE_If("Battery.Level > 70%")
@APE_WaitUntil("Network.Active", MaxDelay=1200)@APE_Else() @APE_WaitUntil("Network.Active", MaxDelay=3600)attemptUpload();
}});uploadThread.start();
The developer-implemented PhoneStateListener, eventhandling, and thread concurrency management are now han-dled by the APE middleware. In this compact, declarative
format, it is now possible to read the policy at a glance, andto attempt variants of the policy quickly.
The APE policy managing uploads can be rapidly ex-tended to also consider the quality of the cellular connectionand the availability of Wi-Fi:
Thread uploadThread = new Thread(new Runnable() {while(true) {@APE_If("Battery.Level > 70%")@APE_WaitUntil("WiFi.Connected ORNetwork.Active AND (Cell.3G OR Cell.4G)",MaxDelay=1200)
@APE_ElseIf("Battery.Level > 30%")@APE_WaitUntil("WiFi.Connected ORNetwork.Active AND (Cell.3G OR Cell.4G)",MaxDelay=2400)
@APE_Else()@APE_WaitUntil("WiFi.Connected ORNetwork.Active AND (Cell.3G OR Cell.4G)",MaxDelay=3600)
attemptUpload();}
});uploadThread.start();
Instead of waiting for simply any cellular network activity,CitiSense now uploads sensor readings only while connectedto a Wi-Fi network or if cellular activity was observed whileconnected to either a 3G or 4G cellular network. The maxi-mum time to wait for such a state was set to be 20 minutesif remaining battery life was greater than 70%, 40 minutesif between 70% and 30%, and 60 minutes if less than 30%.
With the use of APE, the new energy-management pol-icy can be expressed in a total of six annotations. In con-trast, an experienced Android developer implementing thesame policy by hand required 46 lines, including five lines forsuspending and waking threads, three lines to register theapplication for callbacks regarding changes in device statefrom the Android system, and 26 lines and one new classfor handling the callbacks. The thread responsible for up-loading sensor readings is put to sleep until it is interruptedby a different thread which handles callbacks from the An-droid system and determines when all required resources areavailable. Not only is this implementation much longer thanthe APE based implementation, it is significantly more diffi-cult to understand and maintain. This shows that APE notonly represents power management policies concisely, butalso significantly reduces the implementation complexity byremoving the need to write error-prone concurrent code.
5.2 System EvaluationIn this section we evaluate APE by examining the over-
head associated with communicating requests to the mid-dleware service. Additionally, we present power savingsachieved by using APE to implement a simple resource-aware energy-management policy in an application thatmakes regular use of network communication. All exper-iments were run on a Pantech Burst smartphone runningAndroid version 2.3.5. The power consumption of the de-vice was measured using a Power Monitor from MonsoonSolutions [3]. The battery of the Pantech Burst was mod-ified to allow a direct bypass between the smartphone andthe power monitor, allowing power to be drawn from themonitor rather than the battery itself. Traces of this powerconsumption were collected on a laptop connected to thepower monitor over USB. Measurements involving networkcommunication were run on the AT&T cellular network inthe San Diego metropolitan area. Though the Pantech Burstsupports LTE, all experiments were run while operating onAT&T’s HSPA+ network as LTE coverage was not availableat the site of our experiments.
0
5
10
15
20
25
1 3 7 15 31 63 127 191 255 383 511
Time to Resolve (m
s)
State Expression Length
Figure 8: Time to register expressions of variouslengths using registerPolicy. As the size of theexpression grows, the size of the message passed overIPC begins to impact latency.
5.2.1 APE OverheadTo evaluate the overhead associated with using APE,
we examine the time required to complete a simple re-quest to the middleware service. Additionally, we ex-amine the impact of expression length on the latency ofregisterPolicy requests. A simple Android applicationwas built that performed no operations other than to executethe code being benchmarked. The time required to executecode segments was measured by taking the difference be-tween calls to System.nanoTime() placed just before andafter the code segment.
To evaluate the latency overhead associated with usingAPE, we measured the time required to check the currentstatus of data activity on the device using the standard An-droid API and using APE. Checking the current status ofdata activity using the standard Android API was done us-ing the following code:
TelephonyManager telMan = (TelephonyManager)getSystemService(Context.TELEPHONY_SERVICE);
int dataAct = telMan.getDataActivity();
The average time required to execute this code was measuredto be approximately 0.79 ms. Checking the current statususing APE was implemented using the following annotation:
@APE_If("Network.Active")
The average time required to check for data activity usingAPE was measured to be approximately 2.5 ms, meaningapproximately 1.71 ms were spent sending the request to theAPE service over IPC, evaluating a single-term expressiontree, and returning a message to the client application overIPC. Given that a developer would use APE to shape delay-tolerant workloads, we believe that an overhead of 1.71 msis negligible, especially when compared to the time that willbe spent waiting for ideal conditions.
To evaluate the impact of expression length on the timerequired to register a policy, calls to registerPolicy us-ing expressions of various lengths were measured using ourtest application. Expressions were constructed using a chainof Network.Active and AND terms. As observed in Fig-ure 8, the time to register policies remains fairly constant atlower expression lengths. It is only when expressions beginto become longer than 127 terms that the overhead associ-ated with passing large messages over IPC begins to take itstoll. Messages are passed between processes using a buffer
Figure 9: Increase in system power-consumptiondue to the introduction of additional applicationsthat periodically make use of network resources.APE enhanced applications effectively recognizeopportunities to transmit data efficiently, onlymarginally increasing power consumption.
Figure 10: Power consumption (mW) traces from asmartphone device running a variety of naive (top)and APE enhanced (bottom) CRM applications.
in the Android kernel. If messages become sufficiently large,they require additional buffer space to be allocated in thekernel, thus introducing additional latency in resolving re-quests. However, expressions of such length are unlikely toarise in practice as realistic energy-management policies de-pend on significantly fewer application events. In the expe-rience of the authors, most APE expressions tend to be be-tween one and nine terms. As these requests are completedonly once, at the start of an application, their overhead isconsidered acceptable, even at long expression lengths.
5.2.2 Power SavingsTo demonstrate the potential impact of CRM applications
on the battery life of a device, power measurements werecollected from a smartphone running an instance of the Ci-tiSense application, which fetched data from a remote serveronce every two minutes. As a baseline, we measured thepower consumption of the phone, while powering its displayat maximum brightness and running a single instance of Ci-tiSense, to be 865.33 mW. Up to five additional instances ofCitiSense were then introduced to the system. The powerconsumed by these applications when their use of network
resources does not overlap, presented in Figure 9, reached ashigh as 1416.39 mW, a 63.7% increase. This is a worst-casescenario, as there is no coordination with existing workloadson the device to ensure efficient usage of resources.
To demonstrate the potential savings of using APE to im-plement even a simple energy-management policy, the ap-plications were each modified using a single APE WaitUntilannotation to wait up to 120 seconds for the cellular radioto be woken before attempting transmission. As observedin Figure 9, the introduction of this annotation significantlyreduced the power consumption of additional CRM work-loads; adding five additional APE enhanced instances of theCitiSense application increased power consumption by only13.49 mW, or 1.6%. As can be seen in Figure 10, APE is ableto effectively coordinate the workload of the CRM applica-tions to minimize the number of times the cellular radio iswoken and put into a high-power state. If no background ap-plication had been running on the device and transmittingdata, then the first APE enhanced application to timeoutwould wake the radio to transmit its request. The otherAPE applications would then have detected this event andtransmitted at the same time for nearly no additional energycost. This experiment shows that APE provides effectivemeans of coordinating power management across applica-tions to achieve significant energy savings.
6. CONCLUSIONAnnotated Programming for Energy-efficiency (APE) is
a novel approach for specifying and implementing system-level power management policies. APE is based on two keyinsights: (1) Power management policies defer the execu-tion of power hungry code segments until a device entersa state that minimizes the cost of that operation. (2) Thedesired states when an operation should be executed canbe effectively described using an abstract model based ontimed automata. We materialized these insights in a small,declarative, and extensible annotation language and runtimeservice. Annotations are used to demarcate expensive codesegments and allow the developer to precisely control delayand select algorithms to save power.
We showed our approach to be both general and expres-sive, in that it can replicate many previously published poli-cies and that its use reduced the complexity of power man-agement in CitiSense. The APE middleware’s use of tech-niques like code generation, policy handlers, lazy evaluation,and encoding policies as integer arrays kept overhead below1.7 ms for most requests to the service. In our benchmarks,APE provided power savings of 63.7% over an applicationthat did not coordinate access to resources.
Tools for assisting developers in reasoning about appro-priate places to apply APE annotations are currently underdevelopment. We are also exploring the use of a type systemfor designating delay-(in)tolerant data in an application. Auser study of experienced developers will be conducted toexamine how well developers new to APE adapt to usingannotations to express power-management policies.
7. ACKNOWLEDGMENTSThis work was supported by the National Science Foun-
dation (grant nos. CNS-0932403, CNS-1144664, and CNS-1144757) and by the Roy J. Carver Charitable Trust (grantno. 14-4355).
8. REFERENCES[1] AndroidAnnotations.
http://androidannotations.org/.
[2] Google Guice.https://code.google.com/p/google-guice/.
[3] Monsoon Solutions - Power Monitor. http://msoon.com/LabEquipment/PowerMonitor/.
[4] Roboguice: Google Guice on Android.https://github.com/roboguice/roboguice.
[5] R. Alur and D. L. Dill. A theory of timed automata.Theoretical computer science, 126(2):183–235, 1994.
[6] M. Azizyan, I. Constandache, and R. Roy Choudhury.Surroundsense: mobile phone localization viaambience fingerprinting. In Proceedings of the 15thAnnual International Conference on MobileComputing and Networking, pages 261–272. ACM,2009.
[7] L. Benini, A. Bogliolo, and G. De Micheli. A survey ofdesign techniques for system-level dynamic powermanagement. IEEE Transactions on Very Large ScaleIntegration (VLSI) Systems, 8(3):299–316, 2000.
[8] O. Chipara, C. Lu, J. Stankovic, and G. Roman.Dynamic conflict-free transmission scheduling forsensor network queries. IEEE Transactions on MobileComputing, 10(5):734–748, 2011.
[9] M. Cohen, H. S. Zhu, E. E. Senem, and Y. D. Liu.Energy types. In ACM SIGPLAN Notices, volume 47,pages 831–850. ACM, 2012.
[10] L. Dagum and R. Menon. Openmp: an industrystandard api for shared-memory programming. IEEEComputational Science & Engineering, 5(1):46–55,1998.
[11] S. Z. Guyer and C. Lin. An annotation language foroptimizing software libraries. ACM SIGPLAN Notices,35(1):39–52, 2000.
[12] S. S. Hasan, F. Lai, O. Chipara, and Y.-H. Wu.Audiosense: Enabling real-time evaluation of hearingaid technology in-situ. In 26th InternationalSymposium on Computer-Based Medical Systems(CBMS), pages 167–172. IEEE, 2013.
[13] A. J. Khan, K. Jayarajah, D. Han, A. Misra,R. Balan, and S. Seshan. Cameo: A middleware formobile advertisement delivery. In Proceeding of the11th International Conference on Mobile Systems,Applications, and Services, pages 125–138. ACM, 2013.
[14] S. Khurshid, D. Marinov, and D. Jackson. Ananalyzable annotation language. In ACM SIGPLANNotices, volume 37, pages 231–245. ACM, 2002.
[15] M. B. Kjærgaard, S. Bhattacharya, H. Blunck, andP. Nurmi. Energy-efficient trajectory tracking formobile devices. In Proceedings of the 9th InternationalConference on Mobile Systems, Applications, andServices, MobiSys ’11, pages 307–320, New York, NY,USA, 2011. ACM.
[16] H. Lu, J. Yang, Z. Liu, N. D. Lane, T. Choudhury,and A. T. Campbell. The jigsaw continuous sensingengine for mobile phone applications. In Proceedings ofthe 8th ACM Conference on Embedded NetworkedSensor Systems, pages 71–84. ACM, 2010.
[17] E. Miluzzo, N. D. Lane, K. Fodor, R. Peterson, H. Lu,M. Musolesi, S. B. Eisenman, X. Zheng, and A. T.Campbell. Sensing meets mobile social networks: the
design, implementation and evaluation of the cencemeapplication. In Proceedings of the 6th ACM conferenceon Embedded Network Sensor Systems, pages 337–350.ACM, 2008.
[18] P. Mohan, V. N. Padmanabhan, and R. Ramjee.Nericell: rich monitoring of road and traffic conditionsusing mobile smartphones. In Proceedings of the 6thACM Conference on Embedded Network SensorSystems, pages 323–336. ACM, 2008.
[19] M. Musolesi, M. Piraccini, K. Fodor, A. Corradi, andA. T. Campbell. Supporting energy-efficient uploadingstrategies for continuous sensing applications onmobile phones. In Pervasive Computing, pages355–372. Springer, 2010.
[20] S. Nath. Ace: exploiting correlation for energy-efficientand continuous context sensing. In Proceedings of the10th International Conference on Mobile Systems,Applications, and Services, pages 29–42. ACM, 2012.
[21] N. Nikzad, N. Verma, C. Ziftci, E. Bales, N. Quick,P. Zappi, K. Patrick, S. Dasgupta, I. Krueger, T. v.Rosing, and W. G. Griswold. Citisense: Improvinggeospatial environmental assessment of air qualityusing a wireless personal exposure monitoring system.In Proceedings of the Conference on Wireless Health,WH ’12, pages 11:1–11:8, New York, NY, USA, 2012.ACM.
[22] N. Nikzad, J. Yang, P. Zappi, T. S. Rosing, andD. Krishnaswamy. Model-driven adaptive wirelesssensing for environmental healthcare feedbacksystems. In IEEE International Conference onCommunications (ICC), pages 3439–3444. IEEE, 2012.
[23] A. Pathak, A. Jindal, Y. C. Hu, and S. P. Midkiff.What is keeping my phone awake?: characterizing anddetecting no-sleep energy bugs in smartphone apps. InProceedings of the 10th International Conference onMobile Systems, Applications, and Services, pages267–280. ACM, 2012.
[24] J. Polastre, J. Hill, and D. Culler. Versatile low powermedia access for wireless sensor networks. InProceedings of the 2nd International Conference onEmbedded Networked Sensor Systems, pages 95–107.ACM, 2004.
[25] D. Quinlan, M. Schordan, R. Vuduc, and Q. Yi.Annotating user-defined abstractions for optimization.In 20th International Parallel and DistributedProcessing Symposium, 2006, pages 8–pp. IEEE, 2006.
[26] A. Sampson, W. Dietl, E. Fortuna,D. Gnanapragasam, L. Ceze, and D. Grossman. Enerj:Approximate data types for safe and generallow-power computation. In ACM SIGPLAN Notices,volume 46, pages 164–174. ACM, 2011.
[27] V. Srinivasan, G. R. Shenoy, S. Vaddagiri, D. Sarma,and V. Pallipadi. Energy-aware task and interruptmanagement in linux. In Ottawa Linux Symposium,2008.
[28] V. Venkatachalam and M. Franz. Power reductiontechniques for microprocessor systems. ACMComputing Surveys (CSUR), 37(3):195–237, 2005.
[29] Y. Wang, J. Lin, M. Annavaram, Q. Jacobson,J. Hong, B. Krishnamachari, and N. Sadeh. Aframework of energy efficient mobile sensing forautomatic user state recognition. In Proceedings of the
7th International Conference on Mobile Systems,Applications, and Services, pages 179–192. ACM, 2009.
[30] F. Xu, Y. Liu, T. Moscibroda, R. Chandra, L. Jin,Y. Zhang, and Q. Li. Optimizing background emailsync on smartphones. In Proceeding of the 11thInternational Conference on Mobile Systems,Applications, and Services, MobiSys ’13, pages 55–68,New York, NY, USA, 2013. ACM.
[31] W. Ye, F. Silva, and J. Heidemann. Ultra-low dutycycle mac with scheduled channel polling. InProceedings of the 4th International Conference onEmbedded Networked Sensor Systems, pages 321–334.ACM, 2006.
