CAS: Context-aware Background ApplicationScheduling in Interactive Mobile Systems

Joohyun Lee†, Member, IEEE, Kyunghan Lee∗‡, Member, IEEE, Euijin Jeong‡, Student Member, IEEE,Jaemin Jo‡, Student Member, IEEE, and Ness B. Shroff], Fellow, IEEE

Abstract—Each individual’s usage behavior on mobile devicesdepend on a variety of factors such as time, location, and previousactions. Hence, context-awareness provides great opportunities tomake the networking and the computing capabilities of mobilesystems to be more personalized and more efficient in managingtheir resources. To this end, we first reveal new findings from ourown Android user experiment: (i) the launching probabilities ofapplications follow Zipf’s law, and (ii) inter-running and runningtimes of applications conform to log-normal distributions. We alsofind contextual dependencies between application usage patterns,for which we classify contexts autonomously with unsupervisedlearning methods. Using the knowledge acquired, we developa context-aware application scheduling framework, CAS thatadaptively unloads and preloads background applications fora joint optimization in which the energy saving is maximizedand the user discomfort from the scheduling is minimized.Our trace-driven simulations with 96 user traces demonstratethat the context-aware design of CAS enables it to outperformexisting process scheduling algorithms. Our implementation ofCAS over Android platforms and its end-to-end evaluationsverify that its human involved design indeed provides substantialuser-experience gains in both energy and application launchinglatency.

Index Terms—Context-awareness; Context-aware networkingand computing; Application unloading/preloading; Start-up la-tency; Energy minimization

I. INTRODUCTION

As mobile devices have become an essential part of ourlives, people expect more capability from them such as longerbattery life, ubiquitous access to Internet, immediate responsetime, and fresh contents (e.g., messages, feeds, news, ads,sync data, or software updates). The recent advancement ofcellular networks and cloud computing is partly fulfilling theseneeds. However, certain performance features such as longbattery life and high quality-of-service (e.g., low latency and

†J. Lee is with the Department of Electrical and Computer Engineering atThe Ohio State University, e-mail: lee.7119@osu.edu.∗‡K. Lee, the corresponding author, E. Jeong, and J. Jo are with the

School of Electrical and Computer Engineering, UNIST (Ulsan NationalInstitute of Science and Technology), South Korea, e-mails: khlee, ujjeong,jaemin@unist.ac.kr.

]N. B. Shroff holds a joint appointment in both the Department ofECE and the Department of CSE at The Ohio State University, e-mail:shroff.11@osu.edu.

This research was supported in part by grants from the National ScienceFoundation CNS-1409336 and CNS-1446582, and the Army Research LabMURI W911NF-12-1-0385. This research was also supported in part byNRF grant (NRF-2016R1D1A1B03935042) funded by the Korea government(MSIP) and the research funds of UNIST (grant 1.160048.01 and grant1.17004.01).

A preliminary version of this work was presented at ACM UbiComp2016 [1].

8 10 12 14 16 18 20 22 24 2 4 6 8

Byte

s

100

102

104

106

user is sleeping

TX/RX network usage (com.facebook.katana)

Time (hour)8 10 12 14 16 18 20 22 24 2 4 6 8

sta

te

back

foreApplication status (com.facebook.katana)

Fig. 1. Daily network usage of the Facebook app and its correspondingstate either being in the foreground or background. The Facebook app incursbackground network traffic even when the user is not interacting with it.

A motivational example for the effect of unloading

screen off (background)(115mA)screen on (foreground) (750mA)

Pressing the home/power button

Fig. 2. Measured power consumption of a popular game application forforeground and background states in a Galaxy Note 2 smartphone.

fresh contents) have intrinsic tradeoffs that make it difficult tooptimize simultaneously.

In a large-scale measurement study of 2000 Galaxy S3 andS4 devices by Chen et al. [2], [3], 45.9% of the total energydrain occurs during screen off periods. This high energyconsumption mainly comes from background applications thatupdate contents, collect user activity information, or keepcomponents in active states [4], [5]. However, these back-ground activities may not be always beneficial for users. Forexample, if a social network application updates its contentsfrequently (say every 20 minutes), but the user launches thisapplication once a day, then most updates unnecessarily wastenetwork energy.1 As a motivational example, we show themeasured daily network usage2 of a Facebook application ona Galaxy S7 smartphone running Android 6.0.1 in Fig. 1,where the update or collection intervals are less than 20

1It is well known that frequent network traffic incorporates large ramp andtail energy overheads [6], [7].

2We log network usage by reading /proc/uid_stat/[uid]/.

minutes.3 Also, gaming or map applications often keep highpower-consuming components such as CPU and GPS in activestates while being in background. This operation is intendedto provide immediate responses from those applications butwastes energy unless the user re-launches them within a shorttime. This inefficient stand-by operation is indeed observed ina popular game application, as shown in Fig. 2. To this end,we aim at managing mobile applications in a resource-efficientmanner by exploiting per-user application usage behaviorsanalyzed in the perspective of contextual usage statistics. Itis important to mention that managing applications not onlyinfluences the computing behaviors but also the networkingbehaviors of a mobile system which in turn leads to furtherresource optimizations such as delaying or suppressing non-urgent background network traffic.

To our knowledge, the most widely used application con-troller in Android [8] and iOS [9] is called the low memorykiller (LMK) that commonly kills (i.e., unloads or terminates)applications to secure more available memory. Popular mem-ory kill algorithms that are often implemented with LMKpurge applications in the order of either LRU (least recentlyused) or process priority [10]. As this mechanism is merelyinherited from computer systems with abundant resources(e.g., energy), it never considers contextual information ofapplication usages. Thus, it naturally fails to manage mobileapplications in an efficient way.

There have been two complementary approaches to tacklethis problem. Several papers [11]–[14] tried to identify energybugs/hogs, that mainly come from coding errors. This maysuccessfully kill all detected buggy activities, but benignoperations such as activity logging can also be stopped (falsepositive) and unnecessary network activities may be mostly in-tact (false negative). Another recent approach in [2] proposeda metric called BFC (Background to Foreground Correlation)to quantify the level of user engagement for each applicationon the fly. If the BFC value is smaller than a threshold,background activities are implemented to be suppressed. [2]also developed HUSH that puts applications that have not beenrecently used in foreground into inactive states, and extendsthe duration of being in the inactive states in an exponentialmanner. They showed that the screen-off energy saving of theiralgorithms is 15-17% in their large-scale traces.

The second approach partly tackled the energy-inefficientactivities, but still this approach is myopic as it ignores thevery important statistics on when the user will relaunch anapplication. As human behaviors have regular patterns in theirdaily lives, it is clearly possible to design a more efficientapplication controller that is far beyond the naive exponentialmechanism. This is only possible when deeper understandingsof per-user and per-application usage behaviors are acquired.

3The authors in [4] revealed that the Facebook application uses network dataevery 5 minutes or every 1 hour in their large scale measurement between Dec2012 to Nov 2014. They also revealed that network traffic from backgroundapplications consumes 84% of total network energy, mainly due to periodiccontents updates and their tail energy consumption.

To that end, we collect application usage of 103 Androidusers for which we deployed a logger that was designed toperiodically send detailed application, sensor, and memoryusage data to our server. The total data collected spans over1057 days and reaches about 20GB. We find that the usagepatterns follow heavy tail distributions: (i) The launching prob-abilities of applications follow the Zipf’s law, and (ii) inter-running and running times of applications resemble log-normaldistributions. We also reveal detailed context-dependency inthe re-launching probabilities, which convey more personal-ized control ideas over existing studies [15]–[19]. To realizea control algorithm that exploits such personalized context-dependency, we automate the procedure of per-user contextextraction by adopting unsupervised learning methods thatsignificantly improve prediction accuracy.

With the contextual knowledge, we propose a new appli-cation control framework, CAS (Context-aware ApplicationScheduler) that works by predicting when a user will launchan application and which application will be used. Trace-drivensimulations with consideration of system overhead show thatCAS outperforms the Android genuine resource scheduler,LMK, and Android 6.0. We also verify the practicality of CASby implementing the system on Android.

II. RELATED WORK

We classify previous work on mobile resource schedulinginto several categories from experimental studies to implemen-tations and summarize their contributions.Human behaviors on mobile application usage: To estab-lish the foundation of context-awareness for mobile resourcescheduling, several pioneering experimental studies [15]–[21]have been performed to analytically understand how humansuse applications given contexts such as time/location informa-tion, and the last used application. Falaki et al. [21] studiedusage traces from 255 users and found that the levels ofactivities are vastly different across users. They also foundthat screen off times fit well with the Weibull distribution.Application preloading algorithms: Those early studieson context-awareness led to the development of applicationpreloading/prefetching algorithms [22]–[26] applications thatsubstantially reduce the perceivable start-up latency (i.e.,launch latency) by preparing required resources (includingcomputation such as rendering, and communication such asfeed updates) before they are requested by users. However,most previous studies have focused on which application auser will launch next, but not on when the user will launch it.[23] is the only work that concerned the moment of launching,but the authors did not consider the cumulative penalty ofpreloaded applications, hence their prefetching schedules maysuffer from large energy wastage until the predicted applica-tion is actually accessed.Application unloading algorithms: The default low memorykillers (LMK) on Android [8] and iOS [9] unload or ter-minate applications to secure more memory resource, whenthe available memory goes below a pre-defined threshold.

Foreground (on screen)

Foreground (not on screen)

Perceptible

Visible

Service

Background

Empty / Gone

[Android process classification] [3-state classification] Pr

oces

s im

porta

nce

100

130

200

300

400

100

500 1000

Foreground (on screen)

Background

Empty

Fig. 3. The process states defined in Android [28] (left) and our simplifiedthree states (right).

Popular memory kill algorithms that are often implementedwith LMK purge applications in the order of either LRU (leastrecently used) or process priority [10]. Android version 6.0(Marshmallow), released in October 2015, adopts new featurescalled App standby and Doze mode [27] for energy saving.App standby suppresses background activities of an applicationthat has not been used in foreground for 3 days. The Dozemode is enabled when a user leaves the device for a certainamount of time. Doze mode restricts background apps’ accessto network and CPU for most of time, and lets backgroundapps complete their activities for a short maintenance window.Doze mode schedules this maintenance window less frequentlyas the untouched period gets elongated.

A recent paper [2] proposed simple unloading algorithmscalled BFC (Background to Foreground Correlation) andHUSH for screen-off background activities. The BFC metricquantifies the likelihood that a user will interact with an ap-plication during a next screen-on interval after its backgroundactivities. BFC updates the metrics using an exponential mov-ing average at the end of each screen on period, and unloadsapplications if their BFC metrics are less than a cutoff value α.Another algorithm, HUSH increases the suppression intervalof an application if it has not been used in foreground usingexponential backoff (i.e., the interval is multiplied by a givenscaling factor σ). Once an application is used in foreground,the interval is reset to an initial value. This simplistic algorithmis shown to save about 15-17% of energy in their large-scaleusage traces. Our preliminary work [1] was the first of its kindthat jointly considers preloading and unloading of backgroundapplications. However, the scheduling algorithm therein wasnot able to systematically find an optimal schedule for a givenresource constraint (e.g., energy, or launching latency).

III. PRELIMINARY

