A Method for Characterizing Energy Consumption in Android ...

A Method for Characterizing Energy Consumption in Android Smartphones Luis Corral, Anton B. Georgiev, Alberto Sillitti, Giancarlo Succi

Center for Applied Software Engineering Free University of Bozen/Bolzano Bolzano, Italy {Luis.Corral, Anton.Georgiev}@stud-inf.unibz.it, {Alberto.Sillitti, Giancarlo.Succi}@unibz.it Optimizing power consumption has been investigated at different levels, e.g., system, circuit architectures, processors, memories, displays, wireless subsystems, and software [1], establishing at different scopes the question of how can we optimize the consumption of energy resources with the purpose of extending the battery life. Nonetheless, to be able to optimize the power consumption, first we have to measure it accurately. To this end, a core requirement is a good understanding of where and how the energy is used [2] to know precisely how the resources are utilized and discover improvement needs. The optimization of energy for mobile devices may potentially benefit an increasing number of users and platforms in the mainstream: cellular phones are ubiquitous, with a market penetration of millions of active users and sold units. In addition, the increasing computing capabilities and strict autonomy requirements pose a particular concern on energy economization for these product families. In this paper, we investigate an approach to relate the energy consumption of smartphones with the operational status of the device, using parameters exposed by the operating system. We describe its implementation in the form of an Android app, and we explain the data collection strategy, mentioning the advantages and limitations of performing the analysis at software application level. Moreover, we present the results of an experiment in which we used this application to identify the resources that primarily drain the battery on the tested units. Our goal is to contribute to have more reliable measurements that can be used in further research for designing energy optimization profiles. The rest of the paper is organized as follows: Section II introduces power management in operating systems and the power management strategy of Android OS; Section III discusses approaches to measure the energy consumption on mobile devices; Section IV shows a software-based strategy for characterizing the energy consumption with the status of the system based on the CharM application; Section V describes our experimental setup and discusses our results; finally Section VI gives direction for future research, provides a summary and draws conclusions on the present work

Abstract—Cellular phones and tablets are ubiquitous, with a market penetration that is counted in millions of active users and units sold. The increasing computing capabilities and strict autonomy requirements on mobile devices drive a particular concern on energy utilization and optimization of this kind of equipment. In this paper, we investigate an approach to relate the energy consumption of smartphones with the operational status of the device, surveying parameters exposed by the operating system using an Android application. Our goal is to explore the means to expand the information that may help to produce more reliable measurements that can be used in further research for designing energy optimization profiles for mobile devices and identify optimization needs. Index Terms—Android, Applications, Measurement, Power, Smartphone.

Energy,

Mobile,

I. INTRODUCTION In times when energy prices are rising, the disposal of battery garbage is an issue, and the autonomy of devices is a growing requirement, the power consumption of mobile equipment becomes a major concern. Few years ago, energy utilization was a minor problem due to the small demand of power of simple handheld telephones, but with the evolution of their capabilities, the need of power climbed to a level that limited sources cannot always keep up. For instance, a modern smartphone features a conventional cellular radio antenna along with a collection of sensors and services like WiFi, GPS, camera, large screen and many others, each one taking their toll on the battery resources. Cellular phones are normally used carried by their owners, most of the time away from a permanent power source like an AC power outlet. In this way, the normal use of these devices implies a constant energy demand that will invest the battery reserves until they finally exhaust. Users would like a wiser utilization of the energy that allows their phones to be more and more autonomous; however this may imply using expensive, state-of-the-art batteries that last longer, or configuring energy profiles that maximize the profit from a limited power source at the cost of having less features or lower performance.

c 2013 IEEE 978-1-4673-6267-2/13

38

GREENS 2013, San Francisco, CA, USA

c 2013 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media, including reprinting/ Accepted for publication by IEEE. republishing this material for advertising or promotional purposes, creating new collective works, for resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in other works.

