Lifestate: Event-Driven Protocols and Callback Control Flow (Extended Version)
Shawn Meier, Sergio Mover, and Bor-Yuh Evan Chang
TL;DR
This paper introduces lifestate, a formal language for specifying and verifying event-driven application protocols, helping developers ensure correct callback control flow in frameworks like Android.
Contribution
It formalizes a core meta-model for event-driven protocols and develops lifestate, a language that unifies lifecycle and typestate rules for better protocol specification and verification.
Findings
Lifestate effectively models callback control flow and lifecycle constraints.
The verification algorithm can detect protocol violations in app traces.
Lifestate improves understanding and correctness of event-driven app behavior.
Abstract
Developing interactive applications (apps) against event-driven software frameworks such as Android is notoriously difficult. To create apps that behave as expected, developers must follow complex and often implicit asynchronous programming protocols. Such protocols intertwine the proper registering of callbacks to receive control from the framework with appropriate application-programming interface (API) calls that in turn affect the set of possible future callbacks. An app violates the protocol when, for example, it calls a particular API method in a state of the framework where such a call is invalid. What makes automated reasoning hard in this domain is largely what makes programming apps against such frameworks hard: the specification of the protocol is unclear, and the control flow is complex, asynchronous, and higher-order. In this paper, we tackle the problem of specifying and…
Click any figure to enlarge with its caption.
Figure 1
Figure 2
Figure 3
Figure 4
Figure 5
Figure 6| properties | non-crashing traces | callback control-flow models | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| top | lifecycle | lifestate | lifecycle++ | ||||||||
| sensitive | sensitive | verifiable | verified | verified | verified | verified | bad | ||||
| callin | (n) | (n) | (n) | (%) | (n) | (%) | (n) | (%) | (n) | (%) | (n) |
| AlertDialog | |||||||||||
|
dismiss |
16 | 6 | 0 | 0 | 0 | 0 | 6 | 100 | 6 | 100 | 0 |
|
show |
43 | 34 | 17 | 50 | 17 | 50 | 28 | 82 | 24 | 71 | 0 |
| AsyncTask | |||||||||||
|
execute |
4 | 4 | 0 | 0 | 4 | 100 | 4 | 100 | 0 | 0 | 0 |
| Fragment | |||||||||||
|
getResources |
10 | 10 | 0 | 0 | 0 | 0 | 10 | 100 | 4 | 40 | 0 |
|
getString |
10 | 10 | 0 | 0 | 0 | 0 | 2 | 20 | 0 | 0 | 0 |
|
setArguments |
19 | 19 | 1 | 5 | 1 | 5 | 19 | 100 | 13 | 68 | 0 |
| total | 102 | 83 | 18 | 22 | 22 | 27 | 69 | 83 | 47 | 57 | 0 |
| properties | non-crashing traces | callback control-flow models | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| top | lifecycle | lifestate | lifecycle++ | ||||||||
| sensitive | sensitive | verifiable | verified | verified | verified | verified | bad | ||||
| callin | (n) | (n) | (n) | (%) | (n) | (%) | (n) | (%) | (n) | (%) | (n) |
| AlertDialog | |||||||||||
|
dismiss |
94 | 59 | 54 | 92 | 54 | 92 | 54 | 92 | 58 | 98 | 3 |
|
show |
145 | 144 | 125 | 87 | 124 | 86 | 125 | 87 | 127 | 88 | 0 |
| AsyncTask | |||||||||||
|
execute |
415 | 415 | 0 | 0 | 415 | 100 | 412 | 99 | 262 | 63 | 0 |
| Fragment | |||||||||||
|
getResources |
156 | 155 | 89 | 57 | 89 | 57 | 128 | 83 | 116 | 75 | 0 |
|
getString |
220 | 193 | 124 | 64 | 124 | 64 | 134 | 69 | 131 | 68 | 24 |
|
setArguments |
456 | 456 | 59 | 13 | 108 | 24 | 437 | 96 | 435 | 95 | 0 |
|
startActivity |
91 | 91 | 0 | 0 | 0 | 0 | 12 | 13 | 19 | 21 | 0 |
| total | 1577 | 1513 | 451 | 30 | 914 | 60 | 1302 | 86 | 1148 | 76 | 27 |
Peer Reviews
No public reviews on file for this paper yet. If you reviewed it on a platform where reviews are public (OpenReview, ICLR, NeurIPS, ICML), you can paste yours below so the community can read it here.
Videos
No videos yet. Explain this paper in a talk, walkthrough, or lecture? Add one.
Taxonomy
TopicsAdvanced Malware Detection Techniques · Software Testing and Debugging Techniques · Advanced Software Engineering Methodologies
University of Colorado Boulder, USA École Polytechnique, France University of Colorado Boulder, USA
\CopyrightShawn Meier, Sergio Mover, and Bor-Yuh Evan Chang \ccsdesc[100]Software and its engineering Software verification
\EventEditorsAlastair F. Donaldson \EventNoEds1 \EventLongTitle33rd European Conference on Object-Oriented Programming (ECOOP 2019) \EventShortTitleECOOP 2019 \EventAcronymECOOP \EventYear2019 \EventDateJuly 15–19, 2019 \EventLocationLondon, United Kingdom \EventLogo \SeriesVolume134 \ArticleNo4
Lifestate: Event-Driven Protocols and Callback Control Flow
Shawn Meier
Sergio Mover
Bor-Yuh Evan Chang
Abstract
Developing interactive applications (apps) against event-driven software frameworks such as Android is notoriously difficult. To create apps that behave as expected, developers must follow complex and often implicit asynchronous programming protocols. Such protocols intertwine the proper registering of callbacks to receive control from the framework with appropriate application-programming interface (API) calls that in turn affect the set of possible future callbacks. An app violates the protocol when, for example, it calls a particular API method in a state of the framework where such a call is invalid. What makes automated reasoning hard in this domain is largely what makes programming apps against such frameworks hard: the specification of the protocol is unclear, and the control flow is complex, asynchronous, and higher-order. In this paper, we tackle the problem of specifying and modeling event-driven application-programming protocols. In particular, we formalize a core meta-model that captures the dialogue between event-driven frameworks and application callbacks. Based on this meta-model, we define a language called lifestate that permits precise and formal descriptions of application-programming protocols and the callback control flow imposed by the event-driven framework. Lifestate unifies modeling what app callbacks can expect of the framework with specifying rules the app must respect when calling into the framework. In this way, we effectively combine lifecycle constraints and typestate rules. To evaluate the effectiveness of lifestate modeling, we provide a dynamic verification algorithm that takes as input a trace of execution of an app and a lifestate protocol specification to either produce a trace witnessing a protocol violation or a proof that no such trace is realizable.
keywords:
event-driven systems, application-programming protocols, application framework interfaces, callbacks, sound framework modeling, predictive dynamic verification
1 Introduction
We consider the essential problem of checking that an application (app) programmed against an event-driven framework respects the required application-programming protocol. In such frameworks, apps implement callback interfaces so that the app is notified when an event managed by the framework occurs (e.g., a user-interface (UI) button is pressed). The app may then delegate back to the framework through calls to the application programming interface (API), which we term callin by analogy to callback. To develop working apps, the programmer must reason about hidden callback control flow and often implicit asynchronous programming protocols.
Couple difficult reasoning about the space of possible control flow between callbacks with insufficient framework documentation, and it is unsurprising to find some questionable “fixes” for protocol violations. In Figure 1, we show a snippet found on GitHub. The “race condition?” comment is quoted directly from the app developer. The same asynchronous, implicitly defined, control flow that make it difficult for the app developer to reason about his app is also what makes verifying the absence of such protocol violations hard.
In this paper, we focus on the problems of specifying event-driven protocols (i.e., specifying when the invocation of a callin in the app code causes a protocol violation) and modeling the callback control flow (i.e., modeling the possible executions of callbacks).
Lifecycle Automata are Insufficient for Modeling Callback Control Flow.
Lifecycle automata are a common representation used to model callback control flow that is both central to Android documentation [1, 39] and prior Android analysis techniques—both static and dynamic ones (e.g., [5, 32, 8]). In Figure 2, we show a lifecycle automaton for the Activity class of the Android framework. The black, solid edges are the edges present in the Android documentation [1] showing common callback control flow. These edges capture, for example, that the app first receives the onStart callback before entering a cycle between the onResume and the onPause callbacks. But this clean and simple class-based model quickly becomes insufficient when we look deeper.
First, there are complex relationships between the callbacks on “related” objects. For example, an OnClickListener object with an onClick callback may be “registered” on a View object that is “attached” to an Activity object . Because of these relationships, the callback control flow we need to capture is somewhat described by modifying the lifecycle automaton for Activity with the additional blue, dotted edges to and from onClick (implicitly for OnClickListener ) in Figure 2. This modified lifecycle encodes framework-specific knowledge that the OnClickListener ’s onClick callback happens only in the “active” state of Activity between its onResume and onPause callbacks, which typically requires a combination of static analysis on the app and hard-coded rules to connect callbacks on additional objects such as OnClickListeners to component lifecycles such as Activity. We refer to such callback control-flow models based on such refined lifecycle automatons as lifecycle++ models.
Second, there are less common framework-state changes that are difficult to capture soundly and precisely. For example, an analysis that relies on a callback control-flow model that does not consider the intertwined effect of a finish call may be unsound. The red, dashed edges represent callback control flow that are not documented (and thus missing from typical callback control flow models). Each one of these edges specifies different possible callback control flow that the framework imposes depending on if and when the app invokes the finish callin inside one of the Activity’s callbacks. Of course, the lifecycle automaton can be extended to include these red edges. However, this lifecycle automaton is now quite imprecise in the common case because it does not express precisely when certain callback control-flow paths are spurious (i.e., depending on where finish is not called). Figure 2 illustrates why developing callback control flow models is error prone: the effect of calls to finish are subtle and poorly understood.
It is simply too easy to miss possible callback control flow—an observation also made by Wang et al. [52] about lifecycle models. While lifecycle automata are useful for conveying the intuition of callback control flow, they are often insufficiently precise and easily unsound.
In this paper, we re-examine the process of modeling callback control flow. In prior work, modeling callback control flow was almost always a secondary concern in service to, and often built into, a specific program analysis where the analysis abstraction may reasonably mask unsound callback control flow. Instead, we consider modeling callback control flow independent of any analysis abstraction—we identify and formalize the key aspects to effectively model event-driven application-programming protocols at the app-framework interface, such as the effect of callin and callback invocations on the subsequent callback control flow, This first-principles approach enables us to validate callback control-flow soundness with real execution traces against the event-driven framework implementation. It is through this validation step that we discovered the red, dashed edges in Figure 2.
Contributions.
We make the following contributions:
- •
We identify essential aspects of event-driven control flow and application-programming protocols to formalize a core abstract machine model (Section 3). This model provides a formal basis for thinking about event-driven frameworks and their application-programming protocols.
- •
We define a language for simultaneously capturing event-driven application-programming protocols and callback control flow called lifestates, which both model what callback invocations an app can expect from the framework and specify rules the app must respect when calling into the framework (Section 4). Intuitively, lifestates offer the ability to specify traces of the event-driven program in terms of an abstraction of the observable interface between the framework and the app. And thus, this definition leads to a methodology for empirically validating lifestate models against actual interaction traces.
- •
We define lifestate validation and dynamic lifestate verification. And then, we encode them as model checking problems (Section 5). Given an app-framework interaction trace and a lifestate model, validation checks that the trace is in the abstraction of the observable interface defined by the model. This validation can be done with corpora of traces recorded from any set of apps interacting with the same framework because, crucially, the lifestate model speaks only about the app-framework interface. Then, given a trace, dynamic lifestate verification attempts to prove the absence of a rearrangement of the recorded events that could cause a protocol violation. Rearranging the execution trace of events corresponds to exploring a different sequence of external inputs and hence discovering possible protocol violations not observed in the original trace.
- •
We implement our model validation and trace verification approach in a tool called Verivita and use it to empirically evaluate the soundness and precision of callback control flow models of Android (Section 6). Our results provide evidence for the hypotheses that lifecycle models, by themselves, are insufficiently precise to verify Android apps as conforming to the specified protocols, that model validation on large corpora of traces exposes surprising unsoundnesses, and that lifestates are indeed useful.
2 Overview: Specifying and Modeling Lifestates
Here, we illustrate the challenges in specifying and modeling event-driven application-programming protocols. In particular, we motivate the need for lifestates that permit specifying the intertwined effect of callin and callback invocations. We show that even if an app is buggy, it can be difficult to witness the violation of the Android application programming protocol. Then, more importantly, we show how an appropriate fix is both subtle to reason about and requires modeling the complex callback control flow that depends on the previous execution of not only the callbacks but also the callins.
Our running example (code shown in Figure 3) is inspired by actual issues in AntennaPod [16], a podcast manager with 100,000+ installs, and the Facebook SDK for Android [27]. The essence of the issue is that a potentially time-consuming background task is started by a user interaction and implemented using the AsyncTask framework class. Figure 3 shows buggy code that can potentially violate the application-programming protocol for AsyncTask. The remover.execute() call (marked with B) throws an IllegalStateException if the AsyncTask instance, pointed-to by remover, is already running. So a protocol rule for AsyncTask is that .execute() cannot be called twice for the same AsyncTask . The IllegalStateException type is commonly used to signal a protocol violation and has been shown to be a significant source of Android crashes [28].
In Figure 3, the RemoverActivity defines an app window that, on creation (via the onCreate callback), registers a click listener (via the button.setOnClickListener() call on line 3). This registration causes the framework to notify the app of a button click through the onClick method. When that happens, the onClick callback starts the FeedRemover asynchronous task (via the remover.execute() call on line 5). What to do asynchronously is defined in the doInBackground callback, and when the FeedRemover task is done, the framework delegates to the onPostExecute callback, which closes the RemoverActivity (via the call to activity.finish()).
We diagram a common-case execution trace in Figure 4(a). Even though the app is buggy, the trace does not witness the protocol violation. The exception does not manifest because the user only clicks once (Click) before the FeedRemover task completes and generates the post-execute event (PostExecute). And so the (t:AsyncTask).execute() callin on the AsyncTask instance t is executed only once before the activity is closed (cf. the onClick and onPostExecute callbacks in Figure 3).
If typically the Activity is quickly destroyed after the button click, then seeing a protocol violation in a test is quite unlikely. However, it is possible to click a second time before the AsyncTask completes, thereby witnessing a protocol violation. We show this error trace in Figure 4(b): when the app invokes the callin (t:AsyncTask).execute() for the second time in the second Click event, the framework is in a state that does not allow this transition. We say that the callin invocation is disallowed at this point, and apps must only invoke allowed callins. While the original trace Create;Click;PostExecute does not concretely witness the protocol violation, it has sufficient information to predict the error trace Create;Click;Click. It may, however, be difficult to reproduce this error trace: the button must be pressed twice before the activity.finish() method is called by the PostExecute event destroying the Activity. But how can we predict this error trace from the original one?
2.1 Predict Violations from Recorded Interactions
We define the dynamic lifestate verification problem as predicting an error trace that (possibly) witnesses a protocol violation from a trace of interactions or proving that no such error trace exists. Concretely, the input to dynamic lifestate verification is an interaction trace like the one illustrated in Figure 4(a). These traces record the sequence of invocations and returns of callbacks and callins between the framework and the app that result from an interaction sequence. A recorded trace includes the concrete method arguments and return values (e.g., the instance t from the diagrams corresponds to a concrete memory address).
The main challenge, both for the app developer and dynamic lifestate verification, is that the relevant sequence of events that leads to a state where a callin is disallowed is hidden inside the framework. The developer must reason about the evolving internal state of the framework by considering the possible callback and callin interactions between the app and the framework to develop apps that both adhere to the protocol and behave intuitively. To find a reasonable fix for the buggy app from Figure 3, let us consider again the error trace shown in Figure 4(b). Here, the developer has to reason that the (t:AsyncTask).execute() callin is allowed as soon as t is initialized by the call to (t:AsyncTask).ci:<init>() in the Create event and is disallowed just after the first call to (t:AsyncTask).execute() in the first Click event. That is, the developer must reason about what sequence of events and callins determine when a callin is allowed or disallowed.
Since callins are invoked inside callback methods and callback methods are in turn invoked by the framework to notify the app of an event, the internal framework state determines what events can happen when and hence the callback control flow. In particular, the internal framework state determines when the Create and Click events are enabled (i.e., can happen) during the execution. Thus to properly fix this app, the developer must ensure that Create happens before a Click and then only a single Click happens before a PostExecute. How can the app developer constrain the external interaction sequence to conform to this property?
In Figure 5(a), we show a fix based on the above insight that is particularly challenging to verify. The fix adds line 5(a) that disables Button button to indicate when the task has already been started. Thus, this modified version does not violate the no-execute-call-on-already-executing-AsyncTask protocol on line 5(a). To reason precisely enough about this fix, we must know that the button.setEnabled(false) call changes internal framework state that prevents the onClick from happening again. Note that this need to reason about complex control flow arises from the interactions between just two framework types Button and AsyncTask—not to mention that these two are amongst the simplest framework types in Android. There is a clear need here for better automated reasoning tools to support the app developer.
Verivita Approach.
Our dynamic verification approach explores all the possible sequences of interactions that can be obtained by replicating, removing, and reordering the events in a trace. By rearranging event traces, the algorithm statically explores different input sequences of events that a user interaction could generate. The algorithm applied to the Create;Click;PostExecute trace in Figure 4(a) from the buggy app version indeed yields the error trace Create;Click;Click (shown in Figure 4(b)). But more critically, our approach also makes it possible to prove that the fixed app version does not have any traces that violates the protocol (by rearranging Create;Click;PostExecute).
Central to our approach is capturing the essential, hidden framework state—tracking the set of enabled callbacks and the set of disallowed callins. Figure 5(b) illustrates this model state along a trace from the fixed app. After the first Click, the application disables the button to prevent a second Click via the call to (b:Button).setEnabled(false), which at that point removes l.onClick(b) from the set of enabled callbacks the framework can trigger.
Verivita addresses the dynamic verification problem by reducing it to a model checking problem. The model is a transition system with
(i) states abstracting the set of enabled callbacks and disallowed callins and
(ii) transitions capturing the possible replication, removing, and reordering of a given interaction trace.
The safety property of interest is that the transition system never visits a disallowed callin. How can we construct such a transition system that over-approximates concrete behavior while being precise enough to make alarm triage feasible? As alluded to in Section 1, lifestate specification is crucial here.
2.2 Specify Event-Driven Protocols and Model
Callback Control Flow
In Figure 6, we illustrate the essence of callback control-flow modeling as finite-state automata that over-approximate rearrangements of the Create;Click;PostExecute trace shown in Figure 5(b). Automaton 6(a) exhibits the trivially sound, unconstrained, “top” abstraction that considers all replications, removals, and reorderings of the interaction trace. This abstraction is the one that assumes all callbacks are always enabled. Since a possible trace in this abstraction includes two Click events, a sound verifier must alarm. Meanwhile, Automaton 6(b) shows a refined abstraction encoding the Android-specific Activity lifecycle. The abstraction is framework-specific but application-independent and captures that the Create event cannot happen more than once. The abstraction shown by Automaton 6(b) is also insufficient to verify the trace from the fixed app because two Click events are still possible.
Automaton 6(c) shows a refined, lifecycle++ abstraction that considers the Activity lifecycle with additional constraints on an “attached” Click event. This abstraction is representative of the current practice in callback control-flow models (e.g., [5, 32, 8]). While Automaton 6(c) restricts the Click event to come only after the Create event, the abstraction is still too over-approximate to verify that the trace from the fixed app is safe—two Click events are still possible with this model. But worse is that this model is still, in essence, a lifecycle model that is constrained by Android-specific notions like View attachment, Listener registration, and the “live” portion of lifecycles. In existing analysis tools, such constrained lifecycle models are typically hard-coded into the analyzer.
We need a better way to capture how the application may affect callback control flow. In this example, we need to capture the effect of the callin button.setEnabled(false) at line 5(a) in Figure 5(a), which is the only difference with the buggy version in Figure 3. The modeling needs to be expressive to remove such infeasible traces and compositional to express state changes independently. Thus, the role of lifestate specification is to describe how the internal model state is updated by observing the history of intertwined callback and callin invocations. For example, we write
[TABLE]
to model when (:Button).setEnabled(false) is invoked, the click callback is disabled on the same button (on all listeners ). Also, we similarly specify the safety property of interest
[TABLE]
that when (:AsyncTask).execute() is called on a task , it disallows itself. And analogously, lifestates include specification forms for enabling callbacks or allowing callins.
Lifestate uniformly models the callback control-flow and specifies event-driven application-programming protocols. The rules that enable and disable callbacks model what callbacks the framework can invoke at a specific point in the execution of the application, while the rules that disallow and allow callins specify what callins the application must invoke to respect the protocol. What makes lifestate unique compared to typestates [50] or lifecycle automata is this unification of the intertwined effects of callins and callbacks on each other.
The complexity of the implicit callback control flow is what makes expressing and writing correct models challenging. An issue whose importance is often under-estimated when developing callback control-flow models is how much the model faithfully reflects the framework semantics. How can we validate that a lifestate specification is a correct model of the event-driven framework?
Validating Event-Driven Programming Protocols.
As argued in Section 1, a key concern when developing a framework model is that it must over-approximate the possible real behavior of the application. The “top” model as shown in Automaton 6(a) trivially satisfies this property, and it may be reasonable to validate an application-independent lifecycle model like Automaton 6(c). However, as we have seen, verifying correct usage of event-driven protocols typically requires callback control-flow models with significantly more precision.
Automaton 6(d) shows a correct lifestate-abstraction that contains an edge labeled PostExecute. We express this edge with the rule shown below:
[TABLE]
This rule states that when (:AsyncTask).execute() is called, its effect is to enable the callback (:AsyncTask).onPostExecute() on the AsyncTask .
If we do not model this rule, we obtain the abstraction in Automaton 6(e). The lifestate model is unsound since it misses the PostExecute edge.
The trace Create;Click;PostExecute shown in Figure 5(b) is a witness of the unsoundness of the abstraction: Automaton 6(e) accepts only proper prefixes of the trace (e.g., Create;Click), and hence the abstraction does not capture all the possible traces of the app. We can thus use interaction traces to validate lifestate rules: a set of lifestate rules is valid if the abstraction accepts all the interaction traces. The validation applied to the abstraction shown in Automaton 6(e) demonstrates that the abstraction accepts Create;Click as the longest prefix of the trace Create;Click;PostExecute. This information helps to localize the cause for unsoundness since we know that after the sequence Create;Click, the callback PostExecute is (erroneously) disabled.
The encoding of the abstraction from lifestate rules is a central step to perform model validation and dynamic verification. At this point, we still cannot directly encode the abstraction since the lifestate rules contain universally-quantified variables. How can we encode the lifestate abstraction as a transition system amenable to check language inclusion for validation, and to check safety properties for dynamic verification?
From Specification to Validation and Verification.
Generalizing slightly, we use the term message to refer to any observable interaction between the framework and the app. Messages consist of invocations to and returns from callbacks and callins. The abstract state of the transition system is then a pair consisting of the permitted-back messages from framework to app and the prohibited-in messages from app to framework. And thus generalizing the example rules shown above, a lifestate specification is a set of rules whose meaning is,
[TABLE]
There are many possible choices and tradeoffs for the matching language . As is common, we consider a regular expression-based (i.e., finite automata-based) matching language.
We exploit the structure of the validation and dynamic verification problem to encode the lifestate abstraction. In both problems, the set of possible objects and parameters is finite and determined by the messages recorded in the trace. We exploit this property to obtain a set of ground rules (rules without variables). We can then encode each ground rule in a transition system. Since the rule is ground, the encoding is standard: each regular expression is converted to an automaton and then encoded in the transition system, changing the permitted-prohibited state as soon as the transition system visits a trace accepted by the regular expression, which implicitly yields a model like automata 6(d).
Lifestate offers a general and flexible way to specify the possible future messages in terms of observing the past history of messages. It, however, essentially leaves the definition of messages and what is observable abstract. What observables characterize the interactions between an event-driven framework and an app that interfaces with it? And how do these observables define event-driven application-programming protocols and callback control flow?
2.3 Event-Driven App-Framework Interfaces
Lifestate rules are agnostic to the kinds of messages they match and effects they capture on the internal abstract state. To give meaning to lifestates, we formalize the essential aspects of the app-framework interface in an abstract machine model called in Section 3. This abstract machine model formally characterizes what we consider an event-driven framework. The abstract machine crisply defines the messages that the app and the framework code exchange and a formal correspondence between concrete executions of the program and the app-framework interface. We use this formal correspondence to define the semantics of the lifestate framework model, its validation problem, and protocol verification.
We do not intend for to capture all aspects of something as complex as Android; rather, the purpose of is to define a “contract” by which to consider a concrete event-driven framework implementation. And thus, also defines the dynamic-analysis instrumentation we perform to record observable traces from Android applications that we then input to the Verivita tool to either validate a specification or verify protocol violations.
Preview.
We have given a top-down overview of our approach, motivating with the dynamic protocol verification problem the need for having both a precise callback control-flow model and an event-driven protocol specification. We also presented how the lifestate language addresses this need capturing the intertwined effect of callins and callbacks. In the next sections, we detail our approach in a bottom-up manner—beginning with formalizing the abstract machine model. We show that, assuming such a model of execution, it is possible to provide a sound abstraction of the framework (i.e., no real behavior of the framework is missed by the abstraction) expressed with a lifestate model. We then formalize how we validate such models and how we use lifestates to verify the absence of protocol violations.
3 Defining Event-Driven Application-Programming Protocols
Following Section 2, we want to capture the essence of the app-framework interface with respect to framework-imposed programming protocols. To do so, we first formalize a small-step operational semantics for event-driven programs with an abstract machine model . The abstract machine draws on standard techniques but explicitly highlights enabled events and disallowed callins to precisely define event-driven protocols. We then instrument this semantics to formalize the interface of the event-driven framework with an app, thereby defining the traces of the observable app-framework interface of a program.
This language is intentionally minimalistic to center on capturing just the interface between event-driven frameworks and their client applications. By design, we leave out many aspects of real-world event-driven framework implementations (e.g., Android, Swing, or Node.js), such as typing, object-orientation, and module systems that are not needed for formalizing the dialogue between frameworks and their apps (cf. Section 2). Our intent is to illustrate, through examples, that event-driven frameworks could be implemented in and that makes explicit the app-framework interface to define observable traces consisting of back-messages and in-messages (Section 3.3).
3.1 Syntax: Enabling, Disabling, Allowing, and Disallowing
The syntax of is shown at the top of Figure 7(a), which is a -calculus in a let-normal form. The first two cases of expressions split the standard call-by-value function application into multiple steps (similar to call-by-push-value [30]). The {\leavevmode\hbox{\set@color\text{\leavevmode\lstinline{{\lst@@@set@language\lst@@@set@numbers\lst@@@set@frame\lst@@@set@rulecolor\lst@@@set@language\lst@@@set@language{@listingGroup{ltx_lst_identifier}{bind}}}}}}}\;\lambda\;v expression creates a thunk by binding a function value with an argument value . We abuse notation slightly by using as the meta-variable for function values (rather than as a terminal symbol). A thunk may be forced by direct invocation {\leavevmode\hbox{\set@color\text{\leavevmode\lstinline{{\lst@@@set@language\lst@@@set@numbers\lst@@@set@frame\lst@@@set@rulecolor\lst@@@set@language\lst@@@set@language{@listingGroup{ltx_lst_identifier}{invoke}}}}}}}\;\kappa—or indirectly via event dispatch.
Example 3.1** (Applying a Function).**
Let t be bound to an AsyncTask and onPostExecute to an app-defined callback (e.g., onPostExecute from Figure 5(a)), then the direct invocation of a callback from the framework can be modeled by the two steps of binding and then invoking:
⬇ let cb = bind cb:onPostExecute t in invoke cb
Now in , a thunk may or may not have the permission to be forced. Revoking and re-granting the permission to force a thunk via direct invocation is captured by the expressions {\leavevmode\hbox{\set@color\text{\leavevmode\lstinline{{\lst@@@set@language\lst@@@set@numbers\lst@@@set@frame\lst@@@set@rulecolor\lst@@@set@language\lst@@@set@language{@listingGroup{ltx_lst_identifier}{disallow}}}}}}}\;\kappa and {\leavevmode\hbox{\set@color\text{\leavevmode\lstinline{{\lst@@@set@language\lst@@@set@numbers\lst@@@set@frame\lst@@@set@rulecolor\lst@@@set@language\lst@@@set@language{@listingGroup{ltx_lst_identifier}{allow}}}}}}}\;\kappa, respectively. A protocol violation can thus be modeled by an application invoking a disallowed thunk.
The direct invocation expressions are mirrored with expressions for event dispatch. An {\leavevmode\hbox{\set@color\text{\leavevmode\lstinline{{\lst@@@set@language\lst@@@set@numbers\lst@@@set@frame\lst@@@set@rulecolor\lst@@@set@language\lst@@@set@language{@listingGroup{ltx_lst_emph2}{enable}}}}}}}\;\kappa expression enables a thunk for the external event-processing system (i.e., gives the system permission to force the thunk ), while the {\leavevmode\hbox{\set@color\text{\leavevmode\lstinline{{\lst@@@set@language\lst@@@set@numbers\lst@@@set@frame\lst@@@set@rulecolor\lst@@@set@language\lst@@@set@language{@listingGroup{ltx_lst_emph2}{disable}}}}}}}\;\kappa expression disables the thunk .
Example 3.2** (Enabling an Event).**
Let t be bound to an AsyncTask and handlePostExecute to an internal framework-defined function for handling a post-execute event, then enqueuing such an event can be modeled by the two steps of binding then enabling:
⬇ let h = bind handlePostExecute t in enable h
By separating function application and event dispatch into binding to create a thunk and then forcing it, we uniformly make thunks the value form that can be granted permission to be invoked (via {\leavevmode\hbox{\set@color\text{\leavevmode\lstinline{{\lst@@@set@language\lst@@@set@numbers\lst@@@set@frame\lst@@@set@rulecolor\lst@@@set@language\lst@@@set@language{@listingGroup{ltx_lst_identifier}{allow}}}}}}}\;\kappa) or for event dispatch (via {\leavevmode\hbox{\set@color\text{\leavevmode\lstinline{{\lst@@@set@language\lst@@@set@numbers\lst@@@set@frame\lst@@@set@rulecolor\lst@@@set@language\lst@@@set@language{@listingGroup{ltx_lst_emph2}{enable}}}}}}}\;\kappa). The {\leavevmode\hbox{\set@color\text{\leavevmode\lstinline{{\lst@@@set@language\lst@@@set@numbers\lst@@@set@frame\lst@@@set@rulecolor\lst@@@set@language\lst@@@set@language{@listingGroup{ltx_lst_identifier}{force}}}}}}}\;\kappa expression is then an intermediate that represents a thunk that is forcible (i.e., has been permitted for forcing via {\leavevmode\hbox{\set@color\text{\leavevmode\lstinline{{\lst@@@set@language\lst@@@set@numbers\lst@@@set@frame\lst@@@set@rulecolor\lst@@@set@language\lst@@@set@language{@listingGroup{ltx_lst_identifier}{allow}}}}}}}\;\kappa or {\leavevmode\hbox{\set@color\text{\leavevmode\lstinline{{\lst@@@set@language\lst@@@set@numbers\lst@@@set@frame\lst@@@set@rulecolor\lst@@@set@language\lst@@@set@language{@listingGroup{ltx_lst_emph2}{enable}}}}}}}\;\kappa).
The remainder of the syntax is the standard part of the language: values , variable binding {{\leavevmode\hbox{\set@color\text{\leavevmode\lstinline{{\lst@@@set@language\lst@@@set@numbers\lst@@@set@frame\lst@@@set@rulecolor\lst@@@set@language\lst@@@set@language{@listingGroup{ltx_lst_identifier}{let}}}}}}}\;x\;\text{{=}}\;e_{1}\;\leavevmode\hbox{\set@color\text{\leavevmode\lstinline{{\lst@@@set@language\lst@@@set@numbers\lst@@@set@frame\lst@@@set@rulecolor\lst@@@set@language\lst@@@set@language{@listingGroup{ltx_lst_identifier}{in}}}}}}}\;e_{2}, and whatever other operations of interest (e.g., arithmetic, tuples, control flow, heap manipulation). That is, we have made explicit the expressions to expose the app-framework interface and can imagine whatever standard language features in in framework implementations. The values of this expression language are variables , function values , thunks , unit , and whatever other base values of interest . Two exceptions are that (1) the currently active thunk is available via the thk identifier (see Section 3.2) and (2) functions are tagged with a package (see Section 3.3).
3.2 Semantics: Protocol Violations
At the bottom of Figure 7(a), we consider an abstract machine model enriched with an enabled-events store , and a disallowed-calls store . These are finite sets of thunks, which we write as a list . The enabled-events store saves thunks that are permitted to be forced by the event loop, while the disallowed-calls store lists thunks that are not permitted to be forced by invocation. These thunk stores make explicit the event-driven application-programming protocol (that might otherwise be implicit in, for example, flag fields and conditional guards).
A machine state consists of an expression , enabled events , disallowed calls , and a continuation . A continuation can be the top-level continuation or a continuation for returning to the body of a let expression, which are standard. Continuations are also used to record the active thunk via and corresponding to the run-time stack of activation records. These continuation forms record the active thunk and are for defining messages and the app-framework interface in Section 3.3. Since events occur non-deterministically and return to the main event loop, it is reasonable to assume that a state should also include a heap, and the expression language should have heap-manipulating operations through which events communicate. We do not, however, formalize heap operations since they are standard.
We define an operational semantics in terms of the judgment form for a small-step transition relation. In Figure 7(b), we show the inference rules defining the reduction steps related to enabling-disabling, disallowing-allowing, invoking, creating, and finally forcing thunks. The rules follow closely the informal semantics discussed in Section 3.1. Observe that Enable and Allow both permit a thunk to be forced, and Disable and Disallow remove the permission to be forced for a thunk. The difference between Enable and Disable versus Allow and Disallow is that the former pair modifies the enabled events , while the latter touches the disallowed calls .
The Event rule says that when the expression is a value and the continuation is the top-level continuation , then a thunk is non-deterministically chosen from the enabled events to force. Observe that an enabled event remains enabled after an Event reduction, hence can model both events that do not self-disable (e.g., the Click event from Section 2) and those that are self-disabling (e.g., the Create event). The Invoke rule has a similar effect, but it checks that the given thunk is not disallowed in before forcing. The InvokeDisallowed rule states that a disallowed thunk terminates the program in the state. And the Bind rule simply states that thunks are created by binding an actual argument to a function value.
The Force rule implements the “actual application” that reduces to the function body with the argument substituted for the formal and the thunk substituted for the identifier thk, that is, {[\kappa/\leavevmode\hbox{\set@color\text{\leavevmode\lstinline{{\lst@@@set@language\lst@@@set@numbers\lst@@@set@frame\lst@@@set@rulecolor\lst@@@set@language\lst@@@set@language{@listingGroup{ltx_lst_identifier}{thk}}}}}}}][v^{\prime}/x^{\prime}]e^{\prime}. To record the stack of activations, we push the forced thunk on the continuation (via ). The Return and Finish rules simply state that the recorded thunk frames are popped on return from a Force and Event, respectively. The Return rule returns to the caller via the continuation , while the Finish rule returns to the top-level event loop . The last line with the Let and Continue rules describe, in a standard way, evaluating let-binding.
A program violates the event-driven protocol if it ends in the state from the initial state .
Example 3.3** (Asserting a Protocol Property.).**
The no-execute-call-on-already-executing-AsyncTask protocol can be captured by a disallow. We let execute be a framework function (i.e., tagged with fwk) that takes an AsyncTask t.
⬇ let ci:execute = (t =>{{}_{{\leavevmode\hbox{\set@color\text{\leavevmode\lstinline{{\lst@@@set@language\lst@@@set@numbers\lst@@@set@frame\lst@@@set@rulecolor\lst@@@set@language\lst@@@set@language{@listingGroup{ltx_lst_emph5}{fwk}}}}}}}}} disallow thk; let h = bind handlePostExecute t in enable h)
The execute function first disallows itself (via disallow thk) and does some work (via ) before enabling the handlePostExecute event handler (writing as syntactic sugar for sequencing). The disallow thk asserts that this thunk cannot be forced again—doing so would result in a protocol violation (i.e., the state).
In contrast to an event-driven framework implementation, the state of a program does not have a queue. As we see here, a queue is an implementation detail not relevant for capturing event-driven programming protocols. Instead, models the external environment, such as, user interactions, by the non-deterministic selection of an enabled event.
3.3 Messages, Observable Traces, and the App-Framework Interface
To minimally capture how a program is composed of separate framework and app code, we add some simple syntactic restrictions to programs. Function values tagged with the fwk are framework code and the app tag labels app code. We express a framework implementation {\langle\mathbf{Fun}_{{\leavevmode\hbox{\set@color\text{\leavevmode\lstinline{{\lst@@@set@language\lst@@@set@numbers\lst@@@set@frame\lst@@@set@rulecolor\lst@@@set@language\lst@@@set@language{@listingGroup{ltx_lst_emph5}{fwk}}}}}}}}},\lambda_{\mathbf{init}}\rangle with a finite set of framework functions {\mathbf{Fun}_{{\leavevmode\hbox{\set@color\text{\leavevmode\lstinline{{\lst@@@set@language\lst@@@set@numbers\lst@@@set@frame\lst@@@set@rulecolor\lst@@@set@language\lst@@@set@language{@listingGroup{ltx_lst_emph5}{fwk}}}}}}}}} and an initialization function {\lambda_{\mathbf{init}}\in\mathbf{Fun}_{{\leavevmode\hbox{\set@color\text{\leavevmode\lstinline{{\lst@@@set@language\lst@@@set@numbers\lst@@@set@frame\lst@@@set@rulecolor\lst@@@set@language\lst@@@set@language{@listingGroup{ltx_lst_emph5}{fwk}}}}}}}}}. A program uses the framework implementation if it first invokes the function , and all the functions labeled as fwk in are from {\mathbf{Fun}_{{\leavevmode\hbox{\set@color\text{\leavevmode\lstinline{{\lst@@@set@language\lst@@@set@numbers\lst@@@set@frame\lst@@@set@rulecolor\lst@@@set@language\lst@@@set@language{@listingGroup{ltx_lst_emph5}{fwk}}}}}}}}}.
In a typical, real-world framework implementation, the framework implicitly defines the application-programming protocol with internal state to check for protocol violations. The Enable, Disable, Allow, and Disallow transitions make explicit the event-driven protocol specification in . Thus, it is straightforward to capture that framework-defined protocols by syntactically prohibiting the app from using {\leavevmode\hbox{\set@color\text{\leavevmode\lstinline{{\lst@@@set@language\lst@@@set@numbers\lst@@@set@frame\lst@@@set@rulecolor\lst@@@set@language\lst@@@set@language{@listingGroup{ltx_lst_emph2}{enable}}}}}}}\;\kappa, {\leavevmode\hbox{\set@color\text{\leavevmode\lstinline{{\lst@@@set@language\lst@@@set@numbers\lst@@@set@frame\lst@@@set@rulecolor\lst@@@set@language\lst@@@set@language{@listingGroup{ltx_lst_emph2}{disable}}}}}}}\;\kappa, {\leavevmode\hbox{\set@color\text{\leavevmode\lstinline{{\lst@@@set@language\lst@@@set@numbers\lst@@@set@frame\lst@@@set@rulecolor\lst@@@set@language\lst@@@set@language{@listingGroup{ltx_lst_identifier}{allow}}}}}}}\;\kappa, and {\leavevmode\hbox{\set@color\text{\leavevmode\lstinline{{\lst@@@set@language\lst@@@set@numbers\lst@@@set@frame\lst@@@set@rulecolor\lst@@@set@language\lst@@@set@language{@listingGroup{ltx_lst_identifier}{disallow}}}}}}}\;\kappa. Again, the enabled-event store and the disallowed-call store in can be seen as making explicit the implicit internal state of event-driven frameworks that define their application-programming protocols.
The app interacts with the framework only by “exchanging messages.” The app-framework dialogue diagrams from Figures 4(a), 4(b), and 5(b) depicts the notion of messages as arrows back-and-forth between the framework and the app. The framework invokes callbacks and returns from callins (the arrows from left to right), while the app invokes callins and returns from callbacks (the arrows from right to left). To formalize this dialogue, we label the observable transitions in the judgment form and define an observable trace—a trace formed only by these observable messages. Being internal to the framework, the Enable, Disable, Allow, and Disallow transitions are hidden, or unobservable, to the app.
In Figure 8, we define the judgment form \smash{\sigma\stackrel{{\scriptstyle\text{\normalsize\longrightarrow}}}{{\text{\scriptsize{{m}}}}}\sigma^{\prime}}, which instruments our small-step transition relation with message . Recall from Section 2 that we define a callback as an invocation that transitions from framework to app code and a callin as an invocation from app to framework code. In , this definition is captured crisply by the execution context in which a thunk is forced. In particular, we say that a thunk is a callback invocation if the underlying callee function is an app function (package app), and it is called from a framework function (package fwk) as in rule ForceCallback. The function inspects the continuation for the running, caller thunk. The function gets the package of the running thunk.
Analogously, a thunk is a callin if the callee function is in the fwk package, and the caller thunk is in the app package via rule ForceCallin.
Example 3.4** (Observing a Callback).**
Letting handlePostExecute be a framework function (i.e., in package fwk) and onPostExecute be an app function, the observable transition from the framework to the app defines the forcing of cb as a callback:
⬇ let cb:onPostExecute = (t =>{{}_{{\leavevmode\hbox{\set@color\text{\leavevmode\lstinline{{\lst@@@set@language\lst@@@set@numbers\lst@@@set@frame\lst@@@set@rulecolor\lst@@@set@language\lst@@@set@language{@listingGroup{ltx_lst_emph5}{app}}}}}}}}} ) in
let handlePostExecute = (t =>{{}_{{\leavevmode\hbox{\set@color\text{\leavevmode\lstinline{{\lst@@@set@language\lst@@@set@numbers\lst@@@set@frame\lst@@@set@rulecolor\lst@@@set@language\lst@@@set@language{@listingGroup{ltx_lst_emph5}{fwk}}}}}}}}} let cb = bind cb:onPostExecute t in invoke cb) in
In the above, we focused on the transition back-and-forth between framework and app code via calls. Returning from calls can also be seen as a “message exchange” with a return from a callin as another kind of back-message going from framework code to app code (left-to-right in the figures from Section 2). We write a callin-return back-message indicating the returning thunk with return value . Likewise, a return from a callback is another kind in-message going from app code to framework code (right-to-left). We instrument returns in a similar way to forcings with the return back-message with ReturnCallin and the return in-message with ReturnCallback.
Finally to make explicit protocol violations, we instrument the InvokeDisallowed rule to record the disallowed-callin invocations. These rules replace the corresponding rules Force, Return, and InvokeDisallowed from Figure 7(b). For replacing the Force and Return rules, we elide two rules, one for each, where there is no switch in packages (i.e., where is the package of the callee message). These “uninteresting” rules and the remaining rules defining the original transition relation not discussed here are simply copied over with an empty message label .
Observable Traces and Dynamic-Analysis Instrumentation.
As described above, the app-framework interface is defined by the possible messages that can exchanged where messages consist of callback-callin invocations and their returns. A possible app-framework interaction is thus a trace of such observable messages.
Definition 3.5** (App-Framework Interactions as Observable Traces).**
Let be the path semantics of expressions that collects the finite sequences of alternating state-transition-state triples according to the instrumented transition relation \smash{\sigma\stackrel{{\scriptstyle\text{\normalsize\longrightarrow}}}{{\text{\scriptsize{{m}}}}}\sigma^{\prime}}. Then, an observable trace is a finite sequence of messages obtained from a path by dropping the intermediate states and keeping the non- messages. We write for the set of the observable traces obtained from the set of paths, , of an expression .
An observable trace violates the event-driven application-programming protocol if ends with a disallowed message.
These definitions yield a design for a dynamic-analysis instrumentation that observes app-framework interactions. The trace recording in Verivita obtains observable traces like the app-framework dialogue diagrams in Section 2 by following the instrumented semantics \smash{\sigma\stackrel{{\scriptstyle\text{\normalsize\longrightarrow}}}{{\text{\scriptsize{{m}}}}}\sigma^{\prime}}. Verivita maintains a stack similar to the continuation to emit the messages corresponding to the forcings and returns of callbacks and callins, and it emits disallowed messages by observing the exceptions thrown by the framework.
4 Specifying Protocols and Modeling Callback Control Flow
Using as a concrete semantic foundation, we first formalize an abstraction of event-driven programs composed of separate app and framework code with respect to what is observable at the app-framework interface. This abstract transition system captures the possible enabled-event and disallowed-call stores internal to the framework that are consistent with observable traces, essentially defining a family of lifestate framework abstractions. Then, we instantiate this definition for a specific lifestate language that both specifies event-driven application-programming protocols and models callback control flow.
The main point in these definitions is that lifestate modeling of callback control flow can only depend on what is observable at the app-framework interface. Furthermore, the concrete semantic foundation given by leads to a careful definition of soundness and precision and a basis for model validation and predictive-trace verification (Section 5).
Abstracting Framework-Internal State by Observing Messages
In Figure 9, we define the transition system that abstracts the framework-internal state consistent with an observable trace . An abstract state contains a store of permitted back-messages and a store of prohibited in-messages . What the transition system captures are the possible traces consistent with iteratively applying a framework abstraction to the current abstract state: it performs a transition with a back-message {m^{\text{\tiny\mathbf{bk}}}} only if {m^{\text{\tiny\mathbf{bk}}}} is permitted {m^{\text{\tiny\mathbf{bk}}}}\in\hat{\mu}, and a transition with an in-message {m^{\text{\tiny\mathbf{in}}}} only if {m^{\text{\tiny\mathbf{in}}}} is not prohibited {m^{\text{\tiny\mathbf{in}}}}\not\in\hat{\nu}. The trace in an abstract state saves the history of messages observed so far. In the most general setting for modeling the event-driven framework, the transition system can update the stores and as a function of the history of the observed messages . These updates are formalized with the store-update functions \smash{\operatorname{upd}^{\text{\tiny\mathbf{bk}}}_{{\boldsymbol{S}}}({\omega},{\hat{\mu}})} and \smash{\operatorname{upd}^{\text{\tiny\mathbf{in}}}_{{\boldsymbol{S}}}({\omega},{\hat{\nu}})} that define an abstraction of the event-driven framework describing both its application-programming protocol and its callback control flow. A framework abstraction also defines the initial abstract state that contains the initial (abstract) state of the stores of the permitted back-messages and prohibited in-messages.
The semantics of a framework abstraction is the set of observable traces of the transition system defined in Figure 9 instantiated with . We get sequences of states from the transition relation , read the observable trace from the final state, and form a set of all such observable traces.
Definition 4.1** (Soundness of a Framework Abstraction).**
(1) *A framework abstraction is a sound abstraction of a program if ; * (2) *A framework abstraction is a sound abstraction of a framework implementation {\langle\mathbf{Fun}_{{\leavevmode\hbox{\set@color\text{\leavevmode\lstinline{{\lst@@@set@language\lst@@@set@numbers\lst@@@set@frame\lst@@@set@rulecolor\lst@@@set@language\lst@@@set@language{@listingGroup{ltx_lst_emph5}{fwk}}}}}}}}},\lambda_{\mathbf{init}}\rangle if and only if is sound for every possible program that uses the framework implementation {\langle\mathbf{Fun}_{{\leavevmode\hbox{\set@color\text{\leavevmode\lstinline{{\lst@@@set@language\lst@@@set@numbers\lst@@@set@frame\lst@@@set@rulecolor\lst@@@set@language\lst@@@set@language{@listingGroup{ltx_lst_emph5}{fwk}}}}}}}}},\lambda_{\mathbf{init}}\rangle. *
The possible observable traces of a framework abstraction is slightly richer than observable traces in that callback-return messages may also be prohibited (in addition callin-invocations ). Prohibiting callback-return messages corresponds to specifying a protocol where the app yields an invalid return value. If we desire to capture such violations at the concrete level, it is straightforward to extend with “return-invalid” transitions by analogy to InvokeDisallowed transitions.
Finally, if and are sound specifications, we say that is at least as precise as if .
A Lifestate Abstraction.
We arrive at lifestates by instantiating the framework abstraction in a direct way as shown in Figure 10. To describe rules independent of particular programs or executions, we parametrize messages with symbolic variables . The definition of the parametrized messages is parallel to the non-parameterized version but using parameters instead of simply concrete values . We call a message ground when it does not have symbolic variables (from ), and we distinguish the ground and parameterized messages by using normal and bold fonts, respectively. For example, the parametrized callback-invocation message specifies that a callback function is invoked with an arbitrary value from . The variable can be used across several messages in a rule, expressing that multiple messages are invoked with, or return, the same value.
A lifestate abstraction is a set of rules, and a rule consists of trace matcher that when matched either permits ( operator) or prohibits ( operator) a parametrized message . As just one possible choice for the matcher , we consider to be a regular expression where the symbols of the alphabet are parametrized messages . In matching a trace to a regular expression of parametrized messages, we obtain a binding that maps symbolic variables from the parametrized messages to the concrete values from the trace. Given a binding and a message , we write to denote the message obtained by replacing each symbolic variable in with if defined.
The semantics of lifestates is given by a choice of store-update functions \operatorname{upd}^{\text{\tiny\mathbf{bk}}}_{{\boldsymbol{S}}} and \operatorname{upd}^{\text{\tiny\mathbf{in}}}_{{\boldsymbol{S}}} in Figure 10(b) and the abstract transition relation defined previously in Section 4. The store-update functions work intuitively by matching the given trace against the matchers amongst the rules in and then updating the store according to the matching rules .
To describe the store-update functions in Figure 10(b), we write to express that a trace and a binding satisfy a regular expression . The definition of this semantic relation is standard, except for parametrized messages . Here, we explain this interesting case for when the trace and the binding satisfy the regular expression (i.e., ):
[TABLE]
A necessary condition for is, for example, that must assign a value to all the variables in , to get a ground message, and the message must be equal to the trace . Note that, if there is no such ground message for with the binding , then . The full semantics of matching parametrized regular expressions is given in the extended version [33].
Now, the function \operatorname{upd}^{\text{\tiny\mathbf{bk}}}_{{\boldsymbol{S}}}({{\omega}},{\hat{\mu}}) captures how the state of the permitted back-messages store changes according to the rules . As a somewhat technical point, a back-message can only be permitted if the rules are consistent with respect to the given trace (i.e., ). The predicate holds iff there are no rules that permits and prohibits for the same message and trace . Then, if the predicate is true, the back-message {m^{\text{\tiny\mathbf{bk}}}} must not be prohibited given the trace (i.e., \neg\operatorname{prohibit}_{{\boldsymbol{S}}}({\omega},{{m^{\text{\tiny\mathbf{bk}}}}})). Finally, if back-message {m^{\text{\tiny\mathbf{bk}}}} is not prohibited, either it is permitted by a specification for this trace (i.e., \operatorname{permit}_{{\boldsymbol{S}}}({\omega},{{m^{\text{\tiny\mathbf{bk}}}}})) or it was already permitted in the current store (i.e., {m^{\text{\tiny\mathbf{bk}}}}\in\hat{\mu}). The function \operatorname{upd}^{\text{\tiny\mathbf{in}}}_{{\boldsymbol{S}}}({{\omega}},{\hat{\nu}}) is similar, but it is defined for the prohibited in-messages store . An in-message {m^{\text{\tiny\mathbf{in}}}} is prohibited first if the rules are not consistent. Then, if the rules are consistent, the in-message {m^{\text{\tiny\mathbf{in}}}} must not be permitted by this trace, and either it is prohibited by a rule for this trace or the in-message was already prohibited in the current store . The auxiliary predicates and formally capture these conditions. The predicate is true iff there is a rule in the specification that permits a message and a binding , such that the trace and the binding satisfy the regular expression (), and the ground message permitted by the rule is . The predicate is analogous but for prohibit rules.
A key point is that the store-update functions \operatorname{upd}^{\text{\tiny\mathbf{bk}}}_{{\boldsymbol{S}}}({{\omega}},{\hat{\mu}}) and \operatorname{upd}^{\text{\tiny\mathbf{in}}}_{{\boldsymbol{S}}}({{\omega}},{\hat{\nu}}) are defined only in terms of what is observable at the app-framework interface and stores of permitted back-messages and prohibited in-messages . Lifestate abstractions do not depend on framework or app expressions , nor framework-internal state.
5 Dynamic Reasoning with Lifestates
Lifestates are precise and detailed abstractions of event-driven frameworks that simultaneously specify the protocol that the app should observe and the callback control-flow assumptions that an app can assume about the framework. The formal development of lifestates in the above offers a clear approach for model validation and predictive-trace verification. In this section, we define the model validation and verification problem and provide an intuition of their algorithms using the formal development in the previous sections. For completeness of presentation, we provide further details in the extended version [33].
Validating Lifestate Specifications.
As documentation in a real framework implementation like Android is incomplete and ambiguous, it is critical that framework abstractions have a mechanism to validate candidate rules—in a manner independent of, say, a downstream static or dynamic analysis.
We say that a specification is valid for an observable trace if . If a specification is not valid for a trace from a program , then is not a sound abstraction of .
We can then describe an algorithm that checks if is a valid specification for a trace with a reduction to a model checking problem. Lifestate rules specify the behavior of an unbounded number of objects through the use of symbolic variables that are implicitly universally quantified in the language and hence describe an unbounded number of messages. However, as an observable trace has a finite number of ground messages, the set of messages that we can use to instantiate the quantifiers is also finite. Thus, the validation algorithm first “removes” the universal quantifier with the grounding process that transforms the lifestate abstraction to a ground abstraction containing only ground rules.
The language of a ground specification can be represented with a finite transition system since the set of messages in is finite, and lifestate rules are defined using regular expressions. We then pose the validation problem as a model checking problem that we solve using off-the-shelf symbolic model checking tools [12]. The transition system that we check is the parallel composition (i.e., the intersection of the languages of transition systems) of the transition system that accepts only the trace and the transition system parametrized by the grounded lifestate abstraction . The lifestate abstraction is valid if and only if the composed transition system reaches the last state of the trace .
Dynamic Lifestate Verification
Because of the previous sections building up to lifestate validation, the formulation of the dynamic verification is relatively straightforward and offers a means to evaluate the expressiveness of lifestate specification.
We define the set of sub-traces of a trace as , where if is a substring of that represents the entire execution of a callback directly invoked by an event handler. We consider the set of all the traces obtained by repeating the elements in zero-or-more times and its intersection with the traces of the program .
Given an observable trace of the program (i.e., ), the dynamic verification problem consists of proving the absence of a trace that violates the application-programming protocol. Since we cannot know the set of traces for a program (i.e., the set of traces for the app composed with the framework implementation), we cannot solve the dynamic verification problem directly. Instead, we solve an abstract version of the problem, where we use a lifestate specification to abstract the framework implementation {\langle\mathbf{Fun}_{{\leavevmode\hbox{\set@color\text{\leavevmode\lstinline{{\lst@@@set@language\lst@@@set@numbers\lst@@@set@frame\lst@@@set@rulecolor\lst@@@set@language\lst@@@set@language{@listingGroup{ltx_lst_emph5}{fwk}}}}}}}}},\lambda_{\mathbf{init}}\rangle. Let be the set of repetitions of the trace that can be seen in the app-framework interface abstraction defined by .
Given a trace and a sound specification , the abstract dynamic verification problem consists of proving the absence of a trace that violates the application-programming protocol. If we do not find any protocol violation using a specification , then there are no violations in the possible repetitions of the concrete trace . Observe that the key verification challenge is getting a precise enough framework abstraction that sufficiently restricts the possible repetitions of the concrete trace .
We reduce the abstract dynamic verification problem to a model checking problem in a similar way to validation: we first generate the ground model from the lifestate model and the trace . Then, we construct the transition system that only generates traces in the set by composing the transition system obtained from the ground specification and the automaton accepting words in . This transition system satisfies a safety property iff there is no trace that violates the protocol.
6 Empirical Evaluation
We implement our approach for Android in the Verivita tool that
(i) instruments an Android app to record observable traces,
(ii) validates a lifestate model for soundness against a corpus of traces, and
(iii) assesses the precision of a lifestate model with dynamic verification.
We use the following research questions to demonstrate that lifestate is an effective language to model event-driven protocols, and validation is a crucial step to avoid unsoundness.
- RQ1
Lifestate Precision. Is the lifestate language adequate to model the callback control flow of Android? The paper hypothesizes that carefully capturing the app-framework interface is necessary to obtain precise protocol verification results. 2. RQ2
Lifestate Generality. Do lifestate models generalize across apps? We want to see if a lifestate model is still precise when used on a trace from a new, previously unseen app. 3. RQ3
Model Validation. Is validation of callback control-flow models with concrete traces necessary to develop sound models? We expect to witness unsoundnesses in existing (and not validated) callback control-flow models and that validation is a crucial tool to get sound models.
Additionally, we considered the feasibility of continuous model validation. The bottom line is that we could validate 96% of the traces within a 6 minute time budget; we discuss these results further in the extended version [33].
RQ1: Lifestate Precision.
The bottom line of Table 1 is that lifestate modeling is essential to improve the percentage of verified traces to 83%—compared to 57% for lifecycle++ and 27% for lifecycle modeling.
Methodology. We collect execution traces from Android apps and compare the precision obtained verifying protocol violations with four different callback control-flow models. The first three models are expressed using different subsets of the lifestate language. The top model is the least precise (but clearly sound) model where any callback can happen at all times, like in the Automaton 6(a) in Section 2. The lifecycle model represents the most precise callback control-flow model that we can express only using back-messages, like in Automaton 6(b). The lifestate model uses the full lifestate language, and hence also in-messages like in the Automaton 6(d), to change the currently permitted back-messages. It represents the most precise model that we can represent with lifestate. To faithfully compare the precision of the formalisms, we improved the precision of the lifecycle and lifestate models minimizing the false alarms from verification. And at the same time, we continuously run model validation to avoid unsoundnesses, as we discuss below in RQ3. As a result of this process, we modeled the behavior of several commonly-used Android classes, including Activity, Fragment, AsyncTask, CountdownTimer, View, PopupMenu, ListView, and Toolbar and their subclasses. Excluding similar rules for subclasses, this process resulted in a total of 167 lifestate rules.
We further compare with an instance of a lifecycle++ model, which refines component lifecycles with callbacks from other Android objects. Our model is a re-implementation of the model used in FlowDroid [5] that considers the lifecycle for the UI components (i.e., Activity and Fragment) and bounds the execution of a pre-defined list of callback methods in the active state of the Activity lifecycle, similarly to the example we show in Figure 2. We made a best effort attempt to faithfully replicate the FlowDroid model (and discuss how we did so in the extended version [33]).
To find error-prone protocols, we selected sensitive callins, shown in the first column of Table 1, that frequently occur as issues on GitHub and StackOverflow [16, 41, 3, 36, 47, 46]. We then specify the lifestate rules to allow and disallow the sensitive callins.
To create a realistic trace corpus for RQ1, we selected five apps by consulting Android user groups to find those that extensively use Android UI objects, are not overly simple (e.g., student-developed or sample-projects apps), and use at least one of the sensitive callins. To obtain realistic interaction traces, we recorded manual interactions from a non-author user who had no prior knowledge of the internals of the app. The user used each app 10 times for 5 minutes (on an x86 Android emulator running Android 6.0)—obtaining a set of 50 interaction traces. With this trace-gathering process, we exercise a wide range of behaviors of Android UI objects that drives the callback control-flow modeling.
To evaluate the necessity and sufficiency of lifestate, we compare the verified rates (the total number of verified traces over the total number of verifiable traces) obtained using each callback control-flow model. We further measure the verification run time to evaluate the trade-off between the expressiveness of the models and the feasibility of verification.
Discussion. In Table 1, we show the number of verified traces and the verified rates broken down by sensitive callins and different callback control-flow models—aggregated over all apps. As stated earlier, the precision improvement with lifestate is significant, essential to get to 83% verified. We also notice that the lifecycle model is only slightly more precise than the trivial top model (27% versus 22% verified rate). Even with unsoundnesses discussed later, lifecycle++ is still worse than the lifestate model, with 57% of traces proven.
Lifestate is also expressive enough to prove most verifiable traces—making manual triage of the remaining alarms feasible. We manually examined the 14 remaining alarms with the lifestate model, and we identified two sources of imprecision:
(1) an insufficient modeling of the attachment of UI components (e.g., is a View in the View tree attached to a particular Activity?), resulting in 13 alarms;
(2) a single detail on how Android options are set in the app’s XML, resulting in 1 alarm.
The former is not fundamental to lifestates but a modeling tradeoff where deeper attachment modeling offers diminishing returns on the verified rate while increasing the complexity of the model and verification times. The latter is an orthogonal detail for handling Android’s XML processing (that allows the framework to invoke callbacks via reflection).
RQ2: Lifestate Generality.
The bottom line of Table 2 is that the lifestate model developed for RQ1 as-is generalizes to provide precise results (with a verified rate of 86%) when used to verify traces from previously unseen apps. This result provides evidence that lifestates capture general behaviors of the Android framework. While the lifecycle++ model verifies 76% of traces, it also misses 27 out of 64 buggy traces (i.e., has a 42% false-negative rate).
Methodology.
To get a larger corpus, we cloned distinct open source apps repositories from GitHub that use at least one sensitive callin (the count combines forks and clones). Then, we generated execution traces using the Android UI Exerciser Monkey [2] that interacts with the app issuing random UI events (e.g., clicks, touches). We attempted to automatically generate three traces for each app file obtained by building each app.
Discussion. From Table 2, we see that the lifestate verified rate of 86% in this larger experiment is comparable with the verified rate obtained in RQ1. Moreover, lifestate still improves the verified rate with respect to lifecycle, which goes from 60% to 86%, showing that the expressivity of lifestate is necessary.
Critically, the lifecycle++ model does not alarm on 42% of the traces representing real defects. That is, we saw unsoundnesses of the lifecycle++ model manifest in the protocol verification client.
The verified rate for the lifecycle model is higher in this larger corpus (60%) compared to the rate in RQ1 (27%), and the precision improvement from the top abstraction is more substantial (60% to 30% versus 27% to 22%). This difference is perhaps to be expected when using automatically-generated traces that may have reduced coverage of app code and bias towards shallower, “less interesting” callbacks associated with application initialization instead of user interaction. In these traces, it is possible that UI elements were not exercised as frequently, which would result in more traces provable solely with the lifecycle specification. Since coverage is a known issue for the Android UI Exerciser Monkey [4]), it was critical to have some evidence on deep, manually-exercised traces as in RQ1.
Bug Triage. We further manually triage every remaining alarm from both RQ1 and RQ2. Finding protocol usage bugs was not necessarily expected: for RQ1, we selected seemingly well-developed, well-tested apps to challenge verification, and for RQ2, we did not expect automatically generated traces to get very deep into the app (and thus deep in any protocol).
Yet from the RQ1 triage, we found 2 buggy apps out of 5 total. These apps were Puzzles [10] and SwiftNotes [13]. Puzzles had two bugs, one related to AlertDialog.show and one for AlertDialog.dismiss. Swiftnotes has a defect related to AlertDialog.show.
In the RQ2 corpus, we found 7 distinct repositories with a buggy app (out of distinct repositories) from 64 buggy traces (out of ). We were able to reproduce bugs in 4 of the repositories and strongly suspect the other 3 to also be buggy. Three of the buggy apps invoke a method on Fragment that requires the Fragment to be attached. This buggy invocation happens within unsafe callbacks. Audiobug [51] invokes getResources. NextGisLogger [35] and Kistenstapeln [14] invoke getString. We are able to reproduce the Kistenstapeln bug.
Interestingly, one of the apps that contain a bug is Yamba [20], a tutorial app from a book on learning Android [21]. We note that the Yamba code appears as a part of three repositories where the code was copied (we only count these as one bug). The tutorial app calls AlertDialog.dismiss when an AsyncTask is finishing and hence potentially after the Activity object used in the AlertDialog is not visible anymore. We found similar defects in several actively maintained open source apps where callbacks in an AsyncTask object were used either to invoke AlertDialog.show or AlertDialog.dismiss. These apps included OSM Tracker [22] and Noveldroid [44]. Additionally, we found this bug in a binary library connected with the PingPlusPlus android app [38]. By examining the output of our verifier, we were able to create a test to concretely witness defects in 4 of these apps.
RQ3: Model Validation.
The plot in Figure 11 highlights the necessity of applying model validation: lifecycle++ based on a widely used callback control-flow model does not validate (i.e., an unsoundness is witnessed) on 58% of traces (and the validation ran out of memory for out of the total traces).
Methodology. We first evaluate the need for model validation by applying our approach to lifecycle++ and quantifying its discrepancies with the real Android executions.
Our first experiment validates the lifecycle++ model on all the traces we collected (bounding each validation check to 1 hour and 4 GB of memory). We quantify the necessity of model validation collecting for each trace if the model was valid and the length of the maximum prefix of the trace that the model validates. Since there are already some known limitations in the lifecycle++ model (e.g., components interleaving), we triage the results to understand if the real cause of failure is a new mistake discovered with the validation process.
Our second experiment qualitatively evaluates the necessity of model validation to develop sound lifestate specifications. To create a sound model, we started from the empty model (without rules) and continuously applied validation to find and correct mistakes. In each iteration: we model the callback control flow for a specific Android object; we validate the current model on the entire corpus of traces (limiting each trace to one hour and 4 GB of memory); and when the model is not valid for a trace, we inspect the validation result and repair the specification. We stop when the model is valid for all the traces. We then collected the mistakes we found with automatic validation while developing the lifestate model. We describe such mistakes and discuss how we used validation to discover and fix them.
Discussion: lifecycle++ Validation. From the first bar of the plot in Figure 11, we see that the lifecycle++ model validates only 42% of the total traces, while validation fails in the remaining cases (58%). The bar shows the number of traces that we validated for at least one step, grouping them by validation status and cause of validation failure. From our manual triage, we identified different broad causes for unsoundness:
i) outside the active lifecycle: the model prohibits the execution of a callback outside the modeled active state of the Activity;
ii) wrong lifecycle automata: the model wrongly prohibits the execution of an Activity or Fragment lifecycle callback;
iii) wrong start of the Fragment lifecycle: the model prohibits the start of the execution of the Fragment lifecycle;
iv) no components interleaving: the model prohibits the interleaved execution of callbacks from different Activity or Fragment objects.
The plot shows that the lifecycle++ model is not valid on 25% of the traces because it does not model the interleaving of components (e.g., the execution of callbacks from different Activity and Fragment objects cannot interleave) and the start of the Fragment lifecycle at an arbitrary point in the enclosing Activity object. With FlowDroid, such limitations are known and have been justified as practical choices to have feasible flow analyses [5]. But the remaining traces, 33% of the total, cannot be validated due other reasons including modeling mistakes. In particular, the FlowDroid model imprecisely captures the lifecycle automata (for both Activity and Fragment) and erroneously confines the execution of some callbacks in the active state of the lifecycle.
The other bars in the plot of Figure 11 show the number of traces we validated for more than 25, 50, and 75 steps, respectively. In the plot, we report the total number of steps in the execution traces that correspond to a callback or a callin that we either used in the lifestate or the lifecycle++ model, while we remove all the other messages. From such bars, we see that we usually detect the unsoundness of the lifecycle++ model “early” in the trace (i.e., in the first 25 steps). This result is not surprising since most of the modeling mistakes we found are related to the interaction with the lifecycle automata and can be witnessed in the first iteration of the lifecycle. We further discovered that the lifecycle++ model mostly validates shorter execution traces, showing that having sound models for real execution traces is more challenging, which we discuss further in the extended version [33].
Discussion: Catching Mistakes During Modeling. We were able to obtain a valid lifestate specification for over 99.9% of the traces in our corpus. That is, we were able to understand and model the objects we selected in all but two traces.
Surprisingly, we identified and fixed several mistakes in our modeling of the Activity and Fragment lifecycle that are due to undocumented Android behaviors. An example of such behavior is the effect of Activity.finish and Activity.startActivity on the callback control flow for the onClick callback. It is unsound to restrict the enabling of onClick callbacks to the active state of the Activity lifecycle (i.e., between the execution of the onResume and onPause callbacks). This is the behavior represented with blue edges in Figure 2, what is typically understood from the Android documentation, and captured in the existing callback control-flow models used for static analysis.
We implemented a model where onClick could be invoked only when its Activity was running and found this assumption to be invalid on several traces. We inferred that the mistake was due to the wrong “bounding” of the onClick callbacks in the Activity lifecycle since in all the traces:
i) the first callback that was erroneously disabled in the model was the onClick callback; and
ii) the onClick callback was disabled in the model just after the execution of an onPause callback that appeared before in the trace, without an onResume callback in between (and hence, outside the active state of the Activity.)
It turns out that both finish and startActivity cause the Activity to pause without preventing the pending onClick invocations from happening, as represented in the red edges connected to onClick in Figure 2. We validated such behaviors by writing and executing a test application and finding its description in several Stack Overflow posts [49, 48]. The fix for this issue is to detect the finishing state of the Activity and to not disable the onClick callback in this case.
7 Related Work
Several works [5, 8, 42, 45, 24, 40, 37, 43, 24] propose different callback control-flow models. Many previous works, like FlowDroid [5] and Hopper [8], directly implement the lifecycle of Android components. While the main intention of these tools is to implement the lifecycle automata, in practice, they also encode some of the effects of callins invoked in the app code in an ad-hoc manner. For example, FlowDroid determines if and where a callback (e.g., onClick) is registered using a pre-defined list of callin methods and an analysis of the app call graph. Hopper implements the lifecycle callback control flow directly in a static analysis algorithm that efficiently explores the interleaving of Android components. In contrast, our work starts from the observation that reasoning about protocol violations requires capturing, in a first-class manner, the effects that invoking a callin has on the future execution of callbacks (and vice-versa).
Callback control-flow graphs [53] are graphs of callbacks generated from an application and a manually written model of the framework. Perez and Le [37] generate callback control-flow graphs with constraints relating program variables to callback invocations analyzing the Android framework. Such models can indirectly capture callin effects via the predicates on the program state. With lifestate, we carefully focus on what is observable at the app-framework interface so that lifestate specifications are agnostic to the internal implementation details of the framework. DroidStar [40] automatically learns a callback typestate automaton for an Android object from a developer-specified set of transition labels using both callbacks and callins symbols. Such automata specifically represent the protocol for a single object and, differently from lifestate, their labels are not parameterized messages. A callback typestate is thus a coarser abstraction than lifestate since it cannot express the relationships between different message occurrences that are required to describe multi-object protocols.
There exist other classes of framework models that represent different and complementary aspects of the framework than the callback control flow captured by lifestate. For example, Fuchs et al. [19] and Bastani et al. [6] represent the “heap properties” implicitly imposed by the framework. EdgeMiner [11] and Scandal [29] model the registration of callbacks. Droidel [9] also captures callback registration by modeling the reflection calls inside the Android framework code. Similarly, Pasket [25] automatically learns implementations of framework classes that behave according to particular design patterns.
While framework models have been extensively used to support static and dynamic analysis, not much attention has been paid to validating that the models soundly capture the semantics of the real framework. Wang et al. [52] recognized the problem of model unsoundness—measuring unsoundnesses in three different Android framework models. Unsoundnesses were found even using a much weaker notion of model validation than we do in this work. A significant advantage of lifestates is that we can validate their correctness with respect to any execution trace, obtained from arbitrary apps, because they speak generically about the app-framework interface.
There exist several programming languages for asynchronous event-driven systems, such as Tasks [18] and P [15]. In principle, such languages are general enough to develop event-driven systems such as Android. The purpose of our formalization is instead to provide a formalization that captures the app-framework interface.
The protocol verification problem for event-driven applications is related to typestate verification [34, 26, 17], but it is more complex since it requires reasoning about the asynchronous interaction of both callbacks and callins. Dynamic protocol verification is similar in spirit to dynamic event-race detection [32, 23, 7, 31], which predicts if there is an event data-race from execution traces. However, a lifestate violation differs from, and is not directly comparable to, an event data-race. A lifestate violation could manifest as a data race on a framework-internal field, but more commonly it results from encountering an undesirable run-time state within the framework.
8 Conclusion
We considered the problem of specifying event-driven application-programming protocols. The key insight behind our approach is a careful distillation of what is observable at the interface between the framework and the app. This distillation leads to the abstract notions of permitted messages from the framework to the app (e.g., enabled callbacks) and prohibited messages into the framework from the app (e.g., disallowed callins). Lifestate specification then offers the ability to describe the event-driven application-programming protocol in terms of this interface—capturing both what the app can expect of the framework and what the app must respect when calling into the framework. We evaluated our approach by implementing a dynamic lifestate verifier called Verivita and showed that the richness of lifestates are indeed necessary to verify real-world Android apps as conforming to actual Android protocols.
Acknowledgements. Many thanks to Edmund S.L. Lam, Chance Roberts, and Chou Yi for help in gathering traces, as well as Alberto Griggio for a convenient tool for running tests. We also thank Aleksandar Chakarov, Maxwell Russek, the Fixr Team, and the University of Colorado Programming Languages and Verification (CUPLV) Group for insightful discussions, as well as the anonymous reviewers for their helpful comments. This material is based on research sponsored by DARPA under agreement number FA8750-14-2-0263.
The reference list from the paper itself. Each links out to its DOI / PubMed record.
- 1[1] Android Developers. The Activity lifecycle. https://developer.android.com/guide/components/activities/activity-lifecycle.html , 2018.
- 2[2] Android Developers. UI/Application exerciser monkey. https://developer.android.com/studio/test/monkey.html , 2018.
- 3[3] Android Topeka. Crash if rotate device right after press floating action button #4 Topeka for Android. https://github.com/googlesamples/android-topeka/issues/4 , 2015.
- 4[4] Yauhen Leanidavich Arnatovich, Minh Ngoc Ngo, Hee Beng Kuan Tan, and Charlie Soh. Achieving high code coverage in android UI testing via automated widget exercising. In Asia-Pacific Software Engineering Conference (APSEC) , 2016.
- 5[5] Steven Arzt, Siegfried Rasthofer, Christian Fritz, Eric Bodden, Alexandre Bartel, Jacques Klein, Yves Le Traon, Damien Octeau, and Patrick Mc Daniel. Flow Droid: Precise context, flow, field, object-sensitive and lifecycle-aware taint analysis for Android apps. In Programming Language Design and Implementation (PLDI) , 2014.
- 6[6] Osbert Bastani, Saswat Anand, and Alex Aiken. Specification inference using context-free language reachability. In Principles of Programming Languages (POPL) , 2015.
- 7[7] Pavol Bielik, Veselin Raychev, and Martin T. Vechev. Scalable race detection for Android applications. In Object-Oriented Programming Systems, Languages, and Applications (OOPSLA) , 2015.
- 8[8] Sam Blackshear, Bor-Yuh Evan Chang, and Manu Sridharan. Selective control-flow abstraction via jumping. In Object-Oriented Programming Systems, Languages, and Applications (OOPSLA) , 2015.