In this section, we explain basic concepts for applicationprocesses. In Android OS, there are various application stateseach of which has its corresponding “process importances”ranging from 100 to 1000 [28]. An Android application4

installed on a device stays in one of the states at a timeslot. Fig. 3 shows all the states defined in Android and oursimplified mapping of those states into three states: foreground,

4We interchangeably use process and application.

Foreground

(on screen)

Background Empty

Preload

(for shorter start-up latency)

Cold launch

(incurs longer

start-up latency)

Stop

(by home,

power

button)

Warm launch

(incurs shorter

start-up latency)

Unload

(for lower power consumption)

Stop

(by manual

termination)

Fig. 4. Our simplified states and transitions between a pair of states.

background, and empty. We define a foreground process to bea process in use and that is visible to users. By the definition,there can be at most one application in foreground at eachtime. An empty process5 is defined to be a process unloadedfrom memory, and thus no resource is allocated to that process.We denote a background process as a process that is loadedbut not running on foreground.

The rationale behind our simplification of states is thatthe processes that are running with no foreground UI on thescreen show similar resource consumption characteristics (e.g.,memory and power) as background processes of importance400 rather than foreground processes running on the screen.Also, these processes can be unloaded just like backgroundprocesses of importance 400 without disrupting on-going userexperience, except system processes (e.g., phone caller andapplication launcher) that are designed to be running all thetime, and user-interactive applications (e.g., music, radio andrecorder) that are usable even without visible UIs.

We depict the transitions between states in Fig. 4. An emptyto foreground transition called cold launch occurs when a usertouches an empty (i.e., unloaded) application to launch. Atransition from background to foreground called warm launchis mostly made when a user chooses to use the application byre-launching an application that is still kept in the background,and thus has shorter latency than cold launch but consumesmemory and battery for background activities. Therefore, userexperience on battery life and application launch latency ishighly dependent on the decision of putting an application ineither of background or empty state.

We further define the system state as either of off or onand its period. T off

k denotes the k-th screen-off period whenall applications are either in background or empty, while T on

k

denotes the k-th screen-on period for which an application isbeing used in the foreground. Fig. 5 depicts how the numberof background applications (|B(t)|) changes as the screenstate and foreground application Xk change over time, underthe Android default scheduler LMK, where B(t) and Xk

denote the list of background applications at time t and theforeground application at k-th screen on period. Under LMK, aforeground process goes to background when the user switches

5The empty state corresponds to suspended in iOS [9].

Screen

stateOff

On

Foreground app

switched from to

Number of

background

apps at :

( )

Screen

off

Duration

Fig. 5. Our slotted time model of off and on periods (bottom) and an exampleof corresponding sets of background applications at each slot by LMK (top).

to a different foreground application or turns off the screen.LMK kills applications in background in the descending orderof importance values when the available memory goes belowmultiple levels of preset memory thresholds. This is surelydone with no consideration on when the killed applicationis going to be relaunched. Thus, LMK results in highercold launch probability, even though it keeps a number ofapplications in background and brings high energy wastes.

IV. MEASUREMENT STUDY

A. Data collection

To capture application usage behaviors of smartphones inthe wild, we performed our own data collection with 96 An-droid users selected from a few popular Internet communitiesof South Korea during two weeks in Feb. 5-18, 2015. Weprovided a data logger programmed to periodically recordapplication usage and device characteristics summarized in Ta-ble I, and upload the data to our server daily. We anonymizedall user information and IDs at the level of user devices. Weasked users not to use task killers and not to manually unloadapplications while participating our experiment, in order tosee how the Android genuine scheduler, LMK works. Theaverage valid data per user is about 11 days, and the totaldata size is about 20GB. We also asked the participants tofill an anonymized survey involving occupation, age band,gender, and personal statement on their dissatisfaction of thesmartphone (e.g., latency, freeze), summarized in our surveyreport [29]. To improve the reliability of the responses wedid our best to create an anonymous interface to give themconfidence in providing the correct information. Participantscome from diverse occupations, genders, ages, and devices(e.g., Samsung Note2, Note3, Note4, S3, S4, S5, LG G2,G3). Most of participants use Android KitKat (4.4.2) (75%),where a small number of them use Jelly Bean (4.2.2 and 4.3)and Lollipop (5.0.1). From our survey, short lifetime, frequentfreezes, and long start-up latency were still the major problemsfor participants, even though their smartphones were mostlystate-of-the-art.

B. Key observations from the measurements

We summarize key observations in this subsection.Application usage statistics of users and states: In Fig. 6, weplot the fraction of time spent in different process importance

TABLE ILOGGED EVENTS AND ASSOCIATED FIELDS.

Event Name Associated Fields PeriodsApplist List of all installed applications -

Running apps List, Importance, Memory usage 10 secsBattery status [Full, Charging, Not Charging], 0-100% "Screen status [On, Off], Brightness (0-255) "

Available memory Memory in MB "Location Longitude, Latitude, Accuracy 5 mins

timeoff period (inter-running time)

1 sec 10 sec1 min 1 hr 12 hr

CC

DF

: P

(X>

x)

10-2

10-1

100

week 1week 2

timeon period (running time)

1 sec 10 sec 1 min 20 min1 hr

CC

DF

: P

(X>

x)

10-2

10-1

100

week 1week 2

Fig. 8. The CCDF (complementary cumulative distribution functions) of off(left) and on (right) period distributions in week 1 and week 2 of user 59.

evaluated from our experimental logs, the number of runningprocesses at a moment, and the number of unique processesthat have ever been used during the experiment. We treatsystem and user-interactive (e.g., music) processes separatelyin the figure. We find that the number of running (fore-ground+background) processes per user is 5.2 on average,and the number of unique processes ever used per user is 55.1on average, excluding system and user-interactive processes.73% of unique processes have not been used in foregroundfor more than 3 days in our traces, and these processes willbe unloaded by the new feature App standby6 of Android 6.0released in late 2015, which suppresses background activitiesof an application that has not been used in foreground for3 days. However, the number of corresponding backgroundprocesses in run is only 2 on average (40% of that in LMK)so that the energy saving from this feature is not significant aswe will see in our simulation section. The fraction of time aprocess spends in the foreground state is about 6% on average,while the fraction of time in background is about 16 times ofbeing in foreground. The fraction of time that the screen is onis 21% on average (i.e., 5 hours per day).Regularity in application usage: The existence of the regu-larity of application usage patterns of a person is the key tomake a mobile system predictive, and thus more efficient. Inorder to understand individual application usage patterns, weinvestigate the timings of all foreground application actions(launching/stopping) and analyze the event intervals. For thevisualization, we choose one user randomly and depict thetimings of the application launches for two consecutive weeksin Fig. 7. We observe that the active hours are highly regularand the intensity of activities during the weekdays or weekendsfor two weeks resemble each other. More specifically, we findthat there exists strong distributional similarity in both off andon periods in the first week and the second week, as shown inFig. 8. These results confirm that temporal and distributionalknowledge from usage history can be used to better predictthe future application usage.

6Our measurement is conducted before this feature is provided.

user index2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 44 46 48 50 52 54 56 58 60 62 64 66 68 70 72 74 76 78 80 82 84 86 88 90 92 94 96

po

rtio

n o

f sta

te (

imp

ort

an

ce

)

0

0.2

0.4

0.6

0.8

1

Back (42.3%) Service (4.1%) Visible (2.1%) Perceptible (3%) Fore-NotOnScreen (8.9%) Fore-OnScreen (3.9%) System (34.3%) User-interactive (1.4%)

user index2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 44 46 48 50 52 54 56 58 60 62 64 66 68 70 72 74 76 78 80 82 84 86 88 90 92 94 96

# o

f p

roce

sse

s

0

20

40

60

80

avg. # of running processes at a moment # of used processes running (avg.=5.2) used (avg.=55.1)

Fig. 6. The percentage of states (importance) in recorded logs (top) and the number of running processes at a moment and the number of unique processes(bottom). The numbers (-%) in the top graph indicate the average portion of each state across all participants (This figure is best viewed in color).

Time (day), Week 10am Thu 0am Fri 0am Sat 0am Sun 0am Mon 0am Tues 0am Wed 0am

screen off

screen on

Time (day), Week 20am Thu 0am Fri 0am Sat 0am Sun 0am Mon 0am Tues 0am Wed 0am

screen off

screen on

Fig. 7. Foreground activity of user 59 over two weeks (week 1 in Feb. 5-11 (top), and week 2 in Feb. 12-18 (bottom)). Regular temporal patterns are observedin weekdays and in weekends.

off period (inter-running time)1 sec 10 sec 1 min 1 hr 6 hr

CC

DF

: P

(X>

x)

10-3

10-2

10-1

100

trace (avg.=8.2 min)Lognormal fit

on period (running time)1 sec 10 sec 1 min 20 min1 hr

CC

DF

: P

(X>

x)

10-3

10-2

10-1

100

trace (avg.=1.5 min)Lognormal fit

Fig. 9. The CCDF and the corresponding log-normal fittings of off (left) andon (right) periods of one randomly chosen user.

Off/on period distribution: In Fig. 9, we fit off/on perioddistributions of a randomly chosen user to show that thedistributions are heavy-tailed. We verify by Cramer-Smirnov-Von-Mises (CSVM) [30] and Akaike [31] tests that off/onperiods of all users have the best fit with log-normal dis-tributions7 rather than exponential, Weibull, truncated Pareto,gamma and Rayleigh distributions. We use the best fitting log-normal distributions as representative of off/on periods in thefollowing sections for tractability. We also depict the CDFsof average individual off/on period of users in Fig. 10. Theaverage individual off period in total is 15.5 mins for a wholeday, 13.5 mins for the active hours (9:00 to 24:00) and 33.8mins for the inactive hours (24:00 to 9:00). Not surprisingly,the off period in the inactive hours is much longer than inthe active hours, as users tend to leave the device unattendedduring the inactive hours. The average individual on period isabout 1.4 mins.Off/on failure rates: In order to deeply understand the appli-cation usage behavior, we quantify the frequency of alteringits state from “off to on” (launching) or from “on to off”during off/on periods at the elapsed time t, which is commonlycalled as the failure rate. Formally, the failure rate of T isrT (t) , fT (t)

1−FT (t) , for t such that FT (t) < 1, where fT (t)

7The probability density function (PDF) of the log-normal distribution withparameters µ and σ is (xσ

√2π)−1exp(−(ln(x)− µ)2/2σ2).

avg. off period (min)0 10 20 30

CD

F : P

(X ≤

x)

0

0.2

0.4

0.6

0.8

1

active (avg.=13.5min)all day (avg.=15.5min)inactive (avg.=33.8min)

avg. on period (min)0 1 2 3 4 5

CD

F : P

(X ≤

x)

0

0.2

0.4

0.6

0.8

1

active (avg.=1.3min)all day (avg.=1.4min)inactive (avg.=1.7min)

Fig. 10. The CDF of average off (left) and on (right) periods of users.

time1 sec 10 sec 1 min 5 min 20 min 1 hour

failu

re r

ate

(o

ff)

0

0.002

0.004

0.006

0.008

0.01

0.012

0.014

rT off (Ω, t)

avg.

time1 sec 10 sec 1 min 5 min 20 min 1 hour

failu

re r

