Antonin Carette
email: antonin.carette@gmail.com

Adel Ait Mehdi

Younes

Geoffrey Hecht
email: geoffrey.hecht@inria.fr

Naouel Moha
email: moha.naouel@uqam.ca

Romain Rouvoy
email: romain.rouvoy@inria.fr

Investigating the Energy Impact of Android Smells

Keywords: Android, energy consumption, code smells, picture

Android code smells are bad implementation practices within Android applications (or apps) that may lead to poor software quality. These code smells are known to degrade the performance of apps and to have an impact on energy consumption. However, few studies have assessed the positive impact on energy consumption when correcting code smells. In this paper, we therefore propose a tooled and reproducible approach, called HOT-PEPPER, to automatically correct code smells and evaluate their impact on energy consumption. Currently, HOT-PEPPER is able to automatically correct three types of Android-specific code smells: Internal Getter/Setter, Member Ignoring Method, and HashMap Usage. HOT-PEPPER derives four versions of the apps by correcting each detected smell independently, and all of them at once. HOT-PEPPER is able to report on the energy consumption of each app version with a single user scenario test. Our empirical study on five open-source Android apps shows that correcting the three aforementioned Android code smells effectively and significantly reduces the energy consumption of apps. In particular, we observed a global reduction in energy consumption by 4,83% in one app when the three code smells are corrected. We also take advantage of the flexibility of HOT-PEPPER to investigate the impact of three picture smells (bad picture format, compression, and bitmap format) in sample apps. We observed that the usage of optimised JPG pictures with the Android default bitmap format is the most energy efficient combination in Android apps. We believe that developers can benefit from our approach and results to guide their refactoring, and thus improve the energy consumption of their mobile apps.

I. INTRODUCTION

Mobile devices have known a huge success along the last five years, for example Android's sales increased by more than 500% since 2011 [START_REF]Global smartphone sales by operating system[END_REF]. With more than 50% of devices sold worldwide, Android has become one of the most popular operating system [6]. As the number of devices has increased, the number of applications (or apps) also grew rapidly along the last years. Therefore, the number of mobile developers also increases. Apps are mostly written using popular Object-Oriented (or OO) programming languages like Java, Objective-C, Swift or C#. Yet, mobile development is not as similar as traditional software development [54] and developers must consider the mobile specificities. Also, the user demand keeps increasing and forces mobile developers to add new features and maintain their apps as quickly as possible. Unfortunately, this pressure leads developers to adopt bad implementation practices, also known as code smells [START_REF] Fowler | Refactoring: improving the design of existing code[END_REF]. Code smells can lead to cause resources leaks in CPU, memory, battery, etc [START_REF] Brylski | Android smells catalogue[END_REF]. Leaks may deteriorate the quality of the app in terms of stability, user experience, maintainability, etc. It is also important to note that more than 18% of Android apps exhibit code smells [START_REF] Liu | Characterizing and detecting performance bugs for smartphone applications[END_REF]. Our previous studies have investigated the impact of code smells on performance and concluded that the correction of code smells improves the app performance [START_REF] Hecht | An empirical study of the performance impacts of android code smells[END_REF]. In particular, the major code smells that impact the performance of Android apps are HashMap Usage (HMU), Internal Getter/Setter (IGS), and Member Ignoring Method (MIM) [START_REF]Android performance tips[END_REF], [START_REF]Arraymap[END_REF], [START_REF] Hecht | An empirical study of the performance impacts of android code smells[END_REF]. Like performance, the battery lifespan or energy consumption of an app is a critical quality criteria [START_REF]Android developer, core app quality[END_REF]. D. Li and W. Halfond [START_REF] Li | An investigation into energy-saving programming practices for android smartphone app development[END_REF] have proven that two of the three performance code smells listed above also have an energy impact on fictive app. However, these experiments were not performed on a real user app.

In this paper, we therefore propose an automated approach, called HOT-PEPPER, supported by a framework for Android developers that allows them to assess and improve the energy consumption of their Android apps. Concretely, HOT-PEPPER enables developers to detect and correct code smells, and evaluate their impact in terms of energy consumption in Android apps. HOT-PEPPER relies on PAPRIKA, a static analysis tool dedicated to the detection and correction of code smells in Android apps.

For the impact evaluation of code smells, HOT-PEPPER relies on the tool NAGA-VIPER, which uses a physical measurement device and monitors energy-related metrics (execution time, intensity, and voltage) on Android apps. For the validation of HOT-PEPPER, we performed an empirical study that allow us to answer to the following two research questions: RQ 1 : Does the correction of Android code smells improve the energy consumption of the mobile phone? Finding: Yes, the correction of Android code smells improves the energy consumption of the mobile phone. We observed that the correction of at least one code smell reduces the energy consumption of the mobile phone. Moreover, the correction of all code smells reduces the energy consumption even more significantly. RQ 2 : Do picture smells have an impact on the energy consumption of the mobile phone? Finding: Yes, studied picture smells have a bad impact on the energy consumption of the mobile phone. We observed that using optimised JPG pictures and the default Android bitmap format reduces significantly the energy consumption of the mobile phone. The main contributions of this paper are: 1) An automated approach, supported by a framework, to detect and correct Android code smells, and evaluate their impact in terms of energy consumption; 2) An empirical study on five open source Android apps and a specific custom app, which proves that six Android smells can have an impact on the energy consumption of the mobile phone. This paper is organized as follows: Section II introduces the catalog of Android smells investigated in this paper, and the energy metrics used to evaluate the energy consumption. Section III describes the proposed approach, HOT-PEPPER, along with its supporting tools, PAPRIKA and NAGA VIPER. Section IV details the experimental study performed to analyse the energy consumption of six Android smells in five opensource Android apps and a specific custom app. Section V reports the results of this study. Section VI discusses existing approaches that deal with the correction of code smells and automated approaches to analyse and evaluate the energy consumption, both in mobile apps. Finally, Section VII summarises our work and outlines future work.