II. MOBILE POWER MANAGEMENT In a computer ecosystem, power supply is required to operate hardware components; nevertheless, such operation is usually driven by requests made by software: for instance, a process that requires the CPU or needs to read from the memory, a notification that needs to ring a bell, or an application that requests to render an image in the display. Therefore, it is necessary to count on power management policies to orchestrate how different hardware units use a single energy source. The close interaction between software and hardware places power management at Operating System (OS) level. Power management tools at OS level include modules, instructions and conditions that comprise the system’s energy consumption policies. Typical power management techniques include shutting off components not being used, launching economy operation modes, triggering system hibernation, and many others [3]. In environments powered by limited sources, a power management program helps to optimize the energy utilization, since an eventual lack of power would impose serious performance limitations or would simply prevent the operation of the gadget. This situation affects users at different extents, but in particular it impacts the enormous spectrum of users of portable devices like cellular phones and tablets1, due to their ubiquity, increasing computing capabilities, and strict autonomy requirements. Typically, a mobile phone spends a large amount of time in a state where it is not actively used. This means that the screen is off, the processor is idle, and the processor performs with a low level of activity, sufficient to maintain the network connection necessary to receive a call or to ring a bell [4]. Thus, mobile phones are managed by operating systems that are aware of this environment and deploy efficient power management strategies that reduce the consumption during the idle time, and aim to optimize the power demand through aggressive power saving policies. In this tradeoff, power is saved at the expense of latency and performance [5, 6]. Different mobile operative systems implement diverse power management strategies. To have a better understanding of them, we selected Google’s Android OS: as an open source platform, it allows to analyze its structure and internal organization, facilitating a richer analysis and offering better development possibilities. In addition, this platform implies a major impact thanks to a constantly increasing number of target devices, software applications and end users [7, 8]. The Android Operating System is organized in different layers to place the services and applications according to specific requirements and necessities. It is based upon a customized version of the Linux kernel, which acts as the abstraction layer between the hardware and the software; the Linux kernel contains the core services such as security, memory stack, processes, memory, etc. On top of the kernel there is a set of Open Source C/C++ libraries optimized for handling mobile devices and their associated constraints.

Fig. 1. Power Management Localization in the Android OS Stack

Above these layers resides the Android application framework, a collection of Java libraries used for developing and interacting end-user applications and to handle them. Finally, in the topmost level, the end-user applications are set.2 The Android OS power manager facility is distributed throughout the different levels of the stack to guarantee an integral operation between the applications at user space, the application framework, and kernel’s hardware drivers (Figure 1). At kernel level, the Android power manager library has been designed inspired on the standard Linux power management library (APM), but customized with the premise that the processor should not consume any energy if there is not at least one application or service demanding it3. At application level, Android builds upon the kernel’s power management library using libraries and parameters that are exposed to the regular applications to gain control of the device’s power state. Android implements a power management methodology that relies on the principle that applications and services must request power resources using software parameters (called “wake locks”) which are values that the application sets to request and keep computing resources4. In this fashion, when there are no active wake locks, Android shuts down the CPU and other battery-hungry peripherals to save energy when there is no reason to keep such components active [9]. If an application needs to gain control of the power state, Android OS exposes it through a Java class from the application framework (PowerManagement) that permit to create a manager object that manipulates the power state by setting the wake locks values. This class interfaces with lower levels of the OS stack to control the power state (Figure 2), and is able to shut down the system when the unit is out of battery. Using this power management policy, Android allows the kernel to avoid races: wake locks are activated whenever wakeup events occur, which prevents the kernel from suspending the system, and also provides a direct standard for the kernel to decide when opportunistic suspension should be started, this is, the kernel should attempt to suspend the system only whenever there are no active wake locks [10]. 2

http://developer.android.com/about/versions/index.html http://www.kandroid.org/online-pdk/guide/power_management.html 4 http://developer.android.com/reference/android/os/PowerManager.html 3

1

http://www.idc.com/getdoc.jsp?containerId=prUS22917111

39

Thus, we can see that the voltage must be taken into account as a significant variable when calculating the energy consumption. This opens two ways to proceed with the acquisition of a reliable reading: the first one is to attach the mobile device to a power supply unit with the capability of delivering a constant voltage; the second option is to read the voltage itself, using an appropriate physical instrument. Nonetheless, this can be simplified utilizing the internal voltage sensor, available in most modern smartphones. To obtain the value of this sensor, an Android application at user space can be implemented. Table II illustrates the readings for different states for the same HTC HD2 smartphone, using the internal voltage sensor. TABLE II. Description Airplane mode WiFi on Bluetooth on GPS on WiFi transfer Google maps