ate

(o

n)

0

0.01

0.02

0.03

0.04

0.05

0.06

0.07

rT on(Ω, t)

avg.

Fig. 11. Off (top) and on (bottom) failure rates of users. The length of a timeslot is one second. The dotted lines are failure rates of each individual user.

and FT (t) = P[T ≤ t] are the probability mass function andcumulative distribution function (CDF) of T, respectively. Tcan be either T off or T on. We call off failure rate (from off toon) for T off and on failure rate (from on to off) for T on. InFig. 11, we plot off and on failure rates, for each user (dottedlines) and on average (solid line). For most of users, the offand on failure rates increase at first but soon decrease rightafter 10 seconds. The pattern of having decreasing failure rateover time is called negative aging [32]. This indicates that

TABLE IITHE PORTION OF USER-TRIGGERED LAUNCHES, AVERAGE RUNNING

TIMES OF 12 MOST POPULAR APPLICATIONS AND THEIR top-1 TO top-3PROBABILITIES ACROSS ALL USERS.

category process name launches time top-1 top-2 top-3Messaging com.kakao.talk 27% 47s 44% 25% 7.3%Browsing] com.android.browser 6% 161s 9.4% 9.4% 10%

Portal com.nhn.android.search 4.4% 123s 2.1% 5.2% 9.4%Browsing] com.sec.android.app.sbrowser 3.8% 129s 5.2% 5.2% 5.2%

Social com.facebook.katana 3.3% 126s - 6.3% 6.3%Contacts] com.android.contacts 2.7% 20s 4.2% 1% 5.2%

Social com.nhn.android.band 2.2% 49s - 5.2% 1%Browsing com.android.chrome 2.2% 119s 3.1% 4.2% 4.2%Setting] com.android.settings 1.8% 29s - 1% -Social com.nhn.android.navercafe 1.5% 82s - 1% 2.1%Game com.supercell.clashofclans 1.5% 281s - 2.1% 2.1%

Messaging jp.naver.line.android 1.2% 29s 2.1% - 2.1%

] Android default applications.Messaging: 31.2%, Browsing: 14.5%, Portal: 11.7%, Social: 8.5%, Game: 4.9% (for 100most popular applications).

m (# of frequently used apps)0 1 2 3 4 5 6 7 8 9 10

The launchin

g p

rob. of m

apps

0

0.2

0.4

0.6

0.8

1

average

rank100 101 20 30

frequency f(k

;N,s

)

10-3

10-2

10-1

100

avg.Zipf dist. (s=1.4)

Fig. 12. The CDF of the launching probability of m most frequently usedapplications (left) and Zipf distribution fitting for the average launchingprobability (right). The frequently used applications of each user are notidentical. The dotted lines are for each individual user.

users are less likely to launch an app as the off or on periodincreases. Thus, an energy-efficient control needs to reducebackground activities as the failure rate starts to get reduced.This also suggests that the increasing backoff mechanismsof HUSH [2] and Doze [27] can be effective although theirschedules are neither optimized nor personalized given that theindividual failure rates (dotted lines in Fig. 11) show distinctcharacteristics for different users.Frequently used applications: In Table II, we summarizethe 12 most popular applications across all participants fromthe perspective of the launching probabilities, average runningtimes and top-1 to top-3 probabilities. Top-n probability of anapplication is defined as the probability that the applicationis the n-th most frequently used application of a user. Themost popular application in our experiment is shown to beKakaoTalk (com.kakao.talk), a messaging application knownas used by 93% of smartphone users in South Korea as ofMay 2014. 95% of our participants use KakaoTalk.

In Fig. 12, we depict the launching probability of frequentlyused applications of users. Note that the applications areindividually sorted. We find that the launching probabilityfollows Zipf’s law8 with exponent s = 1.4, and the aggre-gated launching probability of the 10 most frequently usedapplications of a user is more than 80% on average. Recall

8The frequency of elements of rank k, f(k; s,N) of a population of Napplications is proportional to k−s, where s is the exponent of the Zipfiandistribution.

that the average number of unique applications ever used fora user is 55.1. Therefore, users tend to use a small fraction ofthe applications most of the time, and there is little gain in thestart-up latency and related user experience when infrequentlyused applications are kept in background.

Memory consumption: The average physical memory sizeof experimented smartphones is 2.14GB. From the log, wefind that the available memory is 488MB on average, whichis only 22.8% of the physical memory (90% of users haveless than 31.6% of total memory available). This is mainlyfrom the memory threshold of the low memory killer, belowwhich it terminates applications. The lack of free memory mayfreeze a mobile device frequently and degrade user experience.The average memory consumption of a controllable activityprocess is 55.4MB in background and 116MB in foreground.We depict memory consumption of 25 popular applications(5 applications in Game, Messaging, Browsing, Portal/Video,Social categories) in foreground and background in the top ofFig. 13. The memory consumption in background is almosthalf of that in foreground, so that a mobile device lacks avail-able memory if many applications are running in background.The time averaged memory size from controllable activityprocesses in background is 325MB. Note that the mobile OSand system processes occupy 60% of physical memory onaverage.Warm and cold launch latency: In the bottom of Fig. 13,we present warm and cold launch latencies for the popularapplications measured from our controlled experiment usingSamsung Note2. To quantify the launch latency, we firstmeasure the time durations until (1) screen rendering, and (2)loading application data in memory is completed, by filteringand monitoring Android logcat debugging outputs [33]. Allother applications are unloaded before each measurement.We then regard the maximum of these two time durationsas the launch latency. The average warm and cold launchlatencies are 0.9s (rendering: 0.7s, memory loading: 0.4s) and4.5s (rendering: 3.61s, memory loading: 3.58s), respectively.The game applications show the most drastic difference inlatency, where the warm and cold launches take 12.6s and1.8s, respectively. This is mostly due to loading high volumeof texture data onto memory and rendering initial game scenes.For the tested popular applications, application preloading thattransforms a cold launch into a warm launch decreases thestart-up latency by 80% (3.6s).User survey: We summarize key results from our survey.We first asked participants to choose major problems in theirsmartphones. 71% of participants chose short battery lifetimeand 40% of them chose frequent freezes. Also, 46% of par-ticipants experience inconvenience from long start-up latencyat least once a week. The battery lifetime that participantsexperience when it is fully charged is 9 hours on average,where it ranges from 3 to 24 hours. To increase batterylifetime and mitigate freezes, 82% of participants manuallyterminate applications and 28% of them use application killersoftware (e.g., Advanced Task Killer [34]). We also requested

g1 g2 g3 g4 g5 m1 m2 m3 m4 m5 b1 b2 b3 b4 b5 p1 p2 p3 p4 p5 s1 s2 s3 s4 s5

po

we

r (m

A)

0

100

200

300

400 back (avg=32mA) fore (avg=226.6mA)

g1 g2 g3 g4 g5 m1 m2 m3 m4 m5 b1 b2 b3 b4 b5 p1 p2 p3 p4 p5 s1 s2 s3 s4 s5

me

mo

ry (

MB

)

0

100

200

300 back (avg=86.3MB) fore (avg=126.7MB)

popular applicationsg1 g2 g3 g4 g5 m1 m2 m3 m4 m5 b1 b2 b3 b4 b5 p1 p2 p3 p4 p5 s1 s2 s3 s4 s5

late

ncy (

se

c)

0

5

10

15 22sec

g1: com.supercell.clashofclansg2: com.joycity.RuleTheSkyg3: com.cjenm.ModooMarbleKakaog4: com.cjenm.sknightsg5: jp.colopl.krquizwiz

m1: com.kakao.talkm2: jp.naver.line.androidm3: kr.co.vcnc.android.couplem4: net.sjang.sailm5: net.daum.android.air

b1: com.android.browserb2: com.android.chromeb3: com.mx.browserb4: mobi.mgeek.TunnyBrowserb5: jp.ddo.pigsty.HabitBrowser

p1: com.nhn.android.searchp2: kr.co.nowcom.mobile.afreecap3: kr.co.quicketp4: net.nvyu.app.clianp5: com.google.android.youtube

s1: com.facebook.katanas2: com.nhn.android.bands3: com.nhn.android.navercafes4: net.daum.android.cafes5: com.kakao.story

warm launch (avg=0.9sec) cold launch (avg=4.5sec)

Fig. 13. Memory (top) consumption in background and foreground, and cold/warm launch latency (bottom) of popular applications in 5 categories (Game,Messaging, Browsing, Portal/Video, Social).

participants to list the applications with long startup latencyand the length of perceived latency they experienced. Morethan 77% of participants have provided at least one applicationwith long startup latency. The average startup latency ofthem is 7.3 seconds, where that of gaming applications is9.1 seconds (and messaging: 3s, social: 3.6s, browsing: 6.3s,navigation: 6s). Thus, short lifetime, frequent freezes, and longstart-up latency are still the major problems for smartphoneusers, even though their smartphones are almost state-of-the-art.Context dependency: We also analyze app usage patternsincorporated under various contexts. Here, contexts correspondto any information that characterizes the situation of users,which enables us to predict future app/component invocationsmore accurately. In Fig. 10, the average inter-launching timeat inactive hours (24:00 to 9:00) is about 3.6 times longerthan the average inter-launching time at active hours. InTable II, we find that the average on periods are vastly differentacross applications (e.g., long running time for games andbrowsers, and short running time for messengers). In Fig. 14,we depict the conditional launching probability of applications(Xk) for the previously used application (Xk−1), for oneuser in each week. The application index is sorted by thelaunching frequency in descending order (application 1 is themost frequently launched application). We choose 13 popularapplications for visibility. We note that if there is a non-zeroscreen-off period between two consecutive on periods (T on

k−1

and T onk ), Xk−1 and Xk could be the same application, and

P[Xk = Xk−1|Xk−1] can be non-zero. We observe that thelaunching probability is vastly different depending on the pre-vious applications. These patterns are also quite similar in eachweek. Therefore, the likelihood of launching an applicationat a moment depends on the previous application, and thesestatistics can be learned from history. We also observe contextdependencies such as the duration of the previous intervals(T offk−1, T on

k−1). For instance, after using a messaging app, thenext inter-launching times are typically shorter than average,as the recipient of a message may respond quickly. We omitmore details for brevity.

V. SYSTEM ARCHITECTURE

In this section, we propose our system design of CAS asdepicted in Fig. 15. Our framework consists of three major

131211

previous application (i)

109876543211312

1110

current application (j)

98

76

54

32

1

0

0.2

0.4

0.6

0.8

1

cond

ition

al la

unch

ing

prob

abili

ty

P(Xk=j|X

k-1=i)

(a) Conditional launching probability (week 1).

131211

previous application (i)

109876543211312

1110

current application (j)

98

76

54

32

1

0

0.2

0.4

0.6

0.8

1

cond

ition

al la

unch

ing

prob

abili

ty

P(Xk=j|X

k-1=i)

(b) Conditional launching probability (week 2).

Fig. 14. The conditional launching probability of applications (Xk) for apreviously used application (Xk−1) in each week of user 59.

components: 1) context monitor, 2) user profiler, and 3) back-ground application controller. Over these system components,CAS runs in three phases: collection, pre-computation, andcontrol. The collection phase builds personalized statistical in-formation about application usage patterns such as described inSection IV. This data will be used in the pre-computation and