II. BACKGROUND

In this section, we introduce a catalog of Android smells that we investigated in this work for the evaluation of the energy consumption. This catalog consists of six Android smells splitted in two categories: three performance code smells and three pictures smells. Then, we introduce the energy metrics that we use to estimate the energy consumption of those Android smells.

A. Studied smells

We chose the following smells as they are commonly observed in Android apps [START_REF] Hecht | Tracking the software quality of android applications along their evolution[END_REF] and are reported to have a negative impact on Android performance. This includes two types of smells: performance code smells and pictures smells. Two of these performance code smells, Member Ignoring Method (MIM) and Internal Getter/Setter (IGS), are already reported to have a significant impact on energy consumption in a fictive Android app [START_REF] Li | An investigation into energy-saving programming practices for android smartphone app development[END_REF]. Our approach aims to measure empirically the energy consumption of the studied smells in common Android apps by using a user-driven scenario.

1) Performance code smells: HashMap Usage (HMU) : The Android framework promotes ArrayMap and SimpleArrayMap as replacements of the standard Java HashMap. They are supposed to be more memory-efficient and trigger less garbage collections with no significant difference on operations performance for maps containing up to hundreds of values [START_REF]Arraymap[END_REF]. Thus, unless a complex map for a large set of objects is required, the use of ArrayMaps should be preferred over the usage of HashMap for Android apps. Therefore, creating small HashMap instances can be considered as a code smell [START_REF]Arraymap[END_REF], [START_REF] Haase | Developing for android, ii the rules: Memory[END_REF]. However, a performance degradation of using a HashMap can occur when facing an unpredicted growth of the map. An example of HashMap Usage is provided in Listing 1. ItemColumns.ALL_COLUMNS[i]); } Internal Getter/Setter (IGS) : IGS is an Android code smell that occurs when a field is accessed, within the declaring class, through a getter (var = getField()) and/or a setter (setField(var)). This indirect access to the field may decrease the performance of the app. The usage of IGS is a common practice in OO languages like C++, C# or Java because compilers or virtual machines can usually inline the access. However, there is only the simple inlining for Android [START_REF]What optimizations can i expect from dalvik and the android toolchain[END_REF] and, consequently, the usage of a trivial getter or setter is often converted into a virtual method call, which makes the operation at least three times slower than a direct access. This code smell can be corrected by accessing the field directly within a class (var = this.myField, this.myField = var) or declaring the getter and setter methods in the public interface. Correcting IGS with this refactoring is therefore a way to increase the performance of the method accessing a field [START_REF]Android performance tips[END_REF], [START_REF] Brylski | Android smells catalogue[END_REF]. Of course, non-trivial getters/setters, as illustrated in Listing 2, are not concerned by this code smell. Therefore, a possible drawback of fixing an IGS can happen when a trivial getter/setter is modified into a non-trivial getter/setter in a future version of an app. Member Ignoring Method (MIM) : In Android, when a method does not access an object attribute or is not a constructor, it is recommended to use a static method in order to increase performance. The static method invocations are about 15%-20% faster than dynamic invocations [START_REF]Android performance tips[END_REF]. It is also considered as a good practice for readability since it ensures that calling the method will not alter the object state [START_REF]Android performance tips[END_REF], [START_REF] Brylski | Android smells catalogue[END_REF]. However, there is one possible side effect in terms of inheritance since all the extending classes have to declare or to refer to the same static methods. Listing 3 is an example of MIM. 2) Pictures smells: Picture Format : The usage of the PNG picture format is known as a bad practice when using large pictures. The JPG or GIF formats should rather be preferred in such cases [START_REF]Canvas and drawables[END_REF] [START_REF]Learn when to use jpeg, gif[END_REF]. The GIF format is a lossless compression picture format limited to 256 colors. It is used on the web to animate plural pictures. JPG is a lossy compression picture format, which makes it a common choice for storing big pictures like photographs or realistic images. This picture format uses 16 bits per pixel. PNG is a lossless compression picture format, which makes it a common choice for pictures on the web. Two different formats of PNG can be found, PNG-8, which is similar to GIF, and PNG-24, which uses 24 bits per pixel. Although it is lossless and uses a greedier pixel compression format, PNG is a good choice for storing pictures with a small file size, and with few colors. Therefore, any developer has to wisely decide on the format of pictures to display within the app depending on the size of the picture, its number of colors and its usage (icon, photograph, etc.) [9], [START_REF]How png works?[END_REF]. Picture Size : A common problem when storing pictures is to get the best trade-off between the size of the picture and its quality. The goal here is to reduce the file size without degrading a lot the quality. An existing solution is to downgrade the quality of a high-resolution picture without strongly impacting the user experience. Existing algorithms, such as PSNR [START_REF]Peak signal-to-noise ratio[END_REF], SSIM [START_REF] Wang | Image quality assessment: From error visibility to structural similarity[END_REF] and Butteraugli [START_REF]Butteraugli, a tool for measuring differences between images[END_REF], are solutions to measure with accuracy the difference and similarity of two pictures. This calculation is related to the perceived difference of both same pictures, in different resolution, by the human eye. These solutions provide excellent ways to find the best trade-off between the compression and the quality of a picture. Using these algorithms and other techniques, it is possible to reduce the size of the file without degrading the user experience [START_REF]Reducing[END_REF], [START_REF]Reducing[END_REF]. Picture Bitmap Usage : Android bitmap objects can consume a lot of memory for large pictures, especially when they are displayed at the same time by Android views like ListView or GridView [START_REF]Managing bitmap memory[END_REF]. However, a common problem with Dalvik, the Android virtual machine used for Android versions until 5.1, is that it cannot defragment in real-time the memory for a single running app. Thus, for an app that displays only a GridView of high-resolution pictures, the virtual machine may not respond to the request of the app when asking to allocate or re-allocate memory to store a new rich picture. Due to this behaviour, the app becomes slower. Android developers have to consider how to load and cache effectively bitmaps, using for example bitmap formats like RGB_565, instead of ARGB_8888. The last bitmap format is the default and greedier one for the latest version of Android. The usage of expensive bitmap formats can be considered as a bad practice in situations where the picture displayed in the app is too small to notice a difference with a picture adopting a lower pixel density [START_REF]Displaying bitmaps efficiently[END_REF].

