23-09-2016, 03:13 PM
1455895328-CSE07.doc (Size: 398 KB / Downloads: 6)
Abstract—Smartphone applications’ energy efficiency is vital, but many Android applications suffer from serious energy inefficiency problems. Locating these problems is labor-intensive and automated diagnosis is highly desirable. However, a key challenge is the lack of a decidable criterion that facilitates automated judgment of such energy problems. Our work aims to address this challenge. We conducted an in-depth study of 173 open-source and 229 commercial Android applications, and observed two common causes of energy problems: missing deactivation of sensors or wake locks, and cost-ineffective use of sensory data. With these findings, we propose an automated approach to diagnosing energy problems in Android applications. Our approach explores an application’s state space by systematically executing the application using Java Path Finder (JPF). It monitors sensor and wake lock operations to detect missing deactivation of sensors and wake locks. It also tracks the transformation and usage of sensory data and judges whether they are effectively utilized by the application using our state-sensitive data utilization metric. In this way, our approach can generate detailed reports with actionable information to assist developers in validating detected energy problems. We built our approach as a tool, GreenDroid, on top of JPF. Technically, we addressed the challenges of generating user interaction events and scheduling event handlers in extending JPF for analyzing Android applications. We evaluated GreenDroid using 13 real-world popular Android applications. GreenDroid completed energy efficiency diagnosis for these applications in a few minutes. It successfully located real energy problems in these applications, and additionally found new unreported energy problems that were later confirmed by developers.
I. INTRODUCTION
THE smart phone application market is growing rapidly. Up until July 2013, the one million Android applications on Google Play store had received more than 50 billion downloads [29]. Many of these applications leverage smart phones’ rich features to provide desirable user experiences. For example, Google Maps can navigate users when they hike in the countryside by location sensing. However, sensing operations are usually energy consumptive, and limited battery capacity always restricts such an application’s usage. As such, energy efficiency becomes a critical concern for smart phone users. Existing studies show that many Android applications are not energy efficient due to two major reasons [54]. First, the Android framework exposes hardware operation APIs (e.g., APIs for controlling screen brightness) to developers. Although these APIs provide flexibility, developers have to be responsible for using them cautiously because hard-ware misuse could easily lead to unexpectedly large energy waste [56]. Second, Android applications are mostly developed by small teams without dedicated quality assurance efforts. Their developers rarely exercise due diligence in assuring energy savings.
Locating energy problems in Android applications is difficult. After studying 66 real bug reports concerning energy problems, we found that many of these problems are intermittent and only manifest themselves at certain application states (details are given later in Section 3). Re-producing these energy problems is labor-intensive. Developers have to extensively test their applications on different devices and perform detailed energy profiling. To figure out the root causes of energy problems, they have to instrument their programs with additional code to log execution traces for diagnosis. Such a process is typically time-consuming. This may explain why some notorious energy problems have failed to be fixed in a timely fashion [15], [40], [47].
In this work, we set out to mitigate this difficulty by automating the energy problem diagnosis process. A key research challenge for automation is the lack of a decidable criterion, which allows mechanical judgment of energy inefficiency problems. As such, we started by conducting a large-scale empirical study to understand how energy problems have occurred in real-world smart phone applications. We investigated 173 open-source and 229 commercial Android applications. By examining their bug reports, commit logs, bug-fixing patches, patch reviews and release logs, we made an interesting observation: Although the root causes of energy problems can vary with different applications, many of them (over 60%) are closely related to two types of problematic coding phenomena:
Missing sensor or wake lock deactivation.
To use a smart phone sensor, an application needs to register a listener with the Android OS. The listener should be unregistered when the concerned sensor is no longer being used. Similarly, to make a phone stay awake for computation, an application has to acquire a wake lock from the An-droid OS. The acquired wake lock should also be released as soon as the computation completes. Forgetting to un-register sensor listeners or release wake locks could quickly deplete a fully charged phone battery
[5], [8].
A. Sensory data underutilization.
Smartphone sensors probe their environments and collect sensory data. These data are obtained at high energy cost and therefore should be utilized effectively by applications. Poor sensory data utilization can also result in energy waste. For example, Osmdroid, a popular navigation application, may contin-ually collect GPS data simply to render an invisible map [51]. This problem occurs occasionally at certain applica-tion states. Battery energy is thus consumed, but collected GPS data fail to produce any observable user benefits.
With these findings, we propose an approach to auto-matically diagnosing such energy problems in Android applications. Our approach explores an Android applica-tion’s state space by systematically executing the applica-tion using Java PathFinder (JPF), a widely-used model checker for Java programs [67]. It analyzes how sensory data are utilized at each explored state, as well as monitor-ing whether sensors/wake locks are properly used and unregistered/released. We have implemented this ap-proach as an 18 KLOC extension to JPF. The resulting tool is named GreenDroid. As we will show in our later evalu-ation, GreenDroid is able to analyze the utilization of loca-tion data for the aforementioned Osmdroid application over its 120K states within three minutes, and successfully locate our discussed energy problem. To realize such effi-cient and effective analysis, we need to address two re-search issues and two major technical issues as follows.
Research issues. While existing techniques can be adapted to monitor sensor and wake lock operations to detect their missing deactivation, how to effectively identi-fy energy problems arising from ineffective uses of senso-ry data is an outstanding challenge, which requires ad-dressing two research issues. First, sensory data, once re-ceived by an application, would be transformed into vari-ous forms and used by different application components. Identifying program data that depend on these sensory data typically requires instrumentation of additional code to the original programs. Manual instrumentation is undesirable because it is labor-intensive and error-prone. Second, even if a program could be carefully instrumented, there is still no well-defined metric for judging ineffective utilization of sensory data automatically. To address these research issues, we propose to monitor an application’s execution and perform dynamic data flow analysis at a byte code instruction level. This allows sensory data usage to be continuously tracked without any need for instrumenting the concerned programs. We also propose a state-sensitive metric to enable automated analysis of sensory data utilization and identify those application states whose sensory data have been underutilized.
B. Technical issues.
JPF was originally designed for ana-lyzing conventional Java programs with explicit control flows [67]. It executes the bytecode of a target Java pro-gram in its virtual machine. However, Android applica-tions are event-driven and depend greatly on user interac-tions. Their program code comprises many loosely cou-pled event handlers, among which no explicit control flow is specified. At runtime, these event handlers are called by the Android framework, which builds on hundreds of native library classes. As such, applying JPF to analyze Android applications requires: (1) generating valid user interaction events, and (2) correctly scheduling event han-dlers. To address the first technical issue, we propose to analyze an Android application’s GUI layout configura-tion files, and systematically enumerate all possible user interaction event sequences with a bounded length at runtime. We show that such a bounded length does not impair the effectiveness of our analysis, but instead helps quickly explore different application states and identify energy problems. To address the second technical issue, we present an application execution model derived from Android specifications. This model captures application-generic temporal rules that specify calling relationships between event handlers. With this model, we are able to ensure an Android application to be exercised with correct control flows, rather than being randomly scheduled on its event handlers. As we will show in our later evaluation, the latter brings almost no benefit to the identification of energy problems in Android applications.
In summary, we make the following contributions in this article:
Android applications. This study identifies two major types of coding phenomena that commonly cause ener-gy problems. We make our empirical study data public for research purposes