Context Monitor

User characteristics

Device characteristics

Background Application Controller

Algorithm block

𝐵𝐵off 𝑡𝑡

𝐵𝐵on 𝑡𝑡

Background apps

User Profiler

App usage pattern

Resource functions

App usage,

Set of contexts, Resource

consumption

getContext

collect

Preloader / Unloader

preload

unload

⋅⋅⋅

updateModel

Schedules

1. Collection

(e.g., a week)

OFF ON

Execution of preloading or unloading

OFF ON ON ON

2. Pre-computation 3. Control

Check the current context information and look up the pre-computed schedules

2. 3. Control

Fig. 15. The overall architecture of CAS and its operations over time.

time of a day (hour)0 3 6 9 12 15 18 21 24T

rain

set: T

off (

hr)

0123456

Active (x), avg=0.17Inactive (o), avg=0.53

time of a day (hour)0 3 6 9 12 15 18 21 24

Tests

et: T

off (

hr)

0123456

Active (x), avg=0.19Inactive (o), avg=0.54

Fig. 16. A sample off-period classification by “active” (8am - 11pm) and“’inactive” (11pm - 8am) hours obtained from the first week trace (top) ofone user. The classification obtained from the first week is applied to thesecond week (bottom) and it still shows a good match from regularity inhuman behaviors.

control phases. The pre-computation phase will be dicussedin more detail with the algorithm descriptions in Section VI.Here, we overview how each component works sequentially.Collection phase and context classification: In the collectionphase, context monitor collects various contextual informationin background, to build information base on application usagepattern. Contexts we collect are screen state, time and locationinformation, memory and CPU/network usage, applicationlaunch sequence, and battery level. Using the informationbase, the user profiler analyzes per-application usage behavior,cross-correlations of application usage behaviors, and resource(power/memory) consumption of background applications ac-cording to component-wise power models in [35], [36], withdiverse statistical measures such as failure rates and launchingprobabilities. Collection of data for learning may take sometime (e.g., one week) in order to prepare a reasonable amountof statistics at first (e.g., when a user buys a new phone).

To better exploit contexts, the collected context informationof traces can be classified and labeled. For instance, time ofa day can be roughly classified into two labels, active andinactive hours, which may show two distinct probabilisticdistributions of off and on periods by the nature of humanlife cycles. The labels resulted from classifications of many

x (residual sum of squares (sec2))

5x108

109

3x109

1010

P(X

≤ x

)

0

0.2

0.4

0.6

0.8

1Prediction errors for off periods

without contextwith context

x (residual sum of squares (sec2))

106

107

108

5x108

P(X

≤ x

)

0

0.2

0.4

0.6

0.8

1Prediction errors for on periods

without contextwith context

Fig. 17. CDF of prediction errors for off (left) and on (right) periods of users.

contexts will lead to a condition for prediction, where the con-dition is composed of a tuple of context labels such as (time =Active, last app = Facebook). People have different lifecyclesand habits, so that contexts should be classified individually.In order to classify contexts automatically in a personalizedmanner without asking users a manual classification, we adoptunsupervised learning techniques. Unsupervised learning aimsat classifying input data autonomously by clustering the databy their correlation (i.e., similarity). For instance, when clas-sifying “time of a day” into k continuous time blocks, we cansetup the following clustering problem which minimizes theresidual sum of square errors from the clustering.9 We solvethis problem using a k-means algorithm [37].minHA

∑k:Sk∈HA

(Tk − E[Tk|Sk ∈ HA])2 +∑

k:Sk /∈HA

(Tk − E[Tk|Sk /∈ HA])2,

where Sk is time of a day of k-th sample (at the beginning),and HA is the active timezone that is continuous (e.g., HA =[a, b], where a is 10:00 and b is 21:00). Sk ∈ HA if Sk iswithin the time interval of HA. We depict an example of “timeof a day” classification for off periods in Fig. 16. The diurnalpattern of this user is clearly identified by the classification.We find that most of the users need only 2 continuous timeblocks (i.e., k = 2) to describe their temporal activities andshow very little gain from further separation.

In Fig. 17, we depict the residual sum of squares of usersfor off and on periods in the test set (i.e., the second weekof the trace), where the contexts (time of a day, previous offand on periods, last used application) are trained from the firstweek of the trace. We note that these dependencies includingdiurnal patterns are vastly different among users depending ontheir usage patterns and lifestyles. The residual sum of squaresis decreased by 29.8% and 40.3% for off and on periodson average, respectively. Thus, it is clear that our automaticcontext classification leads to more accurate prediction. Wealso find that the entropy10 of the next launching app, Xk,is substantially reduced as well, which is omitted for brevity.Intuitively, lower entropy means reduced uncertainty and betterpredictability.Pre-computation and control phases: Based on this anal-ysis, the background application controller computes sets ofbackground applications for possible combinations of contextsin both off and on periods, in the pre-computation phase.For each cluster C (i.e., a tuple of several contexts), we usethe conditional distribution Tk|C and conditional probabilityof Xk|C where these conditional values are trained under

9We similarly formulate and solve this problem for other contexts such asprevious off and on periods.

10The entropy for an application launch is −∑

i∈Ω P[Xk =i] log2 P[Xk = i].

TABLE IIISUMMARY OF MAJOR NOTATION.

Variable Definition

B(t) ⊂ Ω set of background applications at time tB(t) ⊂ Ω set of empty applications at time tP (B(t)) power consumption of B(t)

∆iP (B(t)) = P (B(t) ∪ i)− P (B(t))

M(B(t)) memory usage of B(t)

T offk & T on

k k-th off and on period times (random variable)Xk k-th launching (foreground) application (r.v.)

rT (B(t), t) = fT (t)1−FT (t)

· P[X ∈ B(t)], failure rate of B(t)

γ trade-off parameter (power/disutility)

the cluster C. In other words, our algorithm (which will beexplained in the next section) will run for each cluster C.Therefore, we exclude the conditional information C in therest of the paper, i.e., Tk = Tk|C and Xk = Xk|C, forsimplicity. This pre-computation happens once in a while (e.g.,one time per week) to adapt for the change of the applicationusage behavior. Pre-computation also runs during the inactivehours with the device connected to its charger, to avoid anyinconvenience to users. During the control phase, at the startof each off or on period, the controller calls the contextmonitor and acquires the contextual information at the momentas its input. Based on the pre-computed list of backgroundapplications at each moment for the given contextual informa-tion, background application controller executes pre/unloadingduring the on or off period. As the recommended list ofbackground applications at each moment are pre-computed,these executions do not bring any computational burden.

VI. ALGORITHM DESIGN

In this section, we formulate a submodular optimizationproblem that selects the best set of background applicationsto minimize the total penalty in energy and start-up latency.Then, we develop a practical scheduling algorithm for CAS.We also develop an iterative algorithm that finds the optimalschedules for a given energy constraint. This constrainedoptimal scheduling is practically valuable to users who wantthe best application performance at each level of energyallowance.

A. System model

System states: We summarize major notations in Table III. Welet Ω (|Ω| = N ) denote the set of controllable applications ofa user, which does not include any system and user-interactiveprocesses. We define B(t) ⊆ Ω and B(t) ⊆ Ω to be the sets ofapplications in the background and empty states, respectively,which are our main control knobs.

We define the system state as an off/on period as in Fig. 5.We denote T off

k and T onk as random variables of the k-th off

and on period, respectively. We denote Xk as the foregroundapplication that runs during the time duration of T on

k .11 We

11We omit the subscript k unless confusion arises.

recall that the failure rate is defined as rT (t) , fT (t)1−FT (t) , for

t such that FT (t) < 1. T can be either T off or T on. We alsodefine the partial failure rates for a set of empty applicationsB(t) as rT (B(t), t) = rT (t) · P[X ∈ B(t)], which quantifiesthe rate that one of empty applications B(t) is launched at t.Note that rT (Ω, t) = rT (t).Power consumption and memory usage model: For applica-tions included in Ω, we define a power function, P : 2Ω → R+

and a memory function M : 2Ω → R+ that respectivelyrepresent the amount of the average power and memory usageof a set of background applications. Based on the observa-tions made in [35], we model P as a monotone submodularfunction12 of B(t). Our model is reasonable since applicationsshare hardware components, and each of them becomes morepower-efficient as the utilization becomes higher. We define∆iP (B) = P (B ∪ i) − P (B) as the marginal increase inpower consumption by adding an application i in the back-ground application set B. A memory function M is a linearadditive function13 for any B(t). Note that we use averagepower and memory consumption for long-term optimization.For simplicity, we model that the energy consumption forpreloading and unloading is minor in the long-run and thatthe transition delay is much shorter than one time slot. Thesemodels practically make sense as the preloading/unloadingconsume its power less than a few seconds and happenonly a few times an hour. More detailed discussion on theconsumption of the transition energy will be provided in thesimulation section.

B. Problem formulation

We aim to develop a scheduling algorithm for CAS thatreduces and balances energy consumption and user disutil-ity from experiencing cold launch of applications, under agiven memory budget Mth. Since there is a trade-off betweenthe energy consumption and the user disutility, we adopt aparameter γ to treat both metrics as a unified measure. Auser who is less sensitive to latency but is keen to extendbattery lifetime will choose a smaller γ value, and vice versa.14

The optimal scheduling algorithm for CAS can be obtainedfrom the optimization problem that minimizes both the energyconsumption and the user disutility over the infinite timehorizon. The optimization problem is formally defined below.We present the equation by the summation of two componentscorresponding to off and on period optimizations for betterunderstanding.

minBoff(t),∀t

M(Boff(t))<Mth

Hoff + minBon(t),∀t

M(Bon(t))<Mth

Hon

Hoff ,∞∑t=1

P[T off = t]( t∑τ=1

P (Boff(τ)) + γ · P[X /∈ Boff(t)]),

12P (A∪B) ≤ P (A) +P (B)−P (A∩B) for A,B ⊂ Ω, and P (A) ≤P (B) for any A ⊆ B.

13For any disjoint sets A,B ⊂ Ω, M(A ∪B) = M(A) +M(B).14We will discuss later in this section how γ can be automatically

determined for a user who wants to limit either of energy consumption ordisutility.

Hon ,∞∑t=1

P[T on = t]( t∑τ=1

P (Bon(τ)) + γon · P[X /∈ Bon(t)]),

where γon = γP[T off = 0], Bon(t) ⊆ Ωk, and Ωk = Ω\Xk.We use Boff(t) and Bon(t) to denote the set of backgroundapplications in an off and on period, respectively.

The optimization is decomposed into off and on problems(i.e., Hoff and Hon), each of which corresponds to the opti-mization during a screen-off or screen-on period. In the off-period optimization(Hoff), the summation of P (Boff(τ)) fromτ = 1 to t indicates the energy consumption when the lengthof an off period is t and the second term quantifies the expecteddisutility from the cold launch of an application weighted byγ. In an on period, the disutility is multiplied by the probabilitythat the user will switch to another application without goingthrough an off period (i.e., P[T off = 0]). Otherwise, the devicewill go into an off period (i.e., the user stops using the device)and there will be no disutility.

By restating energy and disutility terms in Hoff usingP[T off ≥ t], we have Hoff =