Fig. 2. Application to Kernel Power Management Call

III. MEASURING ENERGY CONSUMPTION OF A MOBILE DEVICE The most basic approach to quantify the energy consumption of any electronic equipment is to measure the electric current physically using a digital multimeter or other similar instruments. Several works relied on this approach to conduct their analysis [2, 11, 12, 13]. The power consumption is calculated with the product of the current times the voltage. In case of a cellular phone, this operation requires to connect the measurement instrument in series between a terminal of the battery and the corresponding contact on the cell phone. Other contacts must be wired in a way as if the battery was attached to the cellphone. By turning the device on, we obtain a reading for the electric current that travels through the wire and into the device. However, to calculate the energy consumption, we still need a reading for the voltage, and voltage in Li-Ion batteries is not constant during the time that the equipment is in use. Table I shows this behavior, using as example a HTC HD2 smartphone. We can appreciate a steady decrease of voltage over the course of the discharge; although the slight variations in the temperature during the course of the experiment may have applied some impact on the readings, the voltage decrease is not trivial and hence not negligible. TABLE I. 100% 90% 80% 70% 60% 50% 40% 30% 20% 10%

Charge

Voltage (mV) 3840 mV 3813 mV 3822 mV 3814 mV 3824 mV 3726 mV

Current (mA) 0.097 mA 0.126 mA 0.111 mA 0.106 mA 0.213 mA 0.279 mA

Power (mW) 374 mW 482 mW 426 mW 408 mW 817 mW 1042 mW

Table II shows that the energy consumption is lowest when the device is set into Airplane Mode. The energy consumption rises by a certain amount as different services are activated. A dramatic increase in energy consumption can be observed once the smartphone actually starts transmitting data over the WiFi antenna. The value climbs almost three times if we run an application such as Google Maps, which uses GPS and WiFi simultaneously, while rendering images dynamically. Although physical measurement certainly provides us with the most accurate readings, its feasibility of application at large scale can be challenged since it requires special equipment and technical knowledge. Alternatively, software-based analysis is a method that makes use of data collected from the different software system interfaces to perform calculations to assess the energy consumption at software application level. At this scope, it is possible to implement profiling techniques instrumenting the source code, which permits a very detailed analysis about what are the routines and system calls that have a major contribution to the dissipation of energy [14]. Another kind of applications implements energy models: this strategy utilizes a model developed by physical measurements, then processed and interpreted using a software application [15, 16, 17]. To create the model, it is required to hold the unit under test in high-power state for each hardware component being measured, while keeping all others in a lowpower state. In this way, the readings for the battery discharge curve describe how every single element influence the exhaustion of the battery. In this case, the energy model has a higher level of confidence when approximating the energy consumption on the product families after which it was created; for all other product lines these readings can only be considered as estimations, and might deviate significantly from the actual values.

VOLTAGE CHARACTERISTICS OF LI-ION BATTERY Voltage (mV) 4107 mV 3970 mV 3907 mV 3906 mV 3853 mV 3800 mV 3775 mV 3761 mV 3732 mV 3641 mV

ENERGY CONSUMPTION FOR DIFFERENT SYSTEM STATES

Temperature (°C) 29°C 28°C 29°C 25°C 26°C 27°C 26°C 25°C 25°C 27°C

40

more factors that have a significant impact on the discharge cycle are identified and aggregated to the data collection plan. To implement the CharM application, several factors were considered. First, it is critical to decide how can we guarantee that the application is run repeatedly in the time interval specified, without being terminated by the system or interfering with the user blocking the user interface. To solve this, Android provides a system service called AlarmManager, which permits that certain application intent is run repeatedly until it is cancelled. In this manner, the alarm stays active even when the application that initially spawned it gets removed from main memory by the OS. Second, we had to ensure that collecting the statuses will not block the user interface and will not be interrupted by the system. To prevent the method from blocking the user interface, we spawned a new thread that will run the code responsible for carrying out the data collection. In parallel, to ensure that the survey is run in a contiguous transaction, we need to acquire from the system a wake lock to guarantee that the CPU will not be set into an idle state. Finally, it was of critical importance to implement a lightweight application, in a way that execution of the app represents only a negligible footprint in the overall system performance and minimum power consumption.

