1 Specifying Callback Control Flow of Mobile Apps Using Finite Automata Danilo Dominguez Perez and Wei Le Abstract—Given the event-driven and framework-based architecture of Android apps, finding the ordering of callbacks executed by the framework remains a problem that affects every tool that requires inter-callback reasoning. Previous work has focused on the ordering of callbacks related to the Android components and GUI events. But the execution of callbacks can also come from direct calls of the framework (API calls). This paper defines a novel program representation, called Callback Control Flow Automata (CCFA), that specifies the control flow of callbacks invoked via a variety of sources. We present an analysis to automatically construct CCFAs by combining two callback control flow representations developed from the previous research, namely, Window Transition Graphs (WTGs) and Predicate Callback Summaries (PCSs). To demonstrate the usefulness of our representation, we integrated CCFAs into two client analyses: a taint analysis using FLOWDROID, and a value-flow analysis that computes source and sink pairs of a program. Our evaluation shows that we can compute CCFAs efficiently and that CCFAs improved the callback coverages over WTGs. As a result of using CCFAs, we obtained 33 more true positive security leaks than FLOWDROID over a total of 55 apps we have run. With a low false positive rate, we found that 22.76% of source-sink pairs we computed are located in different callbacks and that 31 out of 55 apps contain source-sink pairs spreading across components. Thus, callback control flow graphs and inter-callback analysis are indeed important. Although this paper mainly uses Android, we believe that CCFAs can be useful for modeling control flow of callbacks for other event-driven, framework-based systems. Index Terms—event-driven, framework-based, mobile, program analysis, information flow F 1 INTRODUCTION With more than 1.4 billion Android devices sold [1] and of control, such as external events and API methods, and be over 2.5 million apps in the official Android app’s market directly usable by analysis and testing tools. [2], Android has become one of the leading platforms for In this paper, we propose a novel program repre- smartphone devices. However, the complex event-driven, sentation, namely Callback Control Flow Automata (CCFA), framework-based architecture that developers use to im- to specify control flow of callbacks for event-driven and plement apps imposes new challenges on the quality of framework-based applications. The design of CCFA is based Android apps, creating new kinds of code smells and bugs on the Extended Finite State Machine (EFSM) [15], which ex- [3], [4], [5], [6]. Due to the impact of the Android apps on tends the Finite State Machine (FSM) by labeling transitions the market and the complexity of developing apps, there is using information such as guards. Using the CCFAs, we aim a need for programming tools for analyzing Android apps. to specify four types of callback control flow existing in an One of the foundational challenges for developing these app: 1) a callback B is invoked synchronously after another tools is the sequencing or ordering of callback methods. callback A, 2) B is invoked asynchronously after A, meaning Even for a small subset of callbacks, it has been shown that B is put in the event queue and invoked eventually after the current state-of-the-art tools fail to generate sequences A is invoked, 3) during an execution of A, B is invoked of callbacks that match the runtime behavior of Android synchronously by an API call, and 4) during an execution of apps [7]. A, B is invoked asynchronously by an API call. Previous tools have used manual models to obtain se- In the CCFAs, a state indicates whether the execution quences of callbacks. For instance, Pathak et al. [8] and path enters or exits a callback. The transition from one state Arzt et al. [9] used the lifecycle of components to represent to another represents the transfer of control flow between control flow between callbacks. This approach can miss callbacks. The transitions are labeled with guards, the condi- sequences of callbacks invoked in API methods such as tions under which a transition is enabled. Such a condition AsyncTask.execute and LoaderManager.initLoader. can be an external event (e.g. click the button) or an API call. Other approaches modeled a subset of callbacks, specifi- The input alphabet of the CCFA is composed by the names cally the callbacks invoked from external events including of callbacks implemented in the app. Specifically, we use GUI [10], [11], [12] and sensors’ events [13]. Another ap- callbacknameentry and callbacknameexit as input symbols proach automatically summarize the Android framework so we can specify the case where one callback is invoked to identify the control flow of callbacks implemented in during the execution of the other (see Type 3 and Type 4 the Android API methods [14]. Nevertheless, there is not of control flow discussed above). Using this approach, the a representation that integrates different sources of changes language recognized by a CCFA is a set of paths of callbacks, or possible sequences of callbacks that can be invoked at • Danilo Dominguez Perez and Wei Le are with the Department of Com- runtime for an app. puter Science, Iowa State University, Ames, Iowa, 50011. To compute CCFAs, we designed a static analysis algo- f g E-mail: danilo0,weile @iastate.edu rithm that traverses Windows Transition Graph (WTG) [10] to 2 obtain the control flow of callbacks related to the windows The rest of the paper is organized as follows. In Section 2, (activities, dialogs and menus) and GUI events, and also, in- we present an overview of our work. In Sections 3 and 4, tegrates Predicate Callback Summaries (PCSs) [14] for callback we present the definition of CCFAs and the algorithms for sequences invoked in the Android API methods. These API computing CCFAs. In Section 5 we show how to use CCFAs methods include the callbacks of the Android components’ for inter-callback analysis. The evaluation of our work is lifecycles, which are modeled manually in the previous presented in Section 6, followed by a discussion in Section 7 work. Our approach is able to automatically handle them. and the related work in Section 8. Finally, we present the In addition, we successfully added the callbacks for 9 ad- conclusions and future work in Section 9. ditional external events: GPS location updates, enabling and disabling of GPS services, sensor events, two camera external events (when the camera shutters and when the 2 AN OVERVIEW camera takes a picture), network notifications (through the Given the event-driven, framework-based architecture of ConnectivityManager), a web client and a web chrome Android apps, most of an app’s implementation is done by client that receive notifications from a WebView. The models defining callbacks that are invoked by the Android frame- for these events are constructed manually, but we show work. To perform inter-callback static analysis or testing that CCFA can be easily extended to specify external events the apps beyond unit level, it is important to discover beyond the window and GUI events. and represent the potential orders of the callbacks. In this In this paper, we show two different approaches of inte- section, we use an example to provide an overview of what grating CCFAs into static analyses. In the first approach, we is a CCFA and also the approach of computing the CCFA. extend an existing inter-procedural, context-sensitive anal- ysis to inter-callback dataflow analysis using CCFAs, and 2.1 What is a CCFA also instantiate it to compute inter-callback source and sink pairs of a program. In the second approach, we generate a In Figure 1a, we show a simple Android app that contains program using the callback invocation paths provided by one activity class called A. This activity implements the CCFAs to directly integrate CCFAs with FLOWDROID [9]. callbacks onCreate (line 3), onStart (line 7) and onStop We implemented the construction and applications of (line 15). In the callback onCreate at line 5, the app sets CCFAs using Soot and Spark. The WTGs were computed an object of type CList as the event listener for the click using GATOR [16] and the summaries for Android API event of the button b1. It also invokes the API method methods were provided by Lithium [14]. lm:initLoader at line 12 to load data, where this API call Our results show that the construction of CCFAs is uses the class L (lines 17-22) to create a loader. very efficient, reporting 29 seconds per app on average. Figure 1b shows the CCFA we constructed for Figure 1a. Compared to WTGs, CCFAs improved callback coverage The representation is designed based on the Extended Finite 10.72% on average. In the best cases, we improved the app State Machine (EFSM), and each transition is labeled with a heregps’s coverage from 50% to 100%, and for the app pair (x; g) where x is an input symbol and g is a guard. MyTracks, 78 more callbacks were integrated, improving The input symbol x can represent a callback’s entry point the callback coverage 15.30%. Applying CCFAs, our tool (see A:onCreateentry on the transition from state q1 to q2), found 33 more information leaks than FLOWDROID for 55 a callback’s exit point (see A:onCreateexit on the transition apps we ran. We also experimented on 60 apps from Droid- from state q2 to q3), or an empty input represented by (see Bench that contain inter-callback security leaks, and our tool the transition from state q4 to state q6).