∑∞t=1 P[T off ≥ t]

(P (Boff(t)) +

γ ·rT off(Boff(t), t))

from the definition of the partial failue rate.Since we have assumed that the latency and energy overheadfor preload and unload are minor, the sets of optimal back-ground applications for time slots and their resulting snapshotobjectives become uncorrelated. Hence, in this formulationachieving the optimality in each snapshot (i.e., time slot)warrants the global optimality. The snapshot problem in eachslot in an off period is as follows:

P-off: minBoff(t)

P (Boff(t)) + γ · rT off(Boff(t), t) (1)

subject to M(Boff(t)

)< Mth, B

off(t) ⊆ Ω. (2)

Similarly, in an on period, we have the following problem:

P-on: minBon(t)

P (Bon(t)) + γon · rT on(Bon(t), t)

subject to M(Bon(t)

)< Mth, B

on(t) ⊆ Ωk.

In the rest of the derivation, we focus on the P-off problem, asthe P-on can be identically handled by letting Bon(t) ⊆ Ωk.For simplicity, we omit the superscript off in T off, Boff(t), andrT off(Boff(t), t) unless we need to emphasize them. Thus, theobjective function to minimize is rewritten as h

(B(t), t

)=

P (B(t)) + γ · rT (B(t), t).

Proposition 6.1: The objective functions in P-off and P-onare submodular.

Proof: From the definition of submodularity, it is straight-forward to see that the sum of a submodular function and anadditive function is submodular, by subtracting the additivefunction in the inequality (i.e., adding an additive functionto a submodular function does not break the inequality).Since P (B(t)) is submodular and rT (B(t), t) is additive, theobjectives in P-off and P-on are submodular.

C. Scheduling algorithm design

Proposition 6.1 clarifies that our problem formulation inEq. (1) is of a constrained submodular minimization with an

upper bound constraint. Note that a constrinaed submodularminimization with a lower bound cardinalty constraint hasbeen proven to be NP-hard in [38]. Since the cardinalityconstraint can be generalized to rational weights and g(S) =f(Ω \ S) is also submodular15 such that the upper boundconstraint can be transformed to a lower bound constraint,our problem is also NP-hard. If P (B(t)) were additive, thenthis problem becomes a 0-1 knapsack problem, which canbe solved using dynamic programming. For an unconstrainedsubmodular minimization problem, Orlin et al. [39] devel-oped an optimal polynomial-time algorithm with complexityO(N5L+N6) where L is the time for function evaluation. Thecomputational complexity of the optimal algorithm is alreadytoo heavy for mobile systems even without a constraint.Hence, we propose an algorithm for constrained submodularminimization with limited complexity (e.g., up to quadratictime complexity) that could result in sub-optimal performance,but in practice is often close to optimal performance. To thatend, we provide necessary conditions for a policy to be optimalin Theorem 6.1. Then, we will show that our proposed policysatisfies these necessary conditions.

We denote π =(Bπ(t)

)∞t=1

as a control policy. We defineΠR as a set of rational control policies as follows:

ΠR =π :Bπ(t2) 6⊇Bπ(t1),∀t1, t2 s.t. rT (Ω, t2)≤rT (Ω, t1).The reason why it is rational is that an optimal control policyshould not add more background applications in B(t) whenthe failure rate decreases. We will show that an optimal controlpolicy π∗ satisfies π∗ ∈ ΠR in the following Theorem 6.1.

Theorem 6.1 (Necessary condition): If B∗(t) is an optimalcontrol of P-off in Eq. (1), then for any i ∈ B∗(t) and j ∈Ω \B∗(t) such that M(B∗(t) ∪ j) ≤Mth,

(i) ∆iP (B∗(t) \ i) ≤ γ · rT (i, t), and(ii) ∆jP (B∗(t)) ≥ γ · rT (j, t).

Also, an optimal control policy π∗ =(B∗(t)

)∞t=1

is in ΠR.Proof: (i) Suppose that there exists i ∈ B∗(t) such that

∆iP (B∗(t) \ i) > γ · rT (i, t). Then h(B∗(t) \ i, t

)<

h(B∗(t), t

)for h(B(t), t) = P (B(t)) + γ · rT (B(t), t), and

B∗(t) is no longer an optimal control. (ii) can be proved in asimilar manner.

Now, we will show that π∗ ∈ ΠR by contradiction. Forany t1, t2 such that rT (Ω, t2) ≤ rT (Ω, t1), let B∗(t1) be anoptimal control at t1. Suppose that B(t2) ⊇ B∗(t1) is anoptimal control at t2. From the optimality of B∗(t1),

P (B(t2))− P (B∗(t1)) ≥ γ · rT (Ω, t1)P[X ∈ B′],where B′ = B(t2) \ B∗(t1). Also, since rT (Ω, t2) ≤rT (Ω, t1), P (B(t2)) − P (B∗(t1)) ≥ rT (Ω, t2)P[X ∈ B′]and h

(B∗(t1), t2

)≤ h

(B(t2), t2

). Therefore, B(t2) is not

an optimal control at t2 and π∗ ∈ ΠR.

We further define ΠMR as a set of monotone rational controlpolicies as follows:

ΠMR =π :Bπ(t2)⊆Bπ(t1),∀t1, t2 s.t. rT (Ω, t2)≤rT (Ω, t1).

15For S, T ∈ Ω, g(S) + g(T ) = f(Ω \ S) + f(Ω \ T ) ≥ f(Ω \ (S ∩T )) + f(Ω \ (S ∪ T )) = g(S ∩ T ) + g(S ∪ T ).

By the definition, ΠMR ⊆ ΠR. A monotone rational controlpolicy tends to minimize the number of control actions (i.e.,preloads/unloads), which in turn reduces the control overheadas shown in Proposition 6.2.

Proposition 6.2 (Control overhead): For a monotone rationalcontrol policy π ∈ ΠMR, if rT (Ω, t) is unimodal with t, boththe numbers of control actions (i.e., preloads and unloads) areless than or equal to N.

Proof: Suppose that rT (Ω, t) is unimodal with t andits maximum is at τ. For t ≤ τ, r(Ω, t) is non-decreasing and Bπ(t1) ⊂ Bπ(t2) for any t1, t2 ∈ [1, τ ]such that t1 < t2. The number of preloads in [1, τ ] is∑τt=1 |Bπ(t) \Bπ(t− 1)| =

∑τt=1

(|Bπ(t)| − |Bπ(t− 1)|

).

Thus, the number of preloads for t ∈ [1, τ ] is less than orequal to N since |Bπ(t)| ≤ N, ∀t and there is no unloading.For t > τ, r(Ω, t) is non-increasing and and B(t1) ⊃B(t2) for any t1, t2 ∈ [1, τ ] such that t1 < t2. The num-ber of unloads in (τ,∞) is

∑∞t=τ+1 |Bπ(t− 1) \Bπ(t)| =∑∞

t=τ+1

(|Bπ(t− 1)| − |Bπ(t)|

), and it is less than or equal

to N, and there is no preloading.

CAS scheduling algorithm: We propose a greedy-basedalgorithm that makes locally optimal choices in finding a setof background applications, and thus satisfies the necessaryconditions in Theorem 6.1. This may result in sub-optimalperformance but works well in practice due to the Zipfiandistributed launching probability. Intuitively, most dominantor frequently used application with high launching probabil-ities are chosen as background applications in the first fewiterations. Our scheduling algorithm also incurs small controloverhead from Proposition 6.2, as we will show that theobtained policy is a monotone rational policy.

CAS-Scheduler(γ)

input: P (·),M(·), rT (·),P[X = x], γ,Mthoutput: a1, · · · , aN , c1, · · · , cN , and B(1), · · · , B(tmax)Step (A) Compute a local optimal sequence.

1: A0 ← ∅.2: for m = 1 to N do3: am ← argmaxi∈Ω\Am−1

P[X=i]P (Am−1∪i)−P (Am−1) .

4: cm ← maxi∈Ω\Am−1

P[X=i]P (Am−1∪i)−P (Am−1) .

5: if M(Am−1 ∪ am

)> Mth then

6: cm ←∞ and break7: else Am ← Am−1 ∪ am.

Step (B) Assign controls at each time slot.

1: for t = 1 to tmax do2: m← maxj|ci ≥ 1

γ·rT (t) ,∀i ≤ j.3: B(t)← Am.

Note that tmax is the maximum duration from all observableoff or on periods such that P[T > tmax] goes to zero andB(t) = ∅ for t > tmax. Our scheduling algorithm pre-computes the entire sequence of locally optimal control actionsin step (A) and assign them in each slot in step (B). In step (A),

if more than one application becomes tied, it breaks the tie byarbitrarily choosing one of them. The computational complex-ity of our algorithm is O(N2 + NT ) where complexities ofstep (A) and (B) are O(N2) and O(NT ), respectively.

It is easy to see that the obtained policy from our schedulingalgorithm is a monotone rational policy. Also, the obtainedcontrol policy satisfies the necessary conditions for optimalityin Theorem 6.1, since it makes locally optimal choices in line 3of step (A) and stops increasing the background application setwhen there is no improvement in the objective function in line2 and 3 of step (B). We also note that our scheduling algorithmdoes not change its control decision if the environmentalconditions (e.g., power/memory functions, failure rates, orlaunching probabilities) are maintained. As those conditionsare stationary or slowly changing over time, re-computationof the algorithm happens rarely in practice (e.g., once in a dayor even less frequently). At the run time, the predeterminedschedule is just being executed. In our CAS architecture inSection V, the policy wakes the device up only when thereis an action to apply (either of preload or unload), and doesnothing otherwise, to minimize energy overhead.

Using contextual information: In our framework, we can usemore elaborate values of partial failure rates of applications(i.e., off/on period distributions and next application probabil-ities) using surrounding contexts such as the previously usedapplication (Xk−1), time of a day (Zk), location (Lk), previoustime durations (T off

k−1 and T onk−1). Each context is monitored

and recognized at the beginning of each off/on period. Ifcontext set C is detected, that period will use the conditionaldistribution Tk|C and conditional probability of Xk|C wherethese conditional values had been trained under the contextset C. We will show the performance benefit from exploitingcontextual information in Section VII.

D. Bisection method for an energy or disutility constrainedoptimization

Although it is possible for a user to jointly optimize energyand application launching latency through our framework, itis often more straightforward to optimize the latency perfor-mance given an energy constraint that coincides with the user’scharging pattern. For this, we consider the following energyconstrained problem, where our original problem (minHoff)16

can be viewed as the Lagrange relaxation problem of thisproblem.17

minBoff(t),∀t

M(Boff(t))<Mth

∞∑t=1

P[T off = t]P[X /∈ Boff(t)], (3)

subject to∞∑t=1

P[T off ≥ t]P (Boff(t)) ≤ V, (4)

where V is the average energy constraint for an off period. Theoptimal objective of the Lagrange relaxation problem will beno smaller than the optimal objective of the problem (3). This

16We focus on the off problem for simplicity.17The trade-off parameter γ is a reciprocal of the Lagrange multiplier λ.

