can be represented by the events triggered by the user along
with the order of these events.
2.1 Android Basis
Similar to Java GUI apps, Android apps are usually driven
by runtime events and callbacks. The non-determinism in-
troduced by arbitrarily and distinctively triggered events in-
creases the complexity when exploring the search space and
severely challenges the symbolic execution of GUI apps. The
search space of events is decided by Android programming
and execution model, which needs a careful consideration in
analysis.
CREATED
STARTED
RUNNING
OnCreate()
OnStart()
OnResume()
PAUSED
OnPause()
OnResume()
STOPPED
OnStop()
OnRestart()
OnStart()
OnDestroy()
DESTORYED
NOT
LAUCHED
KILLED
GUI Evenets
System Events
Figure 1: Android application model. This figure depicts
the lifecycle of Android activities. The lifecycle of other
components are similar.
There are two major kinds of events in Android: callbacks
to manipulate the state transition of an app, and listeners to
handle system events and user interactions with GUI com-
ponents:
Android Events: Callbacks of Lifecycle States. Un-
like in the common Java world, Android app does not have
a unique program entry such as main(). Instead, it is com-
posed of one or more components which work together to
fulfill the functionality. The major type of components in
Android is activity. An activity represents a single screen
with a user interface. The other components, e.g., services,
content providers, and BroadcastReceivers, are background
tasks that perform long-running operations or respond to
other threads. For each component, app developers override
callback functions, which are commonly used to maintain
its lifecycle, as depicted in Figure 1. These callbacks are ex-
pected to be automatically invoked by Android application
manager. Therefore, symbolic execution faces a severe chal-
lenge because of the non-deterministic and unbounded trig-
gering order of callbacks. For example, a possible execution
could be (OnStart ⇒ OnPause ⇒ OnResume ⇒ OnPause
⇒ OnResume ⇒...). It will further worsen the already noto-
rious search space explosion problem of traditional symbolic
execution. Actually, symbolic execution may never finish
because the search space is infinite. We propose a guided
symbolic execution mechanism which can effectively solve
this problem with static analysis.
Android Events: GUI Events and System Events.
An app running on Android is commonly GUI based, and
its execution is typically driven by events from the specific
GUI controls (represented as a View object) that the user
interacts with. An app contains a collection of nested in-
terfaces, called event listeners. These listeners capture user
interactions with the app GUI. When respective interactions
occurs on the GUI controls, for example, if a button is clicked
by a user, the pre-defined event handlers are triggered cor-
respondingly. System events are handled in the same way.
Like callbacks, runtime events are also non-deterministic.
They can be triggered in any order and at any time, thus
exhaustively executing all possible sequences of events is a
task that will never end. Fortunately, events in an Android
app are commonly invoked when the state of the app is
RUNNING. In this state, the main thread is hung to wait
for incoming events. Thus, the event triggering behavior
commonly depends on the order, not the exact triggering
time.
3. GOAL AND OVERALL ARCHITECTURE
AppIntent is not an automated method to detect unin-
tended data transmission, which is probably a mission im-
possible. Instead, as a first step in this space, AppIntent is
designed to be an automated tool to present to a human an-
alyst the sequence of UI manipulations that corresponds to
the sequence of events that leads to the sensitive data trans-
mission, thereby facilitating the discrimination of whether
sensitive data transmission is user intended or not.
Our Goal. To achieve our vision, we have the following
three goals:
• Produce the critical app inputs that lead to sensitive
data transmission. Specific to Android GUI apps, in-
puts are always composed of: a) Data inputs which
contain text inputs from outside; b) Event inputs from
user interactions through GUI interface and from sys-
tem through IPC. In addition, we need to track down
the root-cause that gives rise to the transmission and
filter out the massive set of irrelevant inputs.
• Guarantee a good code coverage. To find all feasible
paths, we need to thoroughly traverse diverse program
paths that may lead to a leakage, and at the same
time, we want to ensure low false positive as well as low
false negative rate during this analysis. In addition, to
enable large-scale validation tasks, we do not want too
much overhead.
• Provide an easy-to-understand tool for human ana-
lysts to ascertain under what circumstance the sen-
sitive data transmission happens. Using the produced
app inputs, we need to conduct the execution of an app
according to each feasible path. We want to exercise
the app’s functionality automatically, which can em-
ulate users’ operations, and by observing the UI ma-
nipulation and prompting, we can then easily judge
whether the data transmission is essential for a user-
intended functionality.
Overall Architecture. Figure 2 depicts the overall ar-
chitecture of AppIntent, which analyzes a target app in two
steps:
• Event-space Constraint Guided Symbolic Execution. The
first step is to generate critical inputs incurring sensi-
tive data transmission. We adopt static taint analysis
to preprocess and extract all possible data transmis-
sion paths as well as possible events related to each
path, which helps to construct an event-space con-