PaperlayerView exact revision on arXiv

Source-linked AI summary

Large-Scale Analysis of Framework-Specific Exceptions in Android Apps

Lingling Fan, Ting Su, Sen Chen, Guozhu Meng, Yang Liu, Lihua Xu, Geguang Pu, Zhendong Su

arXiv:1801.07009v3cs.SE

TL;DR

The paper addresses the lack of large-scale analysis of real-world Android crashes and the difficulty of obtaining data and validating root causes. It analyzes framework exceptions, evaluates detection tools and fixes, and finds that static analysis detects few instances while dynamic testing remains limited for some fault categories.

  • Problem

    Large-scale analyses of real-world Android crashes and their root causes were lacking, while crash analysis requires comprehensive data and validation.

    Source: §1 · pp. 1–2

  • Method

    The authors collected exception traces, investigated framework exceptions, evaluated bug-detection tools, and reviewed fixes.

    Source: §6 · p. 10

  • Results

    Static analysis tools gave correct warnings for only 4 of 77 exception instances, while dynamic testing remained ineffective for certain fault categories.

    Source: §1 · p. 2

  • Takeaways & Limitations

    The findings point to improved detection strategies and tools for reproducing exceptions, locating root causes, and checking API compatibility.

    Source: §4.5 · p. 9

    After finding that most investigated NullPointerExceptions were triggered by null object references, the authors did not analyze them further.

    Source: §4.2 · p. 5

Abstract

from arXiv · show

Mobile apps have become ubiquitous. For app developers, it is a key priority to ensure their apps' correctness and reliability. However, many apps still suffer from occasional to frequent crashes, weakening their competitive edge. Large-scale, deep analyses of the characteristics of real-world app crashes can provide useful insights to guide developers, or help improve testing and analysis tools. However, such studies do not exist -- this paper fills this gap. Over a four-month long effort, we have collected 16,245 unique exception traces from 2,486 open-source Android apps, and observed that framework-specific exceptions account for the majority of these crashes. We then extensively investigated the 8,243 framework-specific exceptions (which took six person-months): (1) identifying their characteristics (e.g., manifestation locations, common fault categories), (2) evaluating their manifestation via state-of-the-art bug detection techniques, and (3) reviewing their fixes. Besides the insights they provide, these findings motivate and enable follow-up research on mobile apps, such as bug detection, fault localization and patch generation. In addition, to demonstrate the utility of our findings, we have optimized Stoat, a dynamic testing tool, and implemented ExLocator, an exception localization tool, for Android apps. Stoat is able to quickly uncover three previously-unknown, confirmed/fixed crashes in Gmail and Google+; ExLocator is capable of precisely locating the root causes of identified exceptions in real-world apps. Our substantial dataset is made publicly available to share with and benefit the community.

1 INTRODUCTION

The paper addresses the lack of large-scale analysis of real-world Android crashes and the difficulty of obtaining data and validating root causes. It studies framework exceptions, evaluates detection tools and fixes, and presents findings and prototype tools.

1 INTRODUCTION

  • Framework exceptions account for the majority of app crashes and affect over 75% of the projects studied.The study classifies exceptions by the architecture layer that threw them.Source: §1 · pp. 1–2
  • The authors collected 16,245 unique exception traces from 2,486 open-source Android apps and investigated 8,243 framework exceptions.Collection took four months; analysis took nearly six person-months.Source: §1 · p. 2
  • Framework exceptions take an average of four days to fix and have a 53% issue-closing rate, versus 67% for application exceptions.The investigation also distilled 11 common developer fault categories.Source: §1 · p. 2
  • Static analysis tools gave correct warnings for only 4 of 77 exception instances, while dynamic testing remained ineffective for some fault categories.Testing strategies substantially affect detection ability.Source: §1 · p. 2
  • Many framework exceptions can be fixed with small patches of fewer than 20 code lines, although developers still face fixing challenges.Source: §1 · p. 2
  • Stoat uncovered three previously unknown bugs in Gmail and Google+, while ExLocator precisely localized root causes in real apps.Source: §1 · p. 2