gap can become smaller as we have shorter time slots and morefine-grained control of background applications. To that end,we approximate the solution of the energy constrained problemwith the original weighted sum minimization problem. Inparticular, we devise an iterative algorithm to find the trade-off parameter γ, under which our scheduling algorithm meetsthe given energy constraint. As the trade-off parameter γincreases, more applications will be scheduled in backgroundin a monotone rational control policy (as well as in ourscheduling algorithm from line 2 of Step (B)), so that theenergy consumption increases and disutility decreases. In otherwords, for any monotone rational control policy, the energyconsumption is non-decreasing and disutility is non-increasingin γ.

To find the trade-off paramter γ, under which the obtainedpolicy satisfies the given energy constraint, we use a bisectionmethod (similar to [40]), which is reliable if the initial interval[γ1, γ2] is chosen appropriately. Note that since both theobjective function and the constraint are neither continuousnor differentiable, we cannot apply first-order or second-order iteration algorithms (e.g., gradient descent or Newton’smethod) that are faster than the bisection method in specificconditions. One can apply a quasi-Newton method, but theconvergence is guaranteed under specific conditions includingLipschitz continuity.

From the non-decreasing property of the energy consump-tion with respect to γ in the weighted sum minimizationproblem, there exists γ ∈ [γ1, γ2] that satisfies the energyconstraint with the smallest error in the interval,18 if γ1 yieldsless energy than V and γ2 has higher energy than V , whereV is the average energy budget in an off period to satisfythe given lifetime constraint. In each iteration, the methodcomputes the energy of the middle point, γm = γ1+γ2

2 , andchooses the half interval (either [γ1, γm] or [γm, γ2]), in whichthe solution exists. The formal iteration algorithm is as follows.

Bisection method for a given energy constraint V

input: V, ε, γ1 = 0, sufficiently large γ2

output: γm, B(1), · · · , B(tmax)1: while γ2 − γ1 > ε,2: γm = (γ1 + γ2)/2.3: (B(1), · · · , B(tmax))← CAS-Scheduler(γm).4: E =

∑tmax

t=1 P[T off ≥ t]P (B(t)).5: if E ≥ V , γ2 = γm; else γ1 = γm.

Since the interval becomes half in each iteration, the numberof iterations to converge is dlog2(γ2−γ1ε )e. In other words, therate of convergence of the bisection method is 1/2, where therate of convergence is limk→∞

γk+1−γ∗γk−γ∗ , where γk is the value

at k-th iteration, and γ∗ is the weight such that the energy termis equal to the energy constraint, i.e., E = V . Note that the

18Note that a mixed policy (that takes deterministic policies with someprobabilities) can make the energy consumption continuous, so that thesolution exists within this interval by the intermediate value theorem. Weassume that the time slots are sufficiently short such that the error can besmaller than the given tolerance (ε).

TABLE IVSUMMARY OF CONTEXTUAL INFORMATION.

Info Last used app Time of a day Previous durations(Xk−1) (Sk) (T off

k−1, Tonk−1)

Class 1, · · · , N Active, Inactive Short, Long

iteration algorithm can be easily generalized to consider bothoff and on periods, by considering the time-averaged energyconsumption. Also, the iteration algorithm can be similarlyapplied to the constraint on disutility from application launchlatency. We will see the convergence of our iteration algorithmin Section VII.

VII. TRACE-DRIVEN SIMULATION

A. Setup

To evaluate power consumption and latency performanceof CAS for our measurement traces, we develop a trace-driven simulator incorporating the average power and memoryfunctions, P (·) and M(·). We model P (·) by the component-wise power model (e.g., CPU, screen, WiFi, cellular, and GPS)in [35] and our measurement on utilization of components foreach application in our traces. M(·) is directly computed fromour measurement log. In the trace-driven simulation, we com-pute the performance of CAS in which the control decisionsare made by the proposed scheduling algorithm. All statisticsand classifications are obtained from the first week of the trace(i.e., training set) and simulations are conducted for the secondweek of the trace (i.e., test set). We further compare a set ofexisting algorithms including the default Android scheduler(LMK), App standby and Doze mode [27] in Android 6.0,BFC and HUSH proposed in [2] with CAS. The contextualinformation we used is summarized in Table IV.19 As thegain from location information is turned out to be negligible,we exclude the location information. Authors in [23] alsofound that the benefit from location information in predictionaccuracy is minimal as it is already partially captured by theapplication sequence and time information. The parameters ofBFC (α = 0.1) and HUSH (σ = 1.2) are chosen as in [2].The memory threshold for CAS is set to be 30% of the totalmemory size for each user leading to 840MB on average.20

B. Key Results

We depict the performance of different scheduling algo-rithms in Fig. 18, and summarize results as follows.Inefficiency of LRU-based LMK: As a baseline, we evaluatethe performance of LMK from our experimental logs. Theaverage power consumption from background applications isabout 111mA, which is much higher than the typical idle powerconsumption of 10mA in the most up-to-date smartphones.The average power consumption of a foreground applicationduring screen on periods is about 562.5mA. Given that, our

19We used the k-means algorithm to classify “time of a day” and “previousdurations”.

20Our measurement data indicates that on average about 60% of totalmemory is occupied by the OS and system processes.

LMK Standby Doze+Standby BFC HUSH CAS (γ=1e+6) (γ=3e+5) (γ=6e+4)

avg. # o

f backgro

und a

pps

0

1

2

3

4

5

6

7

avg. app s

tale

ness (

hour)

0

0.5

1

1.5

2

2.5

3

3.5

# of appsapp staleness

(a) Number of background applications and staleness.

LMK Standby Doze+Standby BFC HUSH CAS (γ=1e+6) (γ=3e+5) (γ=6e+4)

avg. backgro

und p

ow

er

(mA

)

0

20

40

60

80

100

120

140

160

cold

launch p

robabili

ty

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

powercold launch

(b) Background power and cold launch probability.

applications1 2 3 4 5

app s

tale

ness (

hour)

0

5

10

15

Naver Line(messaging)

KakaoTalk(messaging)

Facebook(social) Naver Cafe

(social) Naver Band(social)

LMKApp StandbyDoze+App StandbyBFCHUSHCAS (γ=6e+4)

(c) Staleness of social and messaging apps on one user.

Fig. 18. Comparison of scheduling algorithms. The error bars indicate 25thand 75th percentiles.

experimental traces show that the energy consumption ofbackground applications amounts to 48.5% of the total batterycapacity under LMK. These measurements lead to 12.2 hoursof average battery life for the devices in our experimentallogs whose average battery capacity is about 2800mAh. Theaverage cold launch probability with LMK is measured tobe 43% with average memory occupancy of 212MB fromcontrollable background applications.21

Android 6.0, BFC and HUSH [2]: The new feature, Appstandby [27], in Android 6.0 unloads applications that haveno foreground activity for more than 3 days. The portionof unique applications that can be affected by App standbyoption is observed to be 73% of total installed applications,but only 39% of background activities under LMK are affected(See Fig. 18(a)). This is due to active killing of applicationsunder memory pressure in LMK. Therefore, energy saving forbackground applications over LMK is limited to 19.4% (totalenergy saving is 9.4%). Another feature, Doze mode [27] inAndroid 6.0, restricts background activities is enabled after auser leaves the device for an hour. Then, the suppression timewindows are increasing as 1, 2, 4, and 6 hours, where themaintenance windows are scheduled in between suppressionwindows for 5 minutes. Doze mode further reduces back-ground energy by 33% over LMK, but its additional energysaving is not significant as the time portion of off periods overan hour is only about 28%. Note that only 3% of off periodsare longer than an hour.

BFC and HUSH algorithms unload background activitiesmore aggressively each of which suppresses 51% and 47%

21Note that 212MB is only for the background applications. In general, thememory utilization of a device is much higher as it further involves foregroundand system processes.

elapsed time1 sec 10 sec 30 sec 2 min 12 min 40 min 1.5 hr 6 hr

# o

f backgro

und a

pps (

off)

0

1

2

3

4

5

6

7

[1]com.kakao.talk (35.1%)

[2]com.sec.android.app.sbrowser (23.1%)

[3]com.facebook.katana (21.1%)

[4]net.daum.android.map (6.2%)

[5]com.nhn.android.navercafe (3.6%)

[6]com.android.contacts (2.3%)

[7]com.sec.android.gallery3d (1.3%)γ = 6e+4γ = 1.5e+5γ = 3e+5

Fig. 19. Background application schedules of CAS for one user in offperiods. The x-axis is in log scale. We list the application names of theordered sequence in the graph and the numbers (-%) indicate the launchingprobabilities. 1: Messaging, 2: Browsing, 3, 5: Social, 4: Navigation, 6:Contacts, 7: Utility.

staleness (sec)10

110

210

310

410

5

CD

F:

P(X

≤ x

)

0.7

0.75

0.8

0.85

0.9

0.95

1Naver Line (messaging)

LMKApp StandbyDoze+App StandbyBFCHUSHCAS (γ=6e+4)

staleness (sec)10

110

210

310

410

510

6C

DF

: P

(X ≤

x)

0

0.2

0.4

0.6

0.8

1Facebook (social)

LMKApp StandbyDoze+App StandbyBFCHUSHCAS (γ=6e+4)

Fig. 20. CDF of staleness in two applications, Naver Line and Facebook, onone user.

more compared to LMK. The background (total) energysavings over LMK in BFC and HUSH are 31.2% (15.1%)and 32.7% (15.8%), respectively. One potential problem ofBFC and HUSH is that they update control decisions onlyby relying on latest activities of applications. For example,in HUSH, the suppression interval is reset to an initial value(i.e., 1 min) every time an application gets a foregroundactivity, which is not efficient for low active applications. Inall these schemes, their cold launch probabilities and stalenessare higher than LMK, since these algorithms only suppressbackground activities.CAS: CAS achieves diverse operating points dependingon the trade-off parameter γ. Our scheduling loads morebackground applications as γ increase as shown in Fig. 19.Also, according to our finding that the launching probabilitydecreases as the elapsed time passes by in each off/on period(i.e., negative aging), CAS unloads more and more backgroundapplications as time goes by. As the failure rate starts todecrease after around 30 seconds, low priority applicationsare unloaded sequentially. Eventually, all background applica-tions are unloaded after 12, 40, and 90 minutes for differentoperating points, γ = 6e+4, 1.5e+5, and 3e+5, respectively.CAS achieves a similar cold launch probability with only0.7 background applications (14% of LMK) for γ = 6e+4in Fig. 18. The background and the total energy savingsover LMK become as high as 51% and 25% on average forγ =6e+4. Also, CAS reduces the cold launch latency by 26%over LMK for γ = 1e+6, with lower energy consumption.

Staleness: We define app staleness as the average elapsedtime since the last background or foreground activity of anapplication as in [2]. This metric captures the user experienceespecially for applications that need to regularly update theircontents (e.g., social networking and messaging applications).The average app staleness under LMK is 1.5 hours. In Android6.0, BFC and HUSH, their app staleness values are alwayshigher than or equal to LMK because these algorithms do notrestore unloaded background activities as shown in Fig. 18(a).Unlike other algorithms, CAS preloads background applica-tions and reduces the average staleness by 33% and 41% overLMK for γ = 6e+4 and 3e+5, respectively.