Up to now, software-based techniques mainly focus on measuring the battery discharge cycle. However, knowing the battery level says little for understanding how the energy is used. Our work pursues to expand this insight with a software solution that delivers a reliable notion of how the energy is invested based on sampling the status of the system at real time. Furthermore, the implementation must be done in a fashion that can be generalized for different product families. IV. SURVEYING THE DISCHARGE CYCLE The main problem with the discussed software-based approaches is that even though we can obtain the voltage from the device’s internal sensor, there is no way of acquiring a sample for the electric current, except for measuring it with hardware. In consequence, there is no a direct, software-based way to calculate the power. With this condition in mind, we aimed to design a solution to characterize the energy consumption based on the time that the battery lasts, complementing it with a comprehensive survey of the status of the active components in the system to create a relationship between the consumption with the current status of the device. A. Discharge Measurement App (CharM) To analyze the system and characterize the discharge cycle, we placed our solution as means of a regular mobile application at user space. We developed CharM, an Android app that records the battery level and additionally collects specific data from the OS to survey the components deem to have an impact on the discharge curve of the battery. The following data is recorded in fixed intervals of one minute.  Timestamp: A UNIX timestamp to associate the reading with a time.  Battery level: The current charge level of the battery in percent relative to a full charge.  Processor load: The current load of the processor in percent, i.e. the time the processor has actually been working versus the total time.  Processor frequency: The current CPU frequency, as the system adjusts the frequency dynamically.  Memory usage: A value which indicates what share of the total available RAM is in use.  Airplane mode: A logical value which indicates if the phone is connected to a mobile network  Display active: A value that shows whether the screen is currently on, as well as the brightness intensity.  WiFi enabled: A logical value that indicates whether the WiFi service is enabled.  Bluetooth enabled: A logical value that specifies whether the Bluetooth service is enabled.  GPS enabled: A logical value which indicates whether the GPS location service is enabled.  Amount of bytes transmitted and received: Indicates the amount of data in bytes that has been sent and received on the wireless interface. This list is by no means complete and represents a baseline for our experimental purposes. The list can be extended as

B. Data Sources The next step on the application design is to establish the way in which the data should be collected. In the Android OS there are two main sources for important data for measuring energy consumption. First, the Android SDK exposes the current battery level or the status of various components like the screen or the different wireless interfaces, which delivers relevant data for the analysis of power consumption. The second source for information is the Linux kernel. As a UNIXlike OS, the kernel provides us with the virtual proc-filesystem which is mounted at the directory /proc directly under the root directory. This directory contains files with assorted information about the current status of the system. For instance, the file /proc/stat contains information about the CPU usage and the file /proc/meminfo about the allocation of main memory. We choose to survey the system at this level, allowing the OS to work as an intermediate level of abstraction that permits a less hardware-dependent analysis, be reliable on diverse product families of cellular phones (Figure 3).

Fig. 3. Android Application Architecture

41

To explain how these files can be utilized and how the measurements can be interpreted from them, we present a separate analysis for each one:

and this implies the constant use of the WiFi antenna or 3G services, that are themselves energy-hungry and may bias the values seriously.

Processor usage information The data related to processor usage can be read from the file /proc/stat. This file contains one or more rows, depending on the number of processors that the system has. The values in each row indicate the time each core has been working or idle since the launch of the system. To get a value for CPU usage, we calculate the ratio between time that the processor has been active, and the time the processor has been idle.

Writing to a file on the SD card To overcome these shortcomings, we contemplate a way in which the data can be surveyed and stored minimizing the energy consumption associated to the data collection effort. With this implementation, the measurements are written and appended to a file located on the removable SD card using the CSV format, to store the readings in a tabular, plain-text way. While this technique is the most suitable for our needs, a disadvantage is that it does not allow real time analysis: the data need to be collected first, stored in the SD card, and transferred to a computer at the end of the experiment in order to execute further analysis.

