Charting the API minefield using software telemetry data

Abstract

Programs draw significant parts of their functionality through the use of Application Programming Interfaces (APIs). Apart from the way developers incorporate APIs in their software, the stability of these programs depends on the design and implementation of the APIs. In this work, we report how we used software telemetry data to analyze the causes of API failures in Android applications. Specifically, we got 4.9 GB worth of crash data that thousands of applications sent to a centralized crash report management service. We processed that data to extract approximately a million stack traces, stitching together parts of chained exceptions, and established heuristic rules to draw the border between applications and the API calls. We examined a set of more than a half million stack traces associated with risky API calls to map the space of the most common application failure reasons. Our findings show that the top ones can be attributed to memory exhaustion, race conditions or deadlocks, and missing or corrupt resources. Given the classes of the crash causes we identified, we recommend API design and implementation choices, such as specific exceptions, default resources, and non-blocking algorithms, that can eliminate common failures. In addition, we argue that development tools like memory analyzers, thread debuggers, and static analyzers can prevent crashes through early code testing and analysis. Finally, some execution platform and framework designs for process and memory management can also eliminate some application crashes.

Effective and efficient API misuse detection via exception propagation and search-based testing

“…Using Catcher, we can argue about particular api misuses (related to constraints misuses and exception handling misuses) at code level. apis come also with their reference documentation, which can significantly affect the robustness of client applications [12,14,30]. If an exception that might throw at runtime is not listed in the documentation (i.e., it is unexpected), developers stay unaware of the possible manifestation of that exception at runtime.…”

“…Catcher works as follows. First, static exception propagation [24,49] (based on Soot [57]) identifies call paths that propagate runtime exceptions raised by api methods but remained unhandled in the application call sites, potentially causing application crashes [18,30]. The call sites to each one of those api methods represent candidate misuses, defining the search space for the test-case generation.…”

Testing tools for Android context-aware applications: a systematic mapping

“…Although Android applications are GUI-based and mainly written in Java, they differ from Java GUI applications, particularly by the kinds of bugs they can present [2,12]. Existing test input generation tools for Java [13][14][15] cannot be directly used to test Android apps, and custom tools must be adopted instead.…”

Reproducing context-sensitive crashes of mobile apps using crowdsourced monitoring

“…This paper focuses on bugs that manifest with crashes. Kechagia et al [22] identify causes of Android app crashes within a dataset of stack traces collected from real devices. In addition, Liang et al [24] identify contextrelated bugs in mobile apps, i.e., network conditions, device heterogeneity and sensor input.…”