To see how the app staleness varies with scheduling algo-rithms, we compare app staleness of five popular social andmessaging applications from different scheduling algorithmsfor one user in Fig. 18(c). Because this user only infrequentlyuses the Facebook app and sometimes does not use it for morethan 3 days, the App standby of Android 6.0 unloads it, whichin turn leads to a very high app staleness. However, CASpredicts the moment that an application is used next, so that theaverage staleness becomes much shorter than other algorithmsacross all applications including the social and messagingapplications. We also depict the CDF of staleness for twoapplications, Naver Line and Facebook, on the same user,in Fig. 20. In the Naver Line application, the staleness fromCAS is stochastically less than that of any other algorithms.Other applications show similar performance characteristics.In Facebook, LMK has a higher probability for small staleness(e.g., less than 1000 sec) than CAS, but the average stalenessof CAS is still smaller than that of LMK. This is becauseCAS preloads Facebook once in an off or on period most ofthe time so as to prevent the extremely long staleness.

Energy overheads of CAS: There are energy overheads inCAS that are from logging information, processing algorithms,preloading actions and wakeup alarms for pre/unloading. Notethat the application controller sleeps during the time whenthe set of background applications stays the same, and wakesup only when the control action is needed to make changes.Our measurement reveals that contextual information loggingwithout location information consumes only about 5mA. Thepre-computation phase consumes 30mAh to compute the con-trol policies for all context sets. This corresponds to powerconsumption of 1.25mA under a daily update frequency.Wakeup alarming for a control action and actual preloadingof an application are turned out to consume on averageabout 0.03mAh and 0.4mAh, respectively. Note that unloadinghappens in a flash, and thus it consumes nearly 0mAh. InCAS, the average frequencies of wakeup alarms and preloadactions are less than once in 2 mins for the chosen parameters.Overall, the energy overhead required for running CAS doesnot exceed 23.3mAh per hour at maximum, which is about0.8% of the battery capacity and is much smaller than thehuge gain obtained from CAS. We take into account theseenergy overheads in CAS.

Battery life and start-up latency: To quantify the gain in the

TABLE VCOMPARISON OF SCHEDULING ALGORITHMS.

Scheduler Power] Cold launch Memory] Lifetime† Latency‡

LMK-LRU 111mA 43% 212MB 12.2 hr 2.45secApp Standby 89.5mA 54.8% 131MB 13.5 hr 2.87sec

Doze+Standby 74.4mA 55.9% 103MB 14.5 hr 2.91secBFC [2] 76.4mA 49.4% 93MB 14.4 hr 2.67sec

HUSH [2] 74.7mA 48.9% 91MB 14.5 hr 2.66secCAS (same energy as LMK) 111mA 26.3% 138MB 12.2 hr 1.85secCAS (same energy as HUSH) 74.7mA 35.1% 95MB 14.5 hr 2.13secCAS (same disutility as LMK) 54.2mA 43% 58MB 16.3 hr 2.45sec

Oracle 10mA 0% 0MB 21.9 hr 0.9sec

]: Power/memory consumption of background applications including energy overhead.The voltage ranges from 3.7V to 3.8V. The idle background power is 10mA.†: Based on 21% of screen on periods and 2800mAh of battery.‡: Based on 4.5sec of cold launch and 0.9sec of warm launch latencies.

user-perceived metrics such as battery lifetime and expectedstart-up latency, we calculate them based on our measurementover popular applications (see Fig. 13) and summarize themin Table V. We include a simulation of the ideal yet infea-sible scheduler, Oracle, that exactly knows when and whichapplication the user will use next. Note that the upper bound ofbattery lifetime simulated from Oracle is 21.9 hours. For CAS,we apply the bisection method in Section VI-D to achieve thesame disutility or energy as LMK, and the same energy asHUSH. The average battery lifetime of a device is extendedto 16.3 hours in CAS from 12.2 hours observed under LMK,with the same disutility (i.e., the expected start-up latency).When the lifetime of CAS is equalized to that of LMK, theexpected start-up latency is reduced from 2.45sec in LMK to1.85sec in CAS. When the lifetime of CAS gets equalized tothat of HUSH, CAS can reduce the expected start-up latencyfrom 2.66sec to 2.24sec.

VIII. ANDROID IMPLEMENTATION

We implement CAS on Galaxy Note 2 (the most populardevice in our traces), which runs Android 4.4.2, KitKat. Threemajor components (context monitor, user profiler, and back-ground application controller) are implemented and packagedas a system service. The implementation of context monitorspecifically for CAS focuses on collecting application usagehistory and time of the day information that incurs minimalenergy overhead, and uses delayed write for saving data inthe SQL database (i.e., SQLite of Android) in a highly energyefficient manner. To this end, the background application con-troller uses BroadcastReceiver and AlarmManager to executepreloading and unloading at desired moments with little useof CPU resource. In order to realize preloading, we usegetLaunchIntentForPackage method together with startActivityincluded in PackageManager of Android.

To unload processes, we implement the linux shell com-mand execution of am force-stop <Package Name>22 in An-droid using the Android NDK (native development kit), wheream stands for activity manager. To make CAS work indepen-dently from Android LMK or Linux OOM (out of memory)

22We gain the super user (su) access by rooting the device to perform am,which will be unnecessary once our scheduling algorithm is integrated withAndroid.

TABLE VIEXPERIMENTAL RESULTS OF CAS AND LMK OVER 1-DAY TRACES OF

TWO USERS ON GALAXY NOTE 2.

User index User 46 User 61Number of installed apps 37 64

Portion of screen on periods 8.1% 22%Daily screen on durations 1.9 hours 5.3 hours

Avg. off period 16.2 mins 16.9 minsAvg. on period 0.85 min 0.9 min

Scheduling LMK CAS LMK CASAvg. # of background apps in run 6.0 0.2 4.5 0.99

Avg. screen-off power (mA) 72 26.7 100 44.7Avg. screen-on power (mA) 388 378 526 460

Avg. power (mA) 97.5 55.8 194 136Expected lifetime‡ (hour) 31.8 55.5 16.0 22.8

‡: Battery size is 3100mAh.

killer underneath Android platform without interfering withthem, we substantially relaxed all low-memory related param-eters and virtually disabled such resource schedulers. In orderto let an application stay unloaded as per our decision, wealso intercept app invocations23 such as the asynchronous IPC(Inter-Process Communication) message passing mechanismcalled Intent, which can wake up an unloaded process. Thismay delay notifications or messages of unloaded processeswhich we will discuss later.

Android Experiment: For the experiment of our platform,our service is designed to precisely follow the application andscreen behaviors precomputed over a collected trace as a timeseries for each scheduling algorithm. Note that we chooseto perform this replay style emulation as it is better than ahand-carried experiment from the perspective of ensuring a faircomparison between the algorithms. Our replay service turnson and off screen by using WakeLock method in PowerMan-ager class and lockNow method in DevicePolicyManager class,respectively. Because our experiment rules out any human in-tervention, it is reasonable to keep the system awakened usingWakeLock while we emulate a screen on period. Although ouremulation method is not perfect in mimicking user behaviorsin foreground UI such as touch actions, it is fair to say that thisend-to-end evaluation capturing all possible system overheadssets a baseline of the performance of CAS in reality.

We summarize the results of CAS (γ =6e+4) and LMKand the usage patterns for the two randomly chosen users inTable VI. One of these users turned out to be a light user andthe other a mild to heavy user. We find that the energy savingsof CAS from LMK are 43% and 30% for each user, as thenumbers of background applications in run are significantlyreduced. The average power during screen on periods is alsoreduced since CAS unloads background applications both inscreen off and on periods. The experimental results confirmthat energy saving from CAS can be indeed significant inpractice. As a future work, we plan to extend our experimenttoward user studies that involve evaluations of user-perceivedbenefits with CAS installed in the actual user devices.

23This interception is similarly implemented as [2].

IX. DISCUSSIONS AND CAVEATS

There are practical issues that need to be considered beforeCAS can be widely used. The issues are mostly on theapplication characteristics and semantics that can be affectedby controlling the application.Discomfort from Unloading: Our application control maydelay notifications or messages for unloaded applications.This can have both pros and cons, as deferring or neglectingadvertisement messages can relieve one’s stress and receivingimportant messages later can be big losses. However, longdelay occurs only when these applications are not likely to belaunched for a long time, so that the actual inconveniencemay not be critical, as our result on staleness confirms.To avoid such inconvenience, we can consider staleness ofapplications in our objective directly, and allow backgroundactivities intermittently to reduce or bound staleness, whichwe leave as a future work. We can also whitelist some criticalapplications from application controlling as follows.Whitelisting: Some apps should not be unloaded from back-ground even though they may be infrequently used. For exam-ple, caller apps such as Skype should be able to receive callsat anytime. Thus, application categories such as call, music,radio, and recorder need to be excluded from applicationcontrol, which we already excluded them as user-interactiveprocesses. A more intelligent way is to ask users whether theywant to whitelist infrequently used apps as in [14]. We canalso use crowdsourced statistics24 of applications to minimizethe need for user inputs. As more applications are whitelisted,the possibility of energy saving is reduced as well. Becausewhitelisted applications will work as intended by developerswithout considering other applications and application usagebehaviors, this may incur energy inefficiency of the entiresystem.Privacy issue: Our context monitor and user profiler canhave privacy sensitive data (e.g., sleeping hours from timeof a day classification), which should be encrypted and onlyaccessible by CAS. We note that because CAS runs on amobile device and does not rely on cloud resources foranalyzing its application usage patterns, there is no privacyor security concern for leaking personal data to Internet.Dataset bias: Our trace data can be biased in the sensethat we collected traces of the participants from Internet usercommunities in Korea, who may be more tech-savvy thangeneral populations. We will collect more diverse trace datain the future work, and study the performance depending onthe level of user acitivity.

X. CONCLUDING REMARKS

Our scheduling framework, CAS, is the first work thatconsiders both preloading and unloading dimensions in ap-plication scheduling. Through CAS, we have shown in thispaper that mobile systems can achieve much higher efficiency

24Individual choices will be anonymized and only the averaged statisticswill be shared.

in resource management than conventional systems by under-standing human behaviors on application usage and relatedcontextual information. Trace-driven simulations demonstratethat CAS outperforms LMK, HUSH, and Android 6.0. Wealso implement CAS on Android and validate the performancethrough experiments. We underscore that the significant gainof CAS is from regularity and context-dependency of humanbehaviors.

CAS requires sufficient application usage history with con-text information (i.e., long collection phase). For future work,we are interested in training model parameters faster using alearning framework, and crowdsourcing of statistics from thedevices of the same type or of similar attributes, which canbootstrap the collection phase. We will study other energy-efficient contexts and how to classify them to increase theprediction accuracy.

REFERENCES

[1] J. Lee, K. Lee, E. Jeong, J. Jo, and N. B. Shroff, “Context-awareApplication Control in Mobile Systems: What Will Users Do and NotDo Next?” in Proc. of ACM UbiComp, 2016.

[2] X. Chen, A. Jindal, N. Ding, Y. C. Hu, M. Gupta, and R. Vannithamby,“Smartphone background activities in the wild: Origin, energy drain,and optimization,” in Proc. of ACM MobiCom, 2015.

[3] X. Chen, N. Ding, A. Jindal, Y. C. Hu, M. Gupta, and R. Vannithamby,“Smartphone energy drain in the wild: Analysis and implications,” inProc. of ACM Sigmetrics, 2015.