Current processor frequency In a different way, the current processor frequency cannot be found in the directory /proc but rather from the file /sys/devices/system/cpu/cpu0/cpufreq/scaling_cpu_freq, which contains a value for the current frequency in kilohertz (kHz).

V. EXPERIMENTAL SETUP CharM was deployed in three Android-operated devices to collect measurements on different product families with diverse versions of this OS:  HTC Nexus One cell phone, with Android 2.3.7, powered by a Li-Ion 1400 milliampere-hour (mAh) battery.  Samsung Galaxy cell phone, with Android 4.0.4, powered by a Li-Ion 1750 mAh battery.  Nexus 7 tablet, operated by Android 4.2.1, powered by a Li-Ion 4325 mAh battery.

Memory allocation data The data for memory allocation information can be read from /proc/meminfo. This file contains several lines, where each line contains a name and a value in kilobytes. The lines, we are interested in are prefixed with MemTotal and MemFree. From these two values, we can easily calculate the percentage of total memory which is currently in use. Data on wireless interface use The file /proc/net/dev contains a row for each network interface. It contains the number of bytes that have been sent and received by every interface since the system was started.

A. Data Collection Plan There have been extensive research that shows that data collection and visualization is of critical importance when conducting an empirical study [19-23]. We established a solid data collection effort divided in three stages: In a first phase of our experimentation, we installed CharM in the listed devices. We asked the users to recharge them to the full battery capacity, and to utilize the cellular phone normally in the time frame of 2 hours. CharM surveyed the status of the system every minute. This survey permitted to create an operational baseline that illustrates the relationship of the discharge cycle of the cellular phone with the system’s resources utilized in normal, day-to-day conditions: occasional use of cellular radio and 3G connection, intermittent WiFi usage, and regular use of some of the mobile applications. In the second stage, users were asked to recharge their devices to the full battery capacity and to utilize them in Airplane Mode (i.e., disabling all communication interfaces) in the time frame of 2 hours. CharM surveyed the status of the system every minute. Through this practice, we created a baseline for the discharge cycle of the cellular phone resources in strict economy mode. Finally, in a third phase of the exercise, the devices were as well recharged to the full battery capacity, and the status of each phone was surveyed by CharM every minute for 2 hours. In this stage, we exercised a series of software routines that specifically stress a component to observe the relation between the system’s energy consumption with the power toll of such element in conditions of high demand (Table III).

OLED screen and backlight status To survey the screen, we can acquire the on/off status out from the PowerManagement class, while the value set for the backlight brightness can be taken from an integer value stored in the file /sys/devices/virtual/leds/lcd-backlight/brightness. C. Data Storage Once the data sources have been identified, it is necessary to define how the collected data should be organized and aggregated for further analysis. We analyzed three strategies: Writing to the system log Writing into system log [18] automatically makes the data available to any class in an Android application. The system log is also available to any computer terminal connecting the device via USB using the Android debug bridge. The data can be analyzed in real time by filtering the desired data from the log. However, this method is not suitable for our purpose: the readings are affected since the battery is automatically charged when the phone is connected to a computer through USB. Sending the data to a web service Another solution involves sending the data to a REST web service. With this approach, the data can be read and sent to a web service in real time, alleviating the need of having the device connected to a computer via a USB. Nonetheless, this approach was dismissed since it requires internet connection,

42

TABLE III.

ENERGY CONSUMPTION STRESSING ROUTINES

Component CPU OLED screen Multimedia playback WiFi interface GPS interface

Routine High-load, maximum frequency CPU stress Maximum screen brightness Continuous video playing Systematic WiFi transmission Systematic GPS polling

