usage.tex
9.03 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
\section{Example Use Cases}
\label{sec-usage}
The \texttt{maybe} system is inspired by our frustrations building smartphone
apps and confronting the uncertainties of mobile systems programming. In this
section we describe several ways to use the \texttt{maybe} system drawn from
our own experiences, including for a smartphone service, a smartphone app, an
M2M app utilizing smartphones, and within the Android platform itself.
\subsection{PocketParker App}
\begin{comment}
\begin{figure}[t]
\begin{minted}[fontsize=\footnotesize]{java}
string detectParkingEvent() {
maybe {
// Use app-specific algorithm
} or {
// Use Google Play services
}
}
\end{minted}
\vspace*{-0.2in}
\caption{\textbf{Activity recognition using \texttt{maybe}.} \texttt{maybe}
expresses the uncertainty of whether to use our customized app-specific
parking detection algorithm or rely on the Google Play services framework
activity recognition.}
\label{fig-activityrecognition}
\vspace*{-0.1in}
\end{figure}
\end{comment}
PocketParker~\cite{ubicomp14-pocketparker} estimates the availability of
parking spaces in parking lots. It does this by automatically detecting users
of the app parking in, and departing from parking lots. To
detect these events without the need for explicit user input, we used the
accelerometer of the user's smartphone to detect whether a user is driving or
walking. Based on the detected activity and past histories, we could infer
whether a user had parked her car or departed. We needed to do this in
an energy efficient way so that the battery on the user's phone would not
drain because of our app. We developed a custom activity recognition
algorithm to determine the user's activity from the accelerometer values
sampled during the last time interval. In order to reduce battery
consumption, we duty cycled the sampling of the accelerometer.
Towards the end of our development, Google released their own activity
recognition API as a part of their Google Play Services framework. We had to
conduct several small-scale tests to determine the better of the two
algorithms in terms of energy consumption and accuracy. There was no clear
winner between the two and we decided to use the Google's API as it was a third
party library with an actively maintained codebase.
Supporting both algorithms, switching between them at runtime, and assessing
the resulting impact would have required a significant development effort.
Such runtime decisions fit naturally into the \texttt{maybe} framework.
Instead of having to choose based on small-scale local testing, the \texttt{maybe}
system can gradually transition an application's users from mature, but
inexpensive to maintain application logic to a potentially immature system-wide
library implementation. As the library implementation matures and improves, the
\texttt{maybe} system can conduct repeated testing and
move more users over to the third-party implementation. For some
users and on some devices, the third-party implementation may never
outperform the app-specific algorithm, in which cases both alternatives can
coexist safely.
\subsection{\texttt{\large PhoneLab} Conductor}
\begin{comment}
\begin{figure}[t]
\begin{minted}[fontsize=\footnotesize]{java}
maybe {
// policy A
} or {
// policy B
} or {
// policy C
} better {
if (lostLogLines > 0) {
return Integer.MAX_VALUE;
} else {
return w1*bytesOverCellular + w2*energy;
}
}
\end{minted}
\caption{\textbf{\PhoneLab{} Conductor Upload Logic Using \texttt{maybe}.}}
\label{fig-upload}
\end{figure}
\end{comment}
\PhoneLab{} is a large scale smartphone platform testbed at the University at
Buffalo~\cite{phonelab-sensemine13,phonelab-url}. We leverage the Android
\texttt{logcat} subsystem as a data collection mechanism---experiment apps
write their data into a system-wide log buffer and we collect and upload this
data on their behalf.
We developed an app called \PhoneLab{} Conductor for this purpose. Due to the
uncertainties we faced when developing this tool, we developed a specialized
configuration interface that periodically retrieves parameters from our
servers and uses them to reconfigure variable components of the app. This
allows us to control aspects of program behavior such as the amount of storage
space we use on each device for log buffers, how often we check for updates,
and how to decide whether to upload data. Several of these features have
proven essential after deployment---for example, when an upload policy that
worked on an earlier version of Android abruptly stopped working on a newer
version. Development of this app would have been considerably easier using
\texttt{maybe}, which could automate the process of pushing policies to clients
in an energy-efficient way, and enable much more fine-grained and goal-driven adaptation than we are currently performing.
The \PhoneLab{} Conductor also provides a good example of custom
\texttt{maybe} evaluation logic. The primary goal of our app is to collect
data reliably while minimizing energy consumption, storage usage, and metered
data usage. With the \texttt{maybe} statement branching between multiple
policies for uploading data---such as always waiting until the user reaches a
plug, or always initiating an upload once the storage allocated is 50\%
full---the evaluation logic would provide the lowest possible score if data
had been lost, or otherwise a score combining the multiple attributes the app is
trying to minimize.
\subsection{Navjack Sensing Platform}
% 12 Oct 2014 : GWA : Code example here is just too gross. Definitely not
% going to use it.
The Navjack project is exploring hijacking in-car navigation devices built
from repurposed smartphones~\cite{sustain-hotmobile14} and deployed in
personal vehicles to enable city-scale sensing. Volunteers install a device
that acts as a dedicated navigational aid and car performance monitor but
also senses data both while the car is moving and stationary, utilizing the
car's battery for power, the car's driver for maintenance, and new
inexpensive machine-to-machine (M2M) data plans offered by cellular carriers
for telemetry.
Navjack's goal is to produce high-quality data in response to queries without
draining the car's battery, while consuming as little cellular data as
possible. Many uncertainties specific to this app complicate the process.
Some car cigarette lighters and USB charging docks provide power while the
vehicle is off, while some do not. Users drive their vehicles for different
durations and at different frequencies. Furthermore, cellular coverage varies,
altering the energy-per-bit required to offload data. All of these factors
complicate post-deployment adaptation.
\texttt{maybe} statements in Navjack can be used to control the rate at which
data is sampled, the set of sensors that are used, and the conditions under
which uploads are attempted. This app provides an example of an adaptation
state space that can potentially get quite large, and so it may provide a
good chance to evaluate our ability to perform pre-deployment simulations to
reduce the state space and success of post-deployment clustering techniques
to identify differences between users that impact app alternative choices.
\subsection{Android Platform Services}
Earlier, we noted that that app developers should not use \texttt{maybe} to
make decisions that are best left to libraries and platform services. However,
those same
libraries and platform services can themselves use \texttt{maybe} to enable
post-deployment testing and adaptation. We are particularly interested in how
\texttt{maybe} can be used within the Android platform itself wherever
structured uncertainty must be expressed.
One use case is determining whether to use Wifi or cellular network. While this is
a hot topic in current mobile systems research~\cite{shen2008cost}, the approaches
that are currently being tested may struggle to adapt to many of the
variable that the \texttt{maybe} system incorporates and arrive at an
effective per-user approach. A similar example is optimizing the state of
GPS. With three modes already present---``High accuracy'', ``Battery saving'', and
``Device only'', the choice may need to be adapted both to app usage and more
user- or device-specific factors. \texttt{maybe} allows post-deployment
testing of a variety of different approaches to make this runtime decision.
\begin{comment}
Stretching this idea further, what if the developer didn't have to think
about cache or object availability? The language itself could determine which
block to run based on the semantics of the \texttt{maybe} case definition.
For instance, in the \texttt{android.emoji.EmojiFactory} class, there is a
method to get an eomji via its Unicode PUA (Private Use Area). To do this,
the emoji is either grabbed from a platform-level cache or is created then
written to the cache then returned. With \texttt{maybe}, the developer could
have two blocks one for the cache being empty for the PUA and one where an
object exists. Now, the developer doesn't need to think about the
possibilities of cache-state, but instead can move on to other functionality.
\end{comment}