[4] S. Rosen, A. Nikravesh, Y. Guo, Z. M. Mao, F. Qian, and S. Sen,“Revisiting network energy efficiency of mobile apps: Performancein the wild,” in Proc. of ACM Conference on Internet MeasurementConference (IMC), 2015.

[5] A. Pathak, Y. C. Hu, and M. Zhang, “Where is the energy spent insidemy app?: fine grained energy accounting on smartphones with eprof,”in Proc. of ACM EuroSys, 2012, pp. 29–42.

[6] N. Ding, D. Wagner, X. Chen, Y. C. Hu, and A. Rice, “Characterizingand modeling the impact of wireless signal strength on smartphonebattery drain,” in Proc. of the ACM SIGMETRICS, 2013.

[7] J. Huang, F. Qian, A. Gerber, Z. M. Mao, S. Sen, and O. Spatscheck,“A close examination of performance and power characteristics of 4glte networks,” in Proc. of ACM MobiSys, 2012.

[8] Android Developers, “Managing Your App’s Memory,” 2015, https://developer.android.com/training/articles/memory.html.

[9] Apple Developer, “App programming guide for ios: The app lifecycle,” 2015, https://developer.apple.com/library/ios/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/TheAppLifeCycle/TheAppLifeCycle.html.

[10] J. H. Kim, J. Sung, S. Y. Hwang, and H.-J. Suh, “A novel androidmemory management policy focused on periodic habits of a user,” inUbiquitous Computing Application and Wireless Sensor, 2015, pp. 143–149.

[11] A. J. Oliner, A. Iyer, E. Lagerspetz, S. Tarkoma, and I. Stoica, “Col-laborative energy debugging for mobile devices,” in Proc. of USENIXWorkshop on Hot Topics in System Dependability (HotDep), 2012.

[12] A. Pathak, Y. C. Hu, and M. Zhang, “Bootstrapping energy debuggingon smartphones: a first look at energy bugs in mobile devices,” in Proc.of ACM Workshop on Hot Topics in Networks (HotNets), 2011.

[13] A. Pathak, A. Jindal, Y. C. Hu, and S. P. Midkiff, “What is keepingmy phone awake?: characterizing and detecting no-sleep energy bugs insmartphone apps,” in Proc. of ACM MobiSys, 2012.

[14] I. Singh, S. V. Krishnamurthy, H. V. Madhyastha, and I. Neamtiu,“Zapdroid: managing infrequently used applications on smartphones,”in Proc. of ACM UbiComp, 2015, pp. 1185–1196.

[15] H. Verkasalo, “Contextual patterns in mobile service usage,” Personaland Ubiquitous Computing, vol. 13, no. 5, pp. 331–342, 2009.

[16] M. Böhmer, B. Hecht, J. Schöning, A. Krüger, and G. Bauer, “Fallingasleep with angry birds, facebook and kindle: a large scale study on mo-bile application usage,” in Proc. of ACM Human-Computer Interactionwith Mobile Devices and Services (MobileHCI), 2011.

[17] C. Shin, J.-H. Hong, and A. K. Dey, “Understanding and prediction ofmobile application usage for smart phones,” in Proc. of ACM UbiComp,2012.

[18] C. Shepard, A. Rahmati, C. Tossell, L. Zhong, and P. Kortum, “LiveLab:measuring wireless networks and smartphone users in the field,” ACMSIGMETRICS Performance Evaluation Review, vol. 38, no. 3, pp. 15–20, 2011.

[19] A. Rahmati, C. Shepard, C. Tossell, L. Zhong, and P. Kortum, “Practicalcontext awareness: Measuring and utilizing the context dependency ofmobile usage,” IEEE Transactions on Mobile Computing, 2014.

[20] T. M. T. Do, J. Blom, and D. Gatica-Perez, “Smartphone usage in thewild: a large-scale analysis of applications and context,” in Proc. of ACMconference on multimodal interfaces, 2011.

[21] H. Falaki, R. Mahajan, S. Kandula, D. Lymberopoulos, R. Govindan, andD. Estrin, “Diversity in smartphone usage,” in Proc. of ACM MobiSys,2010, pp. 179–194.

[22] T. Yan, D. Chu, D. Ganesan, A. Kansal, and J. Liu, “Fast app launchingfor mobile devices using predictive user context,” in Proc. of ACMMobiSys, 2012.

[23] A. Parate, M. Böhmer, D. Chu, D. Ganesan, and B. M. Marlin, “Practicalprediction and prefetch for faster access to applications on mobilephones,” in Proc. of ACM UbiComp, 2013.

[24] N. Natarajan, D. Shin, and I. S. Dhillon, “Which app will you usenext?: Collaborative filtering with interactional context,” in Proc. of ACMRecommender systems (RecSys), 2013.

[25] R. Baeza-Yates, D. Jiang, F. Silvestri, and B. Harrison, “Predicting thenext app that you are going to use,” in Proc. of ACM Web Search andData Mining, 2015.

[26] Y. Wang, X. Liu, D. Chu, and Y. Liu, “Earlybird: Mobile prefetchingof social network feeds via content preference mining and usage patternanalysis,” in Proc. of ACM MobiHoc, 2015.

[27] Android Developers, “Optimizaing for Doze and App Standby,”2016, https://developer.android.com/training/monitoring-device-state/doze-standby.html.

[28] ——, “ActivityManager.RunningAppProcessInfo,” 2015,http://developer.android.com/reference/android/app/ActivityManager.RunningAppProcessInfo.html.

[29] J. Lee, K. Lee, J. Jo, E. Jeong, and N. B. Shroff, “CAS Survey Questionsand Results,” School of Electrical and Computer Engineering, UlsanNational Institute of Science and Technology, Tech. Rep. 1, 2015, http://msn.unist.ac.kr/CAS_survey.pdf.

[30] W. T. Eadie, M. G. Roos, and F. E. James, Statistical Methods inExperimental Physics. Elsevier Science and Technology, 1971.

[31] K. P. Burnham and D. R. Anderson, “Multimodel inference: Understand-ing aic and bic in model selection,” Sociological Methods and Research,vol. 33, no. 2, pp. 261–304, 2004.

[32] J. Jeong, Y. Yi, J.-w. Cho, D. Y. Eun, and S. Chong, “Wi-fi sensing:Should mobiles sleep longer as they age?” in IEEE INFOCOM, 2013.

[33] Android Developers, “Android logcat,” 2015, http://developer.android.com/tools/help/logcat.html.

[34] Advanced Task Killer, 2015, https://play.google.com/store/apps/details?id=com.rechild.advancedtaskkiller.

[35] C. Yoon, D. Kim, W. Jung, C. Kang, and H. Cha, “AppScope: Appli-cation energy metering framework for android smartphone using kernelactivity monitoring.” in Proc. of USENIX ATC, 2012.

[36] W. Jung, C. Kang, C. Yoon, D. Kim, and H. Cha, “DevScope: anonintrusive and online power analysis tool for smartphone hardwarecomponents,” in Proc. of ACM Hardware/Software Codesign and SystemSynthesis (CODES+ISSS), 2012.

[37] J. A. Hartigan and M. A. Wong, “Algorithm as 136: A k-meansclustering algorithm,” Journal of the Royal Statistical Society. SeriesC (Applied Statistics), vol. 28, no. 1, pp. 100–108, 1979.

[38] Z. Svitkina and L. Fleischer, “Submodular approximation: Sampling-based algorithms and lower bounds,” SIAM Journal on Computing,vol. 40, no. 6, pp. 1715–1737, 2011.

[39] J. B. Orlin, “A faster strongly polynomial time algorithm for submodularfunction minimization,” Mathematical Programming, vol. 118, no. 2, pp.237–251, 2009.

[40] R. Cendrillon, W. Yu, M. Moonen, J. Verlinden, and T. Bostoen,“Optimal multiuser spectrum balancing for digital subscriber lines,”IEEE Transactions on Communications, vol. 54, no. 5, pp. 922–933,2006.

Joohyun Lee (S’11-M’14) received his B.S. andintegrated M.S./Ph.D degree in the Department ofElectrical Engineering from Korea Advanced Insti-tute of Science and Technology (KAIST), Daejeon,Korea, in 2008 and 2014, respectively. He is cur-rently a postdoctoral researcher in the Departmentof Electrical and Computer Engineering at the OhioState University. He received IEEE William R. Ben-nett Prize Paper Award in 2016, given to the bestoriginal paper published in IEEE/ACM Transactionson Networking in the previous three calendar years.His research interests are in the areas of context-

aware networking and computing, mobility-driven cellular traffic offloading,energy-efficient mobile networking, protocol design and analysis for delay-tolerant networks, and network economics and pricing.

Kyunghan Lee (S’07-M’10) is an associate profes-sor in the school of electrical and computer engineer-ing at UNIST (Ulsan National Institute of Scienceand Technology), Ulsan, South Korea. His researchinterests include low latency networking, low-powermobile computing, and mobility-aware networking.He received two IEEE ComSoc William R. BennettPrize Paper Awards in 2013 and 2016, given tothe best original paper published in IEEE/ACMTransactions on Networking in the previous threecalendar years. He received his B.S., M.S., andPh.D. degrees in Electrical Engineering from Korea

Advanced Institute of Science and Technology (KAIST), Daejeon, Korea, in2002, 2004, and 2009, respectively.

Euijin Jeong received his B.S. in Computer Scienceand Engineering from Ulsan National Institute ofScience and Technology (UNIST), Ulsan, SouthKorea, in 2016. He is currently studying for amaster degree at Ulsan National Institute of Scienceand Technology (UNIST), Ulsan, South Korea. Hisresearch interests include the areas of context-awarenetworking and computing, mobile usage prediction,and mobile energy saving.

Jaemin Jo received his B.S. in Computer Scienceand Engineering from Ulsan National Institute ofScience and Technology (UNIST), Ulsan, SouthKorea, in 2016. He is currently studying for amaster degree at Ulsan National Institute of Scienceand Technology (UNIST), Ulsan, South Korea. Hisresearch interests include the areas of context-awarenetworking, architecture design, and mobile energysaving.

Ness B. Shroff (S’91-M’93-SM’01-F’07) receivedhis Ph.D. degree in Electrical Engineering fromColumbia University in 1994. He joined Purdueuniversity as an Assistant Professor in the school ofECE, where he became a Full Professor of ECE in2003 and director of CWSA in 2004, a university-wide center on wireless systems and applications.In July 2007, he joined The Ohio State University,where he holds the Ohio Eminent Scholar endowedchair in Networking and Communications, in thedepartments of ECE and CSE. He holds or has heldvisiting (chaired) professor positions at Tsinghua

University, Beijing, China, Shanghai Jiaotong University, Shanghai, China,and the Indian Institute of Technology, Bombay, India. Dr. Shroff is currentlyan editor at large of IEEE/ACM Trans. on Networking, senior editor of IEEETransactions on Control of Networked Systems, and technical editor for theIEEE Network Magazine. He has received numerous best paper awards for hisresearch and listed Thomson Reuters Book on The World’s Most InfluentialScientific Minds as well as noted as a highly cited researcher by ThomsonReuters. He also received the IEEE INFOCOM achievement award for seminalcontributions to scheduling and resource allocation in wireless networks.