B. Energy consumption metrics

We propose to evaluate the energy consumption by measuring the average intensity, the average voltage of the device and the time between these two measures. The intensity and the voltage are the flow and the force of electricity through an electrical line, respectively. The energy consumption is expressed in Joules considering the intensity, the voltage and the time of the experiment. The intensity of the battery is limited, and the voltage is constant all long of the phone usage. Therefore, we estimate the energy consumption of an Android app as following:

E = (V * ∆t * I Cons ) (1)
where E is the general energy consumption of the Android app (joules), V is the current voltage of the battery (volts), t is the execution time of the studied app (seconds) and I Cons is the average intensity (mA) of the mobile app and the operating system.

III. HOT-PEPPER: IMPROVING THE ENERGY CONSUMPTION

OF ANDROID APPS In this section, we introduce an automated approach, supported by a framework, called HOT-PEPPER. This approach consists in the detection and correction of code smells, in order to evaluate their impact in terms of energy consumption on Android apps.

Overview

The HOT-PEPPER approach is illustrated in Figure 1. It is supported by two main tools, PAPRIKA and NAGA VIPER. HOT-PEPPER uses PAPRIKA [START_REF] Hecht | Detecting antipatterns in android apps[END_REF] to detect Android code smells. We also improved PAPRIKA to automatically correct these smells. As a first step, PAPRIKA takes as input the original app's APK to detect Android code smells. Next, this tool uses detected code smells, and the Android app source code, to generate several fixed APK versions of the app. PAPRIKA generates as many fixed versions of the Android app as detected Android code smells, plus a version fixing all these code smells. HOT-PEPPER uses NAGA VIPER, a tool that we developed to evaluate the impact of each APK version of the Android app, including the original one, iteratively. As a first step, NAGA VIPER takes as input all existing APK versions of the Android app, a scenario based on user events, and an Android smartphone plugged to a physical measuring device. This step consists in computing energy metrics for each APK. After this, NAGA VIPER compares these energy metrics to return the most energy-efficient APK, the associated source code, and the list of refactorings from the Paprika's correction. In the following, we describe the steps covered by PAPRIKA and NAGA VIPER.

PAPRIKA

In order to produce the most energy-efficient app, HOT-PEPPER uses PAPRIKA, a static tool analysis for Android apps. This analysis consists in detecting and correcting Android code smells.