To isolate effectively the power demand of each surveyed element, when a component was stressed we disabled all others (e.g., deactivating the WiFi or GPS interfaces, or turning off the screen). When a component could not be disabled (e.g., CPU), we minimized its utilization (e.g., by executing only the stressing routine and CharM under minimum CPU frequency). To ensure repeatability of our experimentation, we run every test ten times on each cellphone observing consistent results, yet they were kept for reference and are not reported in this paper. Reproducibility is guaranteed since the three test beds belong to different product families. In total, we achieved more than 500 hours of tests, with no major discrepancies observed among similar scenarios.

Fig. 5. Battery discharge for HTC Nexus One on Airplane Mode

Starting with our stress tests, Figure 6 illustrates the discharge curve (solid line) after running a routine that exercises the CPU at the highest load on the maximum frequency. The x axis represents the time in minutes, the left y axis the percentage of the battery charge, and the right y axis the CPU frequency reported by CharM. The dashed line depicts the frequency under the stress scenario, while the dotted line under normal use. This mode consumed 40% of the battery in 2 hours.

B. Data Interpretation Due to lack of space it is not possible to show the plots for each exercise. To simplify the data analysis and interpretation, we illustrate our results with the data plots that correspond to the values of one test session using the HTC Nexus One, while we report the other two instances in Table IV. Figure 4 shows the results of executing CharM in the HTC Nexus One in a time frame of 2 hours of regular utilization. The x axis represents the time in minutes, while the y axis the percentage of the battery charge. The curve of the battery discharge shows a consistent trend, occasionally steeper when CharM data sources reported an increase in the CPU load (minutes 37 to 42). Also, the battery discharged slightly faster when it is reported a higher load in the data transmission using the WiFi interface (minutes 61 to 71). In this mode, 2 hours consumed about 10% of the phone’s battery.

Fig. 6. Battery discharge for HTC Nexus One under CPU stress test

Figure 7 displays the discharge curve (solid line) after executing a routine that sets the OLED display at maximum brightness, keeping it on. The x axis represents the time in minutes, the left y axis the percentage of the battery charge, and the right y axis the OLED brightness level surveyed by CharM. The dashed line shows the brightness under the stress scenario, while the dotted line the brightness under normal use. In this mode, the battery was drained in 35% in 2 hours.

Fig. 4. Battery discharge for HTC Nexus One under regular use

As per the second stage of our experiment, Figure 5 shows the results of conducting the execution of CharM in a time frame of 2 hours of utilization in Airplane Mode. The x axis represents the time in minutes, and the y axis the percentage of the battery charge. The discharge curve is consistent, since no major variations were exercised. This mode saves battery consumption significantly, reducing it to only 2% in 2 hours.

Fig. 7. Battery discharge for HTC Nexus One under OLED display stress test

Figure 8 shows the percentage of the battery charge (solid line) of the device and the amount of memory allocated while playing continuously a MPEG video. The x axis represents the time in minutes, the left y axis the percentage of the battery

43

charge, and the right y axis the percentage of memory allocated described by CharM. The dashed line represents the memory allocated under this scenario, while the dotted line represents the memory allocated under normal use. With this scenario, 2 hours of experimentation consumed 12% of the battery level.

In Table IV we show a summary that includes the results obtained from executing the test scenarios in the three devices. It is important to note that these percentages do not represent an absolute number, but a proportional value with respect to the general battery discharge cycle. The capacity of the battery and the power demand of the features may inject variations among product families. However, all results are consistent, although we can appreciate that as the device’s model evolves, enhancements on power management policies, hardware components and the capacity of the battery delivered noticeable savings on the overall system’s power consumption. TABLE IV.

Fig. 8. Battery discharge for HTC Nexus One under media playback stress

Figure 9 shows the discharge curve (solid line) after exercising a routine that continuously sends and retrieves data from the wireless network. The x axis represents the time in minutes, the left y axis the percentage of the battery charge, and the right y axis the number of bytes received, as noted by CharM. The dashed line represents the number of bytes received under the stress scenario, while the dotted line under normal use. In this mode, it took 2 hours to drain 24% of the battery.

PERCENTAGE OF BATTERY D ISCHARGE IN 2 HOURS

Execution Mode

Nexus One

Nexus 7

Normal mode Airplane mode CPU stress OLED stress Video playback stress WiFi stress GPS stress