2 PRELIMINARY

Prior studies did not provide a comprehensive analysis of Android app crashes, and this paper focuses specifically on crashes caused by app violations of Android framework constraints. It also explains how exception traces encode wrapped exceptions and their root cause.

2.1 Existing Fault Study

  • Earlier functional-bug studies covered limited apps or specific goals, while prior Android crash work did not provide a comprehensive, in-depth analysis.The authors describe their study as the first in-depth investigation of Android app crashes to their knowledge.Source: §2.1 · p. 2
  • The study includes app-caused exceptions thrown from Android framework methods for constraint violations, but excludes framework bugs, application exceptions, and library exceptions.Application exceptions are left for future work; library exceptions require information that varies across apps.Source: §2.1 · p. 2

2.2 Exception Model in Android

  • In an exception trace, the root exception is at the bottom, wrappers appear above it, and the signaler is the first method call beneath the root exception declaration.RuntimeException and Error must be handled by programmers at runtime.Source: §2.2 · p. 3

3 OVERVIEW

The study uses open-source F-Droid apps, collects exception traces by mining issue repositories and running testing tools, and analyzes the traces with additional resources. Its collection combines mined reports with crashes found in automated testing.

3 OVERVIEW

  • The study selects F-Droid apps, mines issue repositories, applies testing tools, and investigates traces and other resources to answer four research questions.The resulting study supports follow-up research.Source: §3 · p. 3

3.1 App Subjects

  • F-Droid provides a large, diverse set of open-source apps with metadata and accessible source code and issue repositories.At the time of the study, it contained more than 2,104 unique apps and 4,560 versions.Source: §3.1 · p. 3

3.2 Data Collection

  • Mining 272,629 issues from 2,174 apps yielded 7,764 valid exception traces, including 6,588 unique traces.The crawler collected reports from GitHub and Google Code.Source: §3.2 · p. 3
  • Automated testing found 9,722 unique crashes across 4,560 app versions, complementing issue repositories that recorded only 545 unique crashes for those versions.Monkey, Sapienz, and Stoat each tested app versions for three hours on an Android emulator.Source: §3.2 · p. 3, Table 1 · p. 3

4 EMPIRICAL STUDY

This empirical study examines framework exceptions in Android apps, characterizing their manifestation modules and fault categories, detection limits, and recurring repair practices. It also discusses implications for Android bug-analysis tools and developers, related work, and study validity.

4.1 RQ1: Exception Categories

  • App Management, Database, and OS are the three most exception-prone modules; common examples include ActivityNotFound and receiver-registration errors in App Management.Database exceptions are mostly SQLite-related; OS exceptions commonly include SecurityException, IllegalArgument, and NullPointer. Other module-specific problems include improper ListView/Adapter use, Bitmap handling, Fragment callbacks, and dialog display.Source: §4.1 · pp. 4–5

4.2 RQ2: Taxonomy of Framework Exceptions

  • Analysis of 86 exception types, covering 84.6% of all framework exceptions, distilled 11 fault categories; developers made more mistakes on Lifecycle, Memory/Hardware, and Android Framework Constraint errors.Source: §4.2 · pp. 5, 7
  • Framework faults arise from lifecycle mismanagement, thread misuse, violated framework constraints, and database errors, among other causes.Examples include failing to check component state after background work, updating UI-bound data off the UI thread, omitting a required message loop, and failing to create a database table during an upgrade.Source: §4.2 · pp. 5–6
  • Existing mutation operators covered only 2 of 75 sampled exception instances for Deng et al.’s operators and 8 for MDroid+, indicating limited coverage of these faults.The top 200 of 2,016 exception buckets account for over 80% of exceptions; the remaining buckets each contain five or fewer exceptions.Source: §4.2 · pp. 5, 7

4.3 RQ3: Auditing Bug Detection Tools

  • Only 4 of 75 sampled bugs were detected by Lint, while FindBugs, PMD, and SonarQube detected none; dynamic tools also struggle with database, framework-constraint, and concurrency errors.Concurrency errors take longer to detect and are hard to trigger because of timing non-determinism; database and framework-constraint errors may require specific states or environment interactions.Source: §4.3 · pp. 7–8