Step 1: Detecting code smells Input: The original Android app APK to analyse. Output: All detected code smells in the app. Description: First, HOT-PEPPER needs to analyse the APK, built from the developer, in order to retrieve Android code smells. For this purpose, we use the PAPRIKA analysis. In this step, PAPRIKA takes as input the Android APK and runs the analysis phase, which consists in detecting code smells in the app. As a result, PAPRIKA returns a list of code smells that contains specifically, for each code smell type, their proportion and their location in the app. Implementation: To perform the analysis step, PAPRIKA needs to build a model of the Android app in order to retrieve 8 entities: App, Class, Method, Attribute, Variable, ExternalClass, ExternalMethod, and ExternalArgument. PAPRIKA is based on the SOOT framework and its DEXPLER module [START_REF] Bartel | Dexpler: Converting android dalvik bytecode to jimple for static analysis with soot[END_REF] to analyse the APK, in order to build the app's model. SOOT converts the Dalvik bytecode of mobile apps into an internal representation, composed by previous entities, that we translate as a NEO4J graph. Finally, PAPRIKA detects code smells by querying the NEO4J graph model using CYPHER (cf. Listing 5). Step 2: Correcting code smells Input: Detected code smells in the Android app and the app source code. Output: The corrected APK versions of the Android app, and the original one. Description: For this step, PAPRIKA requires the Android source code of the app and the list of detected code smells. For each type of code smells, PAPRIKA generates a version of the app without those. Moreover, at the end, the tool generates a version without any detected code smells. At the end, PAPRIKA returns each refactored version, and the original APK. During our empirical study, we prove that the automatic correction of detected code smells does not alter the behaviour of the app. Implementation: The correction phase is performed using SPOON [START_REF] Pawlak | Spoon: A library for implementing analyses and transformations of java source code[END_REF], a library for static analysis and transformation of Java source code. For the transformation, SPOON works on a model of the input source code. SPOON generates the model parsing the input source code, to produce a raw Abstract Syntax Tree (AST). Each node of the AST corresponds to a source program element like Class, Method, Field, Statement, Expression and so on. SPOON allows the navigation through a type of nodes (e.g., classes) via SPOON processors. SPOON processors allow developers to perform a specific action, like refactoring. For each type of code smell detected in the first step, we write a dedicated SPOON processor to perform the correction of this type. PAPRIKA starts each SPOON processor independently on the app source code to generate as many APK versions as code smell types. Finally, the tool applies the whole set of SPOON processors on the app source code to correct all of those, and generates a fully corrected version. Processor exemple (IGS): The IGS's processor correction works on the invocation (e.g., methods call's) elements of each class of the app in the analysis output. For the IGS type, the analysis output corresponds to the class that the IGS is detected. This processor checks if the IGS called is a getter or a setter. After this, it retrieves the accessed field from the getter or the setter body. For example, for the getter case, it gets the field from the return statement, catching the returned expression. To correct IGS code smells, we have to replace all getter and setter calls by a direct access to the given class field. For the getter, we replace the expression of the getter with a direct call to the field. For the setter, we replace the invocation of the setter with an assignment statement.

Listing 6. Replace the invocation of the setter with a direct assignment public class IGSProcessor extends AbstractProcessor<CtInvocation> { ... @Override public void process(CtInvocation invok) { ... CtStatement igsSetter = getFactory().Code(). createCodeSnippetStatement(getField + " = " + invok.getArguments().get(0)); invok.replace(igsSetter); ...

NAGA VIPER

To deliver the most energy-efficient Android app, our approach evaluates different versions of an app, by collecting energy metrics for each versions. To this end, HOT-PEPPER uses a tool called NAGA VIPER, to compute energy metrics and evaluate the impact of corrected APKs.

Step 3: Computing energy metrics Input: The original Android APK, each fixed Android APKs Implementation: NAGA VIPER starts collecting a parameterised number of metric values per second, as soon as the scenario starts and until it stops. For the computation of the average smartphone's energy consumption (I Cons ), the tool uses a physical measuring device (ammeter, voltmeter. . . ) plugged on the phone. This device provides an API to retrieve easily accurate measures from the smartphone. This method allows NAGA VIPER to compute the metrics based on accurate values in runtime, which correspond to the intensity of the smartphone along the scenario executions, that the smartphone consumes (ampere, volts, etc.). The second energy metric to compute is the average execution time of the scenario (t), for each Android version. The third metric value to take account is the voltage of the smartphone's battery (V ). This last metric is a constant, so NAGA VIPER have to compute only one time the voltage of the battery. All metrics values are sent to a remote server, which collect them in order to compute average energy metrics. NAGA VIPER runs a parameterised number of times the Android app and the collection of energy metrics, in order to reduce the impact of interferences that can be caused by external factors. Once those running are performed, the remote server computes all average energy metrics, and iterates on the next Android app version to evaluate. Finally, when all Android apps have been evaluated, the server send computed energy metrics and associated Android APKs to the next step.

Step 4: Evaluating the energy impact of corrected APKs Input: Android APKs and associated energy metrics. Output: A bundle that contains the most energy-efficient APK to deploy, the fixed Android source code associated to this APK, and a file that describes source code changes. Description: HOT-PEPPER identifies the best energy-efficient Android app by comparing energy saving percentages between each Android APK version, including the original one. Once this evaluation is done, NAGA VIPER delivers the most energyefficient APK, the associated source code, and the file that contains source code transformations. Implementation: First, based on energy metrics computed in Step 3, NAGA VIPER computes the global energy consumption (cf. Equation 1) for each Android app version. Second, NAGA VIPER computes the percentage of energy saving between each corrected version and the original one. This percentage value is used to evaluate the difference of energy consumption between those studied versions. Finally, NAGA VIPER gets the Android APK associated to the highest percentage of energy saving, and informs the developer which APK is the best energy-efficient version, for the given scenario. The tool outputs a bundle that contains the best energy-efficient APK to deploy, the associated Android source code, and the file that describes all source code refactorings.

IV. STUDY DESIGN

In this section, we explain the design of our study, which aims to evaluate the energy impact of Android bad practices described in Section II.

For this purpose, we address the following research questions: RQ 1 : Does the correction of Android code smells improve the energy consumption of the mobile phone? RQ 2 : Does picture smells have an impact on the energy consumption of the mobile phone? A. Objects

We propose to evaluate the energy consumption of three different Android code smells using HOT-PEPPER. To this end, we had to find several open-source Android apps, which are available in public and popular apps store, like F-Droid. The apps were selected according to the following criteria:

• the category and usability of the Android app;

• the popularity of the app, based on the rating and the number of downloads; • and the presence of two code smell types (minimum), previously studied in Section II: HMU, IGS, and MIM. Therefore, we ran the PAPRIKA analysis on over 1,900 apps, through F-droid. Following the previous criteria, we found 34 apps in six categories : Music, Reader, Productivity, Utility, Sport, and Education. We selected, for each category, the apps that contain the highest number of code smells, for at one type. Also, we ensured that these apps could be built and that the license of each app is fully open-source. At the end of this process, among the 34 apps, we selected five Android apps from five different categories, as reported in Table I. We did not select any Sport apps, because the only app found in this category required to use a smartwatch. The selected apps are Aizoban, Calculator, SoundWaves Podcast, Todo, and Web Opac. Aizoban is an online/offline catalogue of mangas that allows the user to read, save, and download their favorites mangas. The version of the app is the version 1.2.5. Calculator (version 5.1.1) is the default calculator of the CyanogenMod ROM 11 [START_REF]Cyanogenmod, a customized, aftermarket firmware distribution for several android devices[END_REF]. SoundWaves Podcast is a podcast app that allows the user to search, download, and listen to podcasts. The study was performed on the version 0.130 of the app. Todo (version 1.0) is an app that allows users to create and customise their 'to do' lists. Web Opac (version 4.5.9) allows the access to a catalog of more than 500 public libraries, over 30 countries. The functionalities of this app include: search a library, find a book in the catalog of a library, and make a book reservation. The source code of each app is available on GitHub or SourceForge, via their own F-Droid homepage.

In addition to this analysis, we performed experiments on the three picture smells. However, most of the open-source apps available on F-Droid do not store their pictures locally. As a consequence, we cannot edit enough pictures of popular apps to achieve our study. For this purpose, we rather used seven custom apps to evaluate the energy impact of picture smells. Each custom app loads several random pictures, with a specific picture format, size, and bitmap configuration.

B. Subjects

The subjects of the study were the three Android code smells and the three picture smells previously described in Section II.

C. Experimental Design

For the three Android code smells studied, we corrected the five apps reported in Table I using PAPRIKA, and we obtained several corrected versions of the app. Those versions are described in Table II. V 0 is the original version of the app. V HM U , V IGS , and V M IM are derived from V 0 by correcting HMU, IGS and MIM respectively. Finally, V ALL is the version where all Android code smells are corrected.

For the study of the three picture smells, we created seven custom apps. For the picture format smell, we use two apps that contain PNG or JPEG pictures: V P and V J . For the picture size smell, we propose to evaluate the V J version and a new one: V JO . This version contains a compressed version of each JPEG picture from V J . The compression has been performed using a proprietary software named JPEGMini [START_REF]Jpegmini -your photos on a diet[END_REF], which reduces the size of the picture without degrading its visual quality. Finally, we propose to evaluate four Android apps to study Android bitmap code smells: V A_P and V A_JO correspond respectively to the use of the ARGB_8888 bitmap configuration on PNG and JPEGO format , and V R_P and The major differences between these versions are that CyanogenMod includes additional developers options, e.g. it offers a simple way to turn on/off the root option (that is essential for our experiments), and does not include some apps and services provided by Google. As depicted in Figure 2, we used also an ammeter as a physical measuring device and plugged it in a specific battery harness to the smartphone's model. The harness has been plugged between the battery and the mobile phone, and the ammeter is connected to the harness and the server to collect metrics. Minimization of external factors: To make our experiments reproducible, we set a specific environment with specific rules. First, to communicate with the mobile phone during our experiments, we use the USB port of the phone to reach the ANDROID DEBUG BRIDGE (ADB). We disable the USB charging to use NAGA VIPER, and we re-enable it to reload the battery. After reloading it, we shut it down during five minutes to cool down the battery heat. Also, we noticed some side effects on the energy consumption of Android apps under 50% of the battery level. Therefore, it is important to maintain the battery level above this value. We disable mobile data, Bluetooth, GPS, and Wi-Fi, when the application does not need an Internet access (e.g., Todo app). The screen brightness and the sound are set to the minimum. Before we start each experiment for a given app, we make sure that all the other apps of the phone are stopped. For each app, we use a deterministic scenario, based on user events. We run 20 times each scenario on a specific app and collect the energy metric values using NAGA VIPER. Therefore, we make sure to reduce the influence of any external factors. Furthermore, the phone must be fully charged between each set of 20 runs, to start the scenario of each app at the same battery level. Finally, we restart the phone, and we repeat the procedure for an other app.

1) Evaluation of Android code smells using HOT-PEPPER: Detection and correction of code smells: First, we get the original APK of each selected app (V 0 ) and the associated source code to run PAPRIKA's analysis and get the list of detected code smells. For each code smell type, we have a list of classes and methods where code smells are located.

After the detection of code smells, PAPRIKA applies the correction step on the source code of the app. PAPRIKA starts the correction processors independently on the V 0 version of the app to generate each of its corrected versions: V HM U , V IGS , and V M IM . Then, the tool runs the correction processors simultaneously on the V 0 version of the app to generate V ALL . We validated the automated correction done by PAPRIKA by comparing manually, for a given app namely Soundwave, a correction done manually with an automated one. This comparison has been performed in terms of energy consumption, scenario behaviours, and source code, and was perfectly identical. Scenario test: After the correction of code smells, NAGA VIPER runs a specific scenario on the app. This scenario uses Calabash [START_REF] Calabash | an automated acceptance testing for mobile apps[END_REF], an automated testing technology for mobile apps written in Ruby. For each app, we create a Calabash scenario that browses a maximum of app's features. Each Calabash scenario is based on x steps and y waits. Steps correspond to user events (e.g., click, scroll, input text, clear text, etc.) and waits correspond to delays, in seconds. Synchronisation barriers are used to ensure that all views are fully loaded before using any feature. As reported in Tables I andIII, scenarios cover a representative number of code smell types and occurrences.

Computation and evaluation of energy metrics: Each scenario has been run 20 times for an app version. The tool collects 75 intensity values per second directly on the smartphone, during the execution time of the scenario, via the ammeter's API. Those values are associated to timestamps that allow NAGA VIPER to compute the execution time of the app. Once intensity values and the execution time of the app have been collected, NAGA VIPER computes energy metrics as explained in Section II, for each run. These energy metrics, for the 20 runs, are used to compute the global energy consumption of the app. In addition to these energy metrics, we compute Cliff's δ stats to evaluate if the difference of energy consumption between each app is significant or not.

2) Evaluation of pictures smells using NAGA VIPER: Pictures apps: To run our experiments on picture smells, we created seven versions of a custom app. This custom app is composed of 12 pictures found on the internet. These pictures are initially PNGs and have a transparent background, and a size between 0.12 and 1.0 Mbyte each. The app uses a GridView (3x4) to display them. This app contains two user events: scrolling to browse pictures and taping on a picture to display it for three seconds. Each version of this app has been explained in the experimental design. Computation and evaluation of energy metrics: We developed a specific scenario that lasts around 2 minutes. The scenario scrolls and taps several pictures during its execution. We use this scenario for each version of the app. Each scenario has been run 30 times for each version. NAGA VIPER collects the same energy values as Android code smells.

E. Variables

Independent Variables: In our experiments, the independent variables correspond to the number of each of the three code smells IGS, HMU and MIM corrected in each app. In case of our experiments on images, the independent variables are the size and the format of the image as well as the bitmap format used.

Dependent Variables: Previously, in Section II, we have listed the metrics used to evaluate the energy consumption of the app: the execution time of the app, the voltage and the average intensity. These metrics are our dependent variables.

F. Analysis Method

For our analysis method, we perform Cliff's δ effect size [START_REF] Romano | Appropriate statistics for ordinal level data: Should we really be using t-test and cohen'sd for evaluating group differences on the nsse and other surveys[END_REF] to support the results difference's between each version. The tests are performed using a 99% confidence level. A small effect size (δ > 0.147) represents a slight difference hardly visible, a medium effect size (δ > 0.330) represents a visible difference that can be observed, while a large effect (δ > 0.474) is significantly larger than medium. We use the average values of all experiments to compare versions.

V. CASE STUDY RESULTS

This section reports and discusses the results we obtained to answer our research questions.

1 : Does the correction of Android code smells improve the energy consumption of the mobile phone?: For answering RQ 1 , we use the 5 popular Android open-source apps listed before. In Table III, we report the global energy consumption for the different versions and the one that consumes the less, in bold. Globally, all corrected versions consume less energy than the original one, except for two corrected versions-i.e., V M IM in Aizoban and in SoundWaves. However, these two versions have a negligible increase in terms of energyi.e., these versions consumes 0.08% and 0.29% more than the original app, which may be caused by a measurement error with the physical device. The best version for Calculator and Todo is V ALL with an energy saving of 1.69% and 4.83%. The one for Aizoban is V HM U with an energy saving of 2%. The one for SoundWaves is V IGS with an energy saving of 1.43%. Finally, the one for Web Opac is V M IM with an energy saving of 3.86%. Based on Tables IV andV, we can notice that there is a large significant difference between the original app and each corrected version, for Aizoban, Web Opac and Todo. For Calculator and SoundWaves, we notice that there is a low and a medium difference between the original version and each corrected one. Finally, we can notice that even if V ALL is not the best version for Aizoban, SoundWaves and Web Opac, this version is statistically equivalent to the best version of those apps with -0.01, 0 and -0,11 as Cliff's δ results. So, V ALL can be also considered as the best version for the five selected Android apps.

In summary, the results our research show that the correction of at least one Android code smell (HMU, IGS or MIM) reduces the energy consumption of the mobile phone. Also, based on Cliff's δ results, we can assert that the correction of all code smells on an app has a better impact that the correction of only one of them.

RQ 2 : For answering RQ 2 , we studied three different variables: the picture's format (JPEG or PNG), the size of the file (only for JPEG, in MBytes) and the bitmap format of the picture (ARGB_8888 or RGB_565). Overall, we performed our experiments on seven versions of the picture app to measure the impact of each variable, as explained in the study design.

To perform our experiments on JPEG pictures, we converted the previous pictures to JPEG, and reduced the size of each file until the minimum size has been reached, using JPEGMini. The original directory size that contains PNG directory is 700 KBytes, 1 MBytes for the JPG directory and 367 KBytes for the optimised JPG directory. Results are given in Table VI. Each experiment, for each app version, has been run 30 times. Using 30 tests, the average power consumption of the PNG app is 0.0525 Joules, 0.0536 Joules for the JPG app and 0.0535 Joules for optimized JPG app. We notice that only the power consumption of the PNG app has changed. However, we notice also that there is no statistical difference between the JPEG app and the optimised JPG app. Those observations rely on Cliff's δ computations in Table VII, and comfort us to think that the size has no influence in the global energy consumption of an Android app. For Android bitmaps the global energy consumption of V R_JO is up to 0.0490 Joules, that is greater than V A_JO that consumes 0.0487 Joules, which is the best version of the app for optimised JPEG files. Also, we found that the version V R_P is up to 0.0524 Joules, in contrary to V A_P that consumes 0.0490 Joules, which is the best version of the app for PNG files. Based on Cliff's δ results in Table VII, we found that the difference between V A_P /V R_JO , V P /V R_P and V J /V R_P is not significant. For each other version, the difference of energy consumption is significant, and contributes to conclude that V R_P /V A_JO is the most energy-efficient app. Those results indicate also that V A_P and V R_JO are statically similar and that V R_JO can be considered as the second best version app, in terms of energy consumption.

In summary, we can conclude that the bitmap format has an impact on the energy consumption of the mobile phone. Contrary to what was stated in the Android performance tips, we found that the larger bitmap format (ARGB_8888) has a better energy consumption than the lower (RGB_565).

A. Threats to Validity

In this section, we discuss the threats to validity of our study based on the guidelines provided by Wohlin et al. [START_REF] Wohlin | Experimentation in software engineering[END_REF].

Construct validity threat is the relation between the theory and the observations made. For our experimentation, it could be due to measurements errors. For this purpose, we ran many experiments -20 run for apps with code smells and 30 run for pictures apps -, and used averages values instead of instant values. In addition, in Section IV-D, we described how we tried to reduce the impact of external factors to make our measurements as accurate as possible. Also, measures of our ammeter could be wrong, because they are physical measurements. However, we tried two different ammeters when we ran Hot-Pepper, which provided similar results in both cases. Moreover, our reasoning are based on the difference between measures, therefore the impact of such errors is diminished.

Internal validity threat is the causal relationship between the treatment and the outcome. As our results depend on the correction of code smells, we make sure that Paprika correct all code smells in the app by investigating manually the source code after the correction process. For pictures smells, the correction is already done manually.

External validity threat is the possibility to generalise our finding. Our results depend on various parameters such as the app (the category, the developer, the permissions, etc.), scenarios used, the number of code smells detected -and their occurrences during a scenarios -, the Android version, and the smartphone. For performance code smells, our results are dedicated to our Workbench, explained in Section IV-D, they cannot be generalised at this time. However, we tried to use various apps with different categories, permissions, and code smells, which have been ran with different user scenarios on

V J V JO V A_P V A_JO V R_P V R_JO V P -0.74 -0.72 1 1 0 1 V J - 0.10 1 1 0.69 1 V JO - - 1 1 0.72 1 V A_P - - - 0.2 -0.96 0 V A_JO - - - - -0.98 -0.23 V R_P - - - - - 0.43
rules in Subsection IV-D that must be respected, in order to have comparable conditions. In addition to the informations provided in this paper, the apps used and their scenarios are available in a public git repository 1 .

Conclusion validity threat supports that the conclusions reached in a study are correct. We paid attention to not violate the assumptions of our statistical tests. For this purpose, Hot Pepper uses only non-parametric tests which are not making any assumptions about the distribution of the metric. Finally, we were careful to not generalise our findings.

VI. RELATED WORK

In this section, we discuss the relevant literature focusing on energy code smells, energy analysis on Android devices and automated energy optimisation techniques.

Energy leaks. Most of the literature specific to Android energy leaks takes care of high-level energy bugs like wakelocks [START_REF] Banerjee | Debugging energyefficiency related field failures in mobile apps[END_REF], [START_REF] Gottschalk | Removing energy code smells with reengineering services[END_REF], ads [START_REF] Gui | Lightweight measurement and estimation of mobile ad energy consumption[END_REF] and network utilisation [START_REF] Balasubramanian | Energy consumption in mobile phones: a measurement study and implications for network applications[END_REF], [START_REF] Duribreux | An energy-efficient location provider for daily trips[END_REF], [START_REF] Li | Automated energy optimization of http requests for mobile applications[END_REF]. These approaches focus on energy bugs detection and correction. In contrast, we are interested in reducing energy leaks induced by energy code smells. Two research papers focus on code smells. Pérez-Castillo and Piattini investigated the effect of God Class refactoring on energy consumption [START_REF] Pérez-Castillo | Analysing the harmfull effect of god class refactoring on power consumption[END_REF] for Android apps. They found that the God Class refactoring increases the energy consumption of an app, this is due to the implementation of new methods, classes and by the increase in the number of lines of code as a consequence of the refactoring. Halfond et al. [START_REF] Li | An investigation into energy-saving programming practices for android smartphone app development[END_REF] measures the energy saving for IGS and MIM code smells.This approach is based on a custom app. They found that the IGS refactoring consumes 35% less energy, and that the MIM refactoring consumes 15% less energy, when in our approach IGS refactoring consume at best 2.08% less energy and MIM refactoring consume at best 3.86% less energy. However, the important difference with our results can explained by the context of the experimentation. First, we run our experiments on a different set of real and available apps, when they only used one sample app made for their experiments. In addition, we run our tests on a user-based scenarios when they loop 50, 000, 000 times over the code smells invocation. Gottschalk et al. [START_REF] Gottschalk | Removing energy code smells with reengineering services[END_REF] propose a method to improve energy-efficiency on app level, by applying re-engineering techniques, like code analysis and code restructuring. This method is applied on apps and considers loop bugs, dead code, in-line methods and cache utilisation as energy code smells.

Energy consumption analysis for Android. The overall related work can be split into two categories: static and dynamic energy analysis. Mittal et al. [START_REF] Mittal | Empowering developers to estimate app energy consumption[END_REF] present an energy emulation tool that allows developers to estimate the energy consumption of a mobile app during its development. Marcu and Tudor [START_REF] Marcu | Energy consumption model for mobile wireless communication[END_REF] also explores this aspect to measure the energy consumption with a special device emulator. On the contrary, we based our experiments on a popular android device, the Galaxy Nexus. Experiments using static energy leaks detection uses API invocation trees [START_REF] Li | Automated energy optimization of http requests for mobile applications[END_REF], [START_REF] Zhang | Accurate online power estimation and automatic battery behavior based power model generation for smartphones[END_REF] or modified function call graph [START_REF] Guo | Characterizing and detecting resource leaks in android applications[END_REF]. Dynamic detection is the most used technique to experiment on network [START_REF] Gui | Truth in advertising: the hidden cost of mobile ads for software developers[END_REF], using test scripts [START_REF] Hindle | Greenminer:a hardware based mining software repositories software energy consumption framework[END_REF], [START_REF] Li | An investigation into energy-saving programming practices for android smartphone app development[END_REF], [START_REF] Li | Calculating source line level energy information for android applications[END_REF] or scenarios [START_REF] Linares-Vasquez | Mining energy-greedy api usage patterns in android apps: an empirical study[END_REF]. Jabbarvand et al. [START_REF] Jabbarvand | Ecodroid: an approach for energy-based ranking of android apps[END_REF] use both static and dynamic energy leaks detection to rank apps of the same category. The static part is used as a static model extractor to annotate the call graph of the android app, and the dynamic part to run some test-case and have a profiler about this app. Zhang et al. [START_REF] Zhang | Accurate online power estimation and automatic battery behavior based power model generation for smartphones[END_REF] worked on a automatic power estimator for Android, based on user-reported failures. POWERBOOTER is accurate within 4.1% on average, whereas our approach is accurate to within 2mA (in average less than 1% for an android app run), using a physical device plugged directly on the smartphone's battery. Duribreux et al. [START_REF] Duribreux | An energy-efficient location provider for daily trips[END_REF] and Lineares-Vasquez [START_REF] Linares-Vasquez | Mining energy-greedy api usage patterns in android apps: an empirical study[END_REF] used an hardware power monitor to measure efficiently the energy consumption for a single Android app, instead of measuring bias using an Android app. This physical device can precisely measure the energy consumption spent in the smartphone since it is plugged between the battery and the smartphone. Our work is capable to measure energy consumption per application, using a user-based scenario, with an accurate physic ammeter: the YOCTO-AMP [START_REF]Yocto-amp, a physical ammeter[END_REF].

Correction of Android Code Smells. Actually, except LINT [START_REF]Improve your code with lint[END_REF], the tools proposed with the Android Developer Tools (ADT) and our tool PAPRIKA, there is no specific tools dedicated to the Android platform for the analysis and correction of these code smells. By checking the LINT documentation, we discovered that it can only detect one Android-specific code smells of this study (IGS). There are also specific environments and platforms dedicated to software analysis like IPlasma [START_REF] Marinescu | iplasma: An integrated platform for quality assessment of object-oriented design[END_REF], which is a specific environment for quality software analysis and DECOR [START_REF] Moha | Detection and correction of design defects in object-oriented designs[END_REF] for the detection and correction of antipatterns. For the code transformation, there is some tools and studies on Java code refactoring related to code smells. Like JDEODORANT [START_REF] Fokaefs | Jdeodorant: Identification and application of extract class refactorings[END_REF], which is an ECLIPSE plug-in that analyse and refactor the code smell detected. However these tools are not specific to Android, and thus consider only Object oriented code smells of the Java language.

VII. CONCLUSION AND FUTURE WORK

Energy consumption has become an important topic in software development and it is even more critical for mobile software engineering, as mobile devices run on limited resources and a limited battery. Various studies prove that some Android code smells decrease Android app's performance, and for this purpose many tools were developed to help developers during their development to detect these code smells [START_REF] Hecht | An empirical study of the performance impacts of android code smells[END_REF], [START_REF] Liu | Characterizing and detecting performance bugs for smartphone applications[END_REF], [START_REF] Saglam | Measuring And Assesment Of Well Known Bad Pratices In Android Application Developments[END_REF]. However, there are few works on the energy impact of code smells. Moreover, there are no tools or frameworks available to evaluate Android apps and help developers to detect and correct code smells.

In this paper, we presented an empirical study on six Android apps (five Android open source apps and one custom app) to assess the energy impact of Android performance code smells (HashMap Usage (HMU), Internal Getter/Setter (IGS), and Member Ignoring Method (MIM)) and Android picture smells (Picture Format, Picture Size, and Picture Bitmap Usage). For this purpose, we developed an automated approach called Hot-Pepper that detects and corrects these code smells and assess their energy impact to retrieve the best version of the app.

Our results show that these code smells have an impact on the energy consumption, and that by correcting them we can improve the energy efficiency of an Android app. The correction of only one performance code smell (MIM) can reduce up to 3.86% the energy consumption of an app, while the correction of all code smells can reduce up to 4,83% of the energy consumption. For Android picture smells, we found that using the best compression, associated to the default Android bitmap format has a positive impact on the energy consumption of the mobile phone. Globally, we observed that the correction of all Android code smells is the best practice, even if it can be outperformed in some cases by the correction of a single code smell.

We believe that this study will benefit the developers by helping them to avoid the usage of code and picture smells. Therefore, we hope that our approach will be useful to evaluate apps and help to reduce their energy consumption. For future works, we will extend our studies by investigating more code smells and apps. In addition, we plan to work on a nonintrusive method to collect our energy metrics. Finally, we also plan to deploy our approach and protocol on a cloud platform to make it more accessible for developers.

Listing 5 .

 5 Cypher query to detect Internal Getter/Setter MATCH (m1:Method)-[:CALLS]->(m2:Method), (cl:Class) WHERE (m2.is_setter OR m2.is_getter) AND cl-[:CLASS_OWNS_METHOD]->m1 AND cl-[:CLASS_OWNS_METHOD]->m2 RETURN m1

Fig. 1 .

 1 Fig. 1. Overview of the Hot-Pepper

Fig. 2 .

 2 Fig. 2. Yocto-Amp embranchment with the NAGA VIPER server and an Android phone

  Listing 1. Example of HashMap Usage in SoundWaves Podcast app

	if (itemMap == null) {
	itemMap = new HashMap<>();
	for (int i = 0; i <
	ItemColumns.ALL_COLUMNS.length; i++)
	itemMap.put(ItemColumns.ALL_COLUMNS[i],

TABLE I LIST

 I OF THE FIVE APPS (category, main package, number of classes, methods, and code smells)

	Apps	Category	Main package	#Class	#Method	#HMU	#IGS	#MIM	All
	Aizoban	Reader	com.jparkie.aizoban	524	2773	39	190	110	339
	Calculator	Utility	com.android2.calculator3	147	830	0	10	8	18
	Web Opac	Education	de.geeksfactory.opacclient	367	2176	48	77	43	168
	SoundWaves	Music-Streaming	org.bottiger.podcast	520	2,672	5	47	14	66
	Todo	Productivity	com.xmission.trevin.android.todo	161	610	9	3	0	12

TABLE III GLOBAL

 III ENERGY CONSUMPTION FOR DIFFERENT VERSIONS OF THE FIVE ANDROID APPS (# STEPS, WAITS IN SECONDS, # CODE SMELLS CALLS, GLOBAL ENERGY CONSUMPTION IN JOULES)

	Apps		#Step	Waits	#HM Uc	#IGSc	#M IMc	V 0	V HM U	V IGS	V M IM	V ALL
	Aizoban	169	17s		10		1300	0	0.0424	0.0415	0.0419	0.0425	0.0418
	Calculator	325	0s		0		6122	1350	0.0300	-	0.0300	0.0299	0.0295
	SoundWaves	172	53s		420		8053	6560	0.0859	0.0856	0.0847	0.0867	0.0848
	Todo		248	5s		40		20	0	0.0369	0.0361	0.0362	-	0.0352
	Web Opac	136	79s		6		133	40	0.0392	0.0384	0.0384	0.0377	0.0378
		TABLE IV
	GLOBAL ENERGY CONSUMPTION BENEFIT FOR THOSE THREE FIRST CODE
		SMELLS STUDIED, IN PERCENT.
	Apps	HMU	IGS			MIM	ALL
	Aizoban	-2.00%	-1.09%	+0.08%	-1.38%
	Calculator	-	-0.18%	-0.45%	-1.69%
	SoundWaves	-0.38%	-1.43%	+0.29%	-1.29%
	Todo	-2,40%	-2,04%		-	-4,83%
	Web Opac	-2.06%	-2.08%	-3.86%	-3.50%

TABLE VI EVALUATION

 VI OF EACH VERSION OF THE STUDIED APP, USING NAGA VIPER, IN TERMS OF ENERGY CONSUMPTION. THE DIRECTORY SIZE IS MBYTES. THE UNIT IS JOULES.

	Application	Pic. dir. size	DRAW	ARGB_8888	RGB_565
	PNG	0.70	0.0525	0.0487	0.0524
	JPEG	1.00	0.0536	0	0
	JPEGO	0.37	0.0535	0.0482	0.0490
			TABLE VII
	CLIFF'S δ ESTIMATION BETWEEN EACH VERSION OF THE ORIGINAL APP.

https://github.com/SOMCA/hot-pepper-data/tree/master/scenarios