10% 2% 40% 35% 12% 24% 17%

2% 0.2% 17% 24% 7% 22% 10%

Galaxy Nexus 4% 1% 26% 20% 10% 32% 15%

With these results at hand, we can calculate an average of the readings to sort the components by energy consumption. Table V shows a ranking of the surveyed elements, sorted in descendent order, from the hungriest to the least power demanding features. TABLE V.

RANKING OF ENERGY HUNGRY COMPONENTS

Component 1. CPU stress 2. OLED stress 3. WiFi interface 4. GPS interface 5. Video playback 6. Normal mode 7. Airplane mode

Fig. 9. Battery discharge for HTC Nexus One under WiFi stress test

Impact to discharge cycle 27.66% 26.33% 26.00% 14.00% 9.60% 5.33% 1.06%

From Table V we can identify that three components were noted to particularly drive the battery discharge cycle after being stressed. They are the CPU, the OLED display and the WiFi interface. CharM provided data that ensure a clear view of the operational status of the system, permitting to isolate unambiguously that such components contributed the most to the system’s energy toll.

Lastly, Figure 10 illustrates the discharge curve (solid line) after executing a routine that systematically polls the GPS. The x axis represents the time in minutes, the left y axis the percentage of the battery charge, and the right y axis the GPS status reported by CharM (1 on, 0 off). The dashed line represents when the GPS was active under the stress scenario, while the dotted line represents it under normal use. This mode required 2 hours to consume 17% of the battery level.

VI. FUTURE WORK AND CONCLUDING REMARKS The information delivered by CharM opens the doors for further analysis on the energy utilization quota for each surveyed feature, useful to design economy profiles that can be manually or automatically set depending on how much energy the user is willing to spend. A primary opportunity to enhance CharM is to add features that may improve the survey of the system, including more parameters that can be taken at OS level, for example the temperature of the battery or the status of all the leds in the device. Moreover, we also foresee to improve the user experience by providing enhanced reporting features like plots, tables and customized reports.

Fig. 10. Battery discharge for HTC Nexus One under GPS stress test

44

In this work, we illustrate a technique that builds upon direct measurement and energy models to furnish a softwaredriven approach to survey of the status of the system to illustrate the impact of each relevant working components in the overall power consumption of the unit. This solution proposes an original approach since it places the survey at user space, but conducting the data collection from sources at OS level. This facilitates a less hardware-dependent analysis, eases its maintenance, and makes it reliable on diverse product families of phones and tablets operated by Android, yet easily expandable to other environments operated on top of the Linux kernel. Moreover, our approach simplifies the conduction of a comprehensive system survey by implementing it through a simple mobile application executed at user space. Measuring the battery level says little for understanding the energy consumption of a device. CharM contributes to move towards a better understanding on how the energy is invested in a mobile device, delivering a relationship between the overall system consumption toll and the active components that mainly influence it. A major motivation of this project is to assist on the identification of opportunities for the creation of Green Software solutions. Such efforts represent an important research track that requires the definition of specifications, practices and tools specifically concerning about resource consumption. With this work, we deliver a characterization tool that aids on the identification of components particularly energy consuming, helping to design execution profiles, collect relevant data for green metrics, and identify eventual optimization needs. By fostering the development of Green Software, we aim to promote the most responsible utilization of energy sources and to use software as an effective tool to contribute to the conservation of the environment.

