GreenDroid: Automated Diagnosis of Energy Inefficiency for Smartphone Applications android project free download
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 PathFinder (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.
EXISTING SYSTEM:
* Existing studies show that many Android applications are not energy efficient due to two major reasons.
* 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 hardware misuse could easily lead to unexpectedly large energy waste.
* Second, Android applications are mostly developed by small teams without dedicated quality assurance efforts. Their developers rarely exercise due diligence in assuring energy savings.
DISADVANTAGES OF EXISTING SYSTEM:
] Sensing operations are usually energy consumptive, and limited battery capacity always restricts such an application’s usage.
] Hardware misuse could easily lead to unexpectedly large energy waste.
] Locating energy problems in Android applications is difficult.
PROPOSED SYSTEM:
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 smartphone 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. They are Missing sensor or wake lock deactivation and Sensory data underutilization.
ADVANTAGES OF PROPOSED SYSTEM:
ü Release wake locks could quickly deplete a fully charged phone battery.
ü We will show in our later evaluation, GreenDroid is able to analyze the utilization of location data for the aforementioned Osmdroid application over its 120K states within three minutes.
MODULES
1. Application Execution and State Exploration
2. Missing Sensor or Wake Lock Deactivation
3. Sensory Data Utilization Analysis
a. Preparing and tainting sensory data
b. Propagating taint marks
c. Analyzing sensory data utilization
MODULES DESCRIPTION:
Application Execution and State Exploration
Android applications are mostly designed to interact with smartphone users. Their executions are often triggered by user interaction events. Typically, an Android application starts with its main activity, and ends after all its components are destroyed. During its execution, the application keeps handling received user interaction events and sys-tem events (e.g., broadcasted events) by calling their handlers according to Android specifications. Each call to an event handler may change the application’s state by modifying its components’ local or global program data. As such, in order to execute an application and explore its state space in JPF, we need to: (1) generate user interaction events, and (2) guide JPF to schedule corresponding event handlers.
Missing Sensor or Wake Lock Deactivation
We next discuss how to detect energy problems when exploring an application’s state space. As mentioned earlier, missing sensor or wake lock deactivation is one common cause of energy problems. This shares some similarity with traditional resource leak problems, where a program fails to release its acquired system resources (e.g., memory blocks, file handles, etc.) Resource leak problems can cause system performance degradation (e.g., slower re-sponse), and similarly missing deactivation of sensors or wake locks can also waste valuable battery energy. Besides, according to Android process management policy, senors and wake locks are not automatically deactivated even when the application components that activated them are destroyed (e.g., onDestroy() handler is called). We will give an example and details. Based on the preceding state exploration efforts, we can now adapt existing resource leak detection techniques to detect missing sensor or wake lock deactivation.
Sensory Data Utilization Analysis
During an Android application’s execution, its collected sensory data are transformed into different forms and consumed by different application components. We need to track these data usages for energy efficiency analysis. We do it at the bytecode instruction level by dynamic tainting. Our technique contains three phases: (1) tainting each collected sensory datum with a unique mark; (2) propagating taint marks as the application executes; (3) analyzing sensory data utilization at different application states. We elaborate on the three phases in the following.
a.) Preparing and tainting sensory data
In the first phase, we generate mock sensory data from an existing sensory data pool, which is controlled with different precision levels. They are then fed to the application under analysis after each event handler call. The object reference to each sensory datum is initialized with a unique taint mark before the datum is fed to the applica-tion. The taint mark will be propagated with the datum together for later analysis.
b.) Propagating taint marks
At runtime, an Android application’s collected sensory data are transformed into different forms by assignment, arithmetic, relational, and logical operations. For example, the Osmdroid application in has its loc object (Line 38) transformed to another formattedLoc object (Line 39), which further affects the intent object (Line 42). Later, by message communication, this intent object is propagated to a broadcast receiver and converted back to the loc object (Line 9), which may or may not affect database con-tent, depending on the variable tracking ModeOn’s value (Line 11). Such data flows need to be tracked to propagate taint marks so as to identify which program data dependon the collected sensory data. Based on this information, one is then able to analyze sensory data utilization .
c.)Analyzing sensory data utilization
With program data tainted with marks associated with sensory data, we can analyze how sensory data are used in an Android application and whether the uses are effective with respect to energy cost.
SYSTEM REQUIREMENTS:
HARDWARE REQUIREMENTS:
Ø System : Pentium IV 2.4 GHz.
Ø Hard Disk : 40 GB.
Ø Floppy Drive : 1.44 Mb.
Ø Monitor : 15 VGA Colour.
Ø Mouse : Logitech.
Ø Ram : 512 Mb.
Ø MOBILE : ANDROID
SOFTWARE REQUIREMENTS:
Ø Operating system : Windows XP/7.
Ø Coding Language : Java 1.7
Ø Tool Kit : Android 2.3 ABOVE
Ø IDE : Eclipse
VIDEO OUTPUT :
thank you for your comment
pls call me on 8125424511