4.4 RQ4: Fixing Patterns and Efforts

  • Four common fix patterns—refining checks, moving code to the correct thread, working in the right callbacks, and adjusting implementations—resolve over 80% of issues.Implementation adjustments include resizing bitmaps to reduce memory use and using locks or backing up shared data to address races.Source: §4.4 · pp. 8–9
  • Parameter, indexing, resource, and database fixes usually require fewer than 20 changed lines, while UI, concurrency, and memory/hardware fixes require larger patches.The smaller fixes commonly refine conditional checks.Source: §4.4 · p. 9
  • Reproducing and validating fixes is difficult when reports lack steps or inputs, and concurrency errors are especially hard to reproduce; developers also face challenges understanding Android system behavior.Concurrency errors have longer issue durations and lower fixing rates.Source: §4.4 · p. 9
  • Developers sometimes use fragile workarounds for UI errors, while fast-changing APIs and features can leave apps fragile across platforms and delay fixes.Android averages 115 API updates per month; some developers delayed fixing runtime-permission issues because they did not fully understand the feature.Source: §4.4 · p. 9
  • Four common fixes are refining conditional checks, using correct thread types, working in the right callbacks, and adjusting implementation choices.Memory/Hardware, Lifecycle, Concurrency, and UI update errors are more difficult to fix.Source: §4.4 · p. 9

4.5 Discussion

  • The study finds Lifecycle, Memory/Hardware, Concurrency, and UI update errors especially effort-intensive, and recommends stronger detection, testing, and debugging support.Static analysis could add rules for UI update, Lifecycle, and Framework Constraint errors; testing tools could add targeted strategies, while other tools could reproduce exceptions, locate root causes, and check SDK API compatibility.Source: §4.5 · p. 9
  • The authors distinguish their comprehensive framework-exception analysis from Linares-Vásquez et al.’s mutation-operator work [52], whose 38 operators cover 8 of their 75 instances.They suggest their results could further improve existing mutation operators.Source: §4.5 · p. 9

5 APPLICATIONS OF OUR STUDY

The study’s dataset supports tool comparison, fault-localization benchmarks, and patch-generation research, while its findings also motivate stronger detection methods. Prototype tools demonstrate exception detection and localization on real-world apps.

5.1 Benchmarking Android App Exceptions

  • The dataset contains 16,245 app exceptions and 8,243 framework exceptions, with buggy code, traces, fault categories, and possible fixes.The authors propose it as a basis for comparing analysis tools, fault-localization benchmarks, and patch-generation research.Source: §5.1 · p. 10

5.2 Improving Exception Detection

  • Testing can target parameter errors with formatted inputs and lifecycle, concurrency, and UI-update errors with interleaved environment actions; static analysis can add checks for framework constraints, lifecycle, and UI updates.The study also recommends testing across app and SDK versions and using more advanced testing criteria.Source: §5.2 · p. 10
  • Stoat uncovered three previously unknown, confirmed bugs in Gmail and Google+ that Monkey and Sapienz had not found.The bugs involved parameter, UI-update, and lifecycle errors.Source: §5.2 · p. 10

5.3 Enabling Exception Localization

  • ExLocator correctly located 25 of 27 randomly selected exceptions, and Android framework context helped identify the remaining two root causes.The tool reports likely causes and possible fixes; it supports five exception types.Source: §5.3 · p. 10

6 CONCLUSION

The paper analyzes Android framework exceptions at scale, characterizes them, evaluates bug-detection tools, and reviews fixes. It reports a dataset and prototype tools as outputs of the study.

6 CONCLUSION

  • The study investigates 8,243 framework exceptions from a dataset of 16,245 unique exception traces.It characterizes exceptions, evaluates their manifestation with bug-detection tools, and reviews their fixes.Source: §6 · p. 10
  • The analysis identifies exception characteristics and motivates follow-up research.The paper demonstrates the findings’ utility with two prototype tools.Source: §6 · p. 10
Loading 1801.07009v3…