[6] Corral, L., Sillitti, A., Succi, G., Strumpflohner, J., Vlasenko, J.; DroidSense: a mobile tool to analyze software development processes by measuring team proximity. Proceedings of TOOLS 2012, pp. 17-33. LCNS vol. 7304. 2012. [7] Butler, M.; Android: Changing the mobile landscape. Pervasive Computing, Vol. 10, No. 1, pp. 4-7. ISSN: 1536-1268. 2011. [8] Sillitti A., Janes A., Succi G., Vernazza T., Measures for Mobile Users: an Architecture. Journal of Systems Architecture, Elsevier, Vol. 50, No. 7, pp. 393 - 405, July 2004. [9] Paul, K.; Kundu, T.K.; Android on mobile devices: An energy perspective. 10th International Conference on Computer and Information Technology, pp.2421-2426. 2010. [10] Hu, S., Yu, Y., Xie, L.; Comparing power management strategies of Android and TinyOS. 3rd Pacific-Asia Conf. on Circuits, Communications and System (PACCS), pp.1-4. 2011. [11] Sagahyroon, A.; Power consumption in handheld computers. IEEE Asia Pacific Conf. on Circuits and Systems, pp.17211724. 2006. [12] Malik, Y.; Power consumption analysis of a modern smartphone. Arxiv.org. 2012. [13] Wise, J.A., Lin, W.; Precise power characterization of modern Android devices. 2010. [14] Zhang, L., Tiwana, B., Qian, Z., and Wang, Z.; Accurate online power estimation and automatic battery behavior based power model generation for smartphones. 8th Intl. Conf. on HW/SW Codesign and System Synthesis, pp. 105-114. 2010. [15] Pathak, A., Hu, Y., Zhang, M.; Where is the energy spent inside my app? Fine grained energy accounting on smartphones with Eprof. 7th ACM European Conference on Computer Systems EuroSys '12, pp. 29-42. 2012. [16] Wonwoo, J., Chulko, K., Chanmin, Y., Donwon, K., Hojung, C.; DevScope: a nonintrusive and online power analysis tool for smartphone hardware components. 8th Intl. Conf. on HW/SW Codesign and System Synthesis, pp. 353-362. 2012. [17] Yoon, C., Kim, D., Jung, W., Kang, C. and Cha, H.; AppScope: application energy metering framework for Android smartphone using kernel activity monitoring. In USENIX Annual Technical Conference. 2012. [18] Fronza, I., Sillitti, A., Succi, G., Terho, M., Vlasenko, J.; Failure prediction based on log files using Random Indexing and Support Vector Machines. Journal of Systems and Software 86 (1), pp. 2-11. 2013. [19] Scotto, M., Sillitti, A., Succi, G., Vernazza, T.; A non-invasive approach to product metrics collection. Journal of Systems Architecture 52 (11), 668-675. 2006. [20] Succi, G., Benedicenti, L., Vernazza, T.; Analysis of the effects of software reuse on customer satisfaction in an RPG environment. IEEE Trans. on Soft. Eng., 27 (5), 473-479. 2001. [21] Sillitti, A., Succi, G., Vlasenko, J.; Toward a better understanding of tool usage: NIER track 33rd International In proceedings of ICSE 2011, pp. 832-835. 2011. [22] Succi, G., Paulson, J., Eberlein A.; Preliminary results from an empirical study on the growth of open source and commercial software products. EDSER-3 Workshop, pp. 14-15. 2001 [23] Di Bella E., Fronza I., Phaphoom N., Sillitti A., Succi G., Vlasenko J.; Pair Programming and Software Defects – a large, industrial case study. Transaction on Software Engineering, IEEE, to appear (DOI: 10.1109/TSE.2012.68). (n.d.).

ACKNOWLEDGMENT Authors gratefully thank Thomas Roeggla for his support on the coding tasks of the CharM tool. REFERENCES [1] Olsen, C.M., Narayanaswami, C.; PowerNap: An efficient power management scheme for mobile devices. IEEE Trans. on Mobile Computing, Vol. 5, No. 7, pp. 816-828. 2006. [2] Carroll, A., Heiser, G.; An analysis of power consumption in a smartphone. USENIX Annual Tech. Conf, pp. 21-34. 2010. [3] Margi, C., Obraczka, K,. Manduchi, R.; Characterizing system level energy consumption in mobile computing platforms. International Conference on Wireless Networks, Communications and Mobile Computing. 2005. [4] Motlhabi, M.; Advanced Android power management and implementation of wakelocks. University of the Western Cape. Paper available online: http://www.cs.uwc.ac.za/~mmotlhabi/apm2.pdf (n.d.) [5] Maker, F., Chan, Y.H.; A survey on Android vs. Linux. University of California. Paper available online: http://handycodeworks.com/wpcontent/uploads/2011/02/linux_versus_android.pdf. 2011.

45