8th International Workshop on Quantitative Approaches to Software Quality (QuASoQ 2020) Detection and Correction of Android-specific Code Smells and Energy Bugs: An Android Lint Extension Iffat Fatimaa , Hina Anwarb , Dietmar Pfahlb and Usman Qamara a College of Electrical and Mechanical Engineering, National University of Sciences and Technology,Islamabad, Pakistan b Institute of Computer Science, University of Tartu, Tartu, Estonia Abstract Context: While Android applications suffer from code smells and energy drain issues there is still a lack of tools that help developers improve energy consumption and maintainability of Android applications. Objective: Our research aims to provide tool support to Android developers helping them to create greener and more maintainable applications by eliminating Android-specific code smells/energy bugs. The proposed tool support integrates routine code smell detection with energy bug detection so that developers can do both at the same time. Method: We extend ‘Android Lint’ (AL) with custom rules to detect and correct 12 code smells (nine are new and three are improved) and three energy bugs (two are new and one is improved). In addition, for the improved and newly introduced code smells, we compared the performance of our tool with the open version of the ’PAPRIKA’ tool. Result: We evaluated our tool on nine open-source Android applications. Our tool detects the specified code smells and energy bugs with an average precision, average recall and F1 score of 0.93, 0.96, and 0.94, respectively. It accurately corrects 84% of selected code smells and energy bugs. The performance of the new and improved code smell detection is better than that achieved by ‘PAPRIKA’. Conclusion: Our tool is a useful extension to the existing ‘AL’ tool with better performance than ‘PAPRIKA’. Keywords Green Software Development, Android, Energy Optimization, Code Smell, Energy Bug, Android Lint, Detection, Refactoring, Static Analysis 1. Introduction carried out on the impact of object-oriented smells in Java applications [3, 4, 5, 6]. In our previous Recently, the focus of research has shifted towards work [1] we identified support tools that aid green sustainable and green software development with a Android development. We further identified the focus on energy optimized programming and energy coverage of code smells and energy bugs by those optimization at the application level [1]. Software tools and identified their limitations. We concluded is now being built not only keeping performance, that there is a lack of guidelines for Android devel- dependability, and maintainability in mind but also opers to write sustainable software. Current state the principles of green software engineering aiming of the art tools lack in providing complete coverage at the development of sustainable software with for Android code smells and energy bugs. More- less negative impact on the environment. With the over, they lack in usability, IDE integration and fast-paced emergence of mobile technologies in the effective refactoring approach. The aim of this re- past decade, mobile applications are being widely search is to create a tool that solves these issues by used. 3.5 billion people use smartphones around aiding developer to solve energy related problems the world [2], and Android has 75% of the market during development of the application for improved share. performance and maintainability. Code smells and energy bugs have been identi- ‘Android Lint’ (AL) is the default static analysis fied as causes of abnormal energy consumption in tool in Android Studio IDE, hence used by most Android applications. Significant research has been Android developers. Code smells detected and pri- oritized by ‘AL’ tend to disappear faster from code QuASoQ 2020: 8th International Workshop on base as compared to other code smells detection Quantitative Approaches to Software Quality, December 1st, 2020, Singapore tools. Moreover, a lint tool integrated in Android " iffat.fatima@ce.ceme.edu.pk (I. Fatima); Studio IDE not only encourages the developers to hina.anwar@ut.ee (H. Anwar); dietmar.pfahl@ut.ee correct code smells on the go but also plays a role in (D. Pfahl); usmanq@ceme.nust.edu.pk (U. Qamar) developer education [7]. We chose a custom imple-  0000-0002-4725-4636 (H. Anwar); 0000-0003-2400-501X mentation of ‘AL’ API to 1) maximize coverage of (D. Pfahl) © 2020 Copyright for this paper by its authors. Use Android code smells/energy bugs, 2) provide recom- mendations to developers for refactoring, 3) provide permitted under Creative Commons License Attribu- tion 4.0 International (CC BY 4.0). CEUR CEUR Workshop Proceedings (CEUR- Workshop http://ceur-ws.org a preview of the detected and corrected code, and ISSN 1613-0073 Proceedings WS.org) 71 8th International Workshop on Quantitative Approaches to Software Quality (QuASoQ 2020) 4) provide an interface consistent with the Android applications. They detected energy bugs like Cam- Studio IDE. era Leak, Memory leak, Multimedia Leak, sensor The ’extended Android Lint’ (xAL) tool is evalu- Leak, and layout defects. ated on open-source Android applications to detect Olivier Le Goaër [14] presented an automated tool and correct code smells and energy bugs. The cur- based on ‘AL’ which detected 11 energy greedy An- rent evaluation has resulted in average precision, droid patterns such as Draw Allocation, Wakelock, average recall and F1 score of 0.93, 0.96, and 0.94, Recycle, Obsolete Layout Parameter, HashMap Us- respectively. Whereas, 84% of the suggested correc- age, Member Ignoring Method, Excessive Method tions applied to the applications under test, resulted Calls and some Resource Leaks. The tool ‘Au- in the smooth functioning of applications. However, toRefactor’ was used for refactoring and the impact results cannot be generalized based on these statis- of those refactoring on energy consumption of open- tics due to the small scale of the evaluation setup. source Android applications was measured. Our tool also provides better code smell/energy bug The ‘E-Debitum’ [15] tool (based on ‘SonarQube’) coverage, and usability compared to ‘PAPRIKA’ detected six energy code smells and calculated their tool. energy debt. Section 2 provides related work. Section 3 con- Comprehensive coverage of Android-specific code tains the tool design and implementation details. smells and energy bugs within one single tool is Section 4 presents the evaluation plan and results. missing in existing tools. In the tools mentioned Section 5 discusses threats to validity. Section 6 above, most commonly detected code smells were concludes the study. Member Ignoring Method, Internal Getter and Set- ter methods whereas most commonly detected en- ergy bugs were Wakelock Bug and Resource Leaks. 2. Related Work Existing tools have low usability due to lack of Android Studio IDE integration. Tools in studies There are several publications in which Android [9, 8, 13] provided a command line interface while application analysis tools have been presented that in the study [11] integration with Eclipse IDE was detect or correct Android-specific code smells and provided instead of Android Studio (which is the energy bugs. The aim of this study is to provide official IDE for Android development [7]). Tools a solution at the development stage hence we look compatible with Android Studio [14, 16], were not into only those tools that perform static analysis, open source. Tools in studies [9, 13, 12, 11, 16] with the aim to optimize applications in terms of did not refactor applications while tools in studies their energy consumption. [8, 15] provided completely automated refactoring The ‘HOT-PEPPER’ toolkit [8] (based on ‘PA- hence reducing the control of the developer during PRIKA’ tool [9]) detected and refactored a set of refactoring process. Android-specific code smells and produced a cor- rected version of the APK without developer inter- vention. 3. Design ‘Statedroid’ tool [10] performed a taint-like anal- ysis using specified resource protocols to detect en- In this section, we describe how we selected the ergy leaks caused by Wakelock Bugs and Resource baseline tool for extension and how we enhanced it. Leaks. In [11], the authors used a combination of ‘Eclipse 3.1. Baseline Tool Selection Refactoring API’, ‘PMD’, and ‘AL’ to build a tool that optimizes Android applications for CPU usage. The aim of this study is to create a tool that cov- Their rule set covered only a limited number of ers the limitations of previously developed tools in Android code smells. However, the tool offered terms of providing a comprehensive coverage of the developers the flexibility to add their own rules. Android code smells and energy bugs and solving The ‘aDOCTOR’ tool [12] detected 15 code smells the usability issues such as IDE integration, flex- causing energy drains by traversing the abstract ibility and ease of use for developer, open source syntax tree. The code smells were removed manually availability etc. Based on this objective, we set the by authors and correlated to energy consumption. following criteria for selecting a tool for an exten- Energy estimation was done using ‘PETrA’. The sion: ‘aDOCTOR’ tool has a precision and recall of 98%. • The tool should be open source or provide Jiang et al.[13] used ‘SAAF’ for resource leak anal- the ability to extend or customize it to add ysis and ‘AL’ for layout defect analysis in Android 72 8th International Workshop on Quantitative Approaches to Software Quality (QuASoQ 2020) rules for detection and refactoring of code Table 1 smells/energy bugs. Comparison of tools in terms of selection criteria • The tool should be able to perform static Criteria AL PMD SB SL SQ ST analysis. Open Source ✓ ✓ ✓ ✓ ✓ ✓ • The tool should be integrate-able with An- Customization API ✓ ✓ X ✓ ✓ X droid studio IDE as it is the official IDE for Source Code Analysis ✓ ✓ X ✓ X X Android development [7]. Byte Code Analysis ✓ X ✓ X ✓ ✓ • The tool should provide an inline warning Android Studio Integration ✓ ✓ ✓ ✓ ✓ X Inline issue warning/hint ✓ X X ✓ ✓ X on code smell/energy bug detection inside List of detected code smells/energy bugs Android Studio code editor. ✓ ✓ ✓ ✓ ✓ ✓ Allows adding refactoring rules ✓ X X X X X • The tool should provide a mechanism to list AL = Android Lint, SB = SpotBugs,SL= SonarLint, SQ = SonarQube, ST= SOOT detected code smells/energy bugs along with their description. The above criteria were applied on industry- not find any evidence in the literature about the standard tools such as ‘AL1 ’ (AL), ‘PMD’, ‘Spot- energy impact of the issues already covered by the Bugs2 ’ (SB), ‘SonarLint3 ’ (SL), ‘SonarQube4 ’ (SQ), above shortlisted tools, therefore, we only compared and ‘SOOT5 ’ (ST) (see Table 1). A similar tool, them for the coverage of 25 Android-specific code ‘FindBugs’, was not considered as its successor is smells and nine energy bugs listed in [1]. ‘SpotBugs’. ‘Eclipse refactoring engine’ was also ex- In Tables 2 and 3, ‘*’ represents that the code cluded as it is not integratable with Android Studio. smell/energy bug is detected but based on the defi- Tools that perform static analysis but focus on code nition of code smell/energy bug8 the detection cov- styling such as ‘CheckStyle’ were excluded. We also erage has room for improvement. ✓represents that considered detection and optimization tools identi- code smell/energy bug is detected, × represents that fied in our previous work [1]. Even though many of code smell/energy bug is not covered by the tool yet. these tools were built on top of open-source static From Tables 2 and 3, we can see that ‘AL’ already analysis tools such as ‘SOOT’, ‘SPARK’, ’SAAF’, covers 13 code smells and six energy bugs. There- ‘ASM’, ‘PMD’, and ‘Lint’, we did not select them fore, an effort towards improvement in the small for an extension because they were not designed to number of undetected code smells/energy bugs will be integrated with Android Studio IDE. The tools result in a single tool with maximum coverage. In using dynamic analysis were also excluded as they addition, ‘AL’ provides offline documentation for require the application to be built every time. Long rules and allows the developer to choose whether average build time for Android applications is a to correct a specific code smell/energy bug or not. known and significant issue among the development Based on the above data, ‘AL’ is a feasible tool for community6 . Table 1 shows a comparison of tools an extension. in terms of selection criteria. After this compar- ison, ‘SpotBugs’, ‘SonarQube’, and ‘SOOT’ were 3.2. Android Lint Extension excluded as they built the application every time a In this section, we explain the ‘AL’ API and im- code smell/energy bug needs to be detected. plementation details of our new ’extended Android Next, we compared the three shortlisted tools: Lint’ (xAL) tool. ‘AL’, ‘PMD’, and ‘SL’ for Android-specific code API Overview. ‘AL’ provides an embedding API smell and energy bug coverage (See Table 2 and that allows adding custom rules. In order to cre- 3). ‘AL’, ‘PMD’, and ‘SonarLint’ can cover many ate custom rules, the ‘AL’ embedding API pro- different types of issues in code (code smell, bug or error is referred to as ‘issue’ in these tools). For 8 https://figshare.com/s/84ae49a21551e6302d41 example, ‘AL’ can detect 261 different types of Android-specific issues7 . Majority of these issues are related to syntax and styling of the code. We could 1 http://tools.android.com/tips/lint-custom-rules 2 https://spotbugs.github.io/ 3 https://www.sonarlint.org/features/ 4 https://docs.sonarqube.org/latest/extend 5 https://github.com/Sable/soot/ 6 https://developer.android.com/studio/build/optimize- your-build Figure 1: Overview of ‘AL’ API 7 http://tools.android.com/lint/overview 73 8th International Workshop on Quantitative Approaches to Software Quality (QuASoQ 2020) Table 2 Code smell coverage by tools ‘AL’, ‘PMD’ and ‘SL’ DTWC DR LIC IDFP ISQLQ IDS IGS LT MIM NLMR PD RAM SL UC LC LWS UHA BFU UIO IWR HAT HSS HBR IOD ERB AL X ✓ ✓ ✓ ✓ ✓ ✓ * ✓ X X ✓ ✓ ✓ X ✓ X * ✓ X X X X ✓ * PMD X X X X ✓ X ✓ * X X X X ✓ ✓ X X X X X X X X X X * SL X ✓ X X ✓ X ✓ * ✓ X ✓ X ✓ ✓ X ✓ X X X X X X ✓ X ✓ DTWC=Data Transmission Without Compression, DR=Debuggable Release, LIC=Leaking Inner Class, IDFP=Inefficient Data Format and Parser, ISQLQ=Inefficient SQL Query, IDS=Inefficient Data Structure, IGS=Internal Getter and Setter, , LT=Leaking Thread, MIM=Member Ignoring Method, NLMR=No Low Memory Resolver, PD=Public Data, RAM=Rigid Alarm Manager, SL=Slow Loop, UC=Unclosed Closeable, LC=Lifetime Containment, LWS= Long Wait State, UHA=Unsupported Hardware Acceleration, BFU= Bitmap Format Usage, UIO=UI Overdraw, IWR=Invalidate Without Rect, HAT=Heavy AsyncTask, HSS=Heavy Service Start, HBR=Heavy Broadcast Receiver, IOD=Init ONDraw, ERB=Early Resource Binding Table 3 Table 4 Energy bug coverage by tools ‘AL’, ‘PMD’ and ‘SL’ Android code smells and energy bugs implemented in ’xAL’ RL WB VBS IB TMV TDL NCD UL UP AL * ✓ X X ✓ ✓ ✓ ✓ ✓ Abbr. Implementation Detection Correction offered PMD * X X X X X X X X Code smells SL * X X X X X X X X DTWC novel yes No, just warning is shown RL=Resource Leak, WB=Wake-lock Bug, VBS=Vacuous Background Services, IB= Immortality Bug, LT improvement yes yes TMV=Too Many Views, TDL= Too Deep Layout, NCD=Not Using Compound Drawables, UL= Useless Leaf, UP=Useless Parent NLMR novel yes yes PD novel yes yes LC novel yes yes vides many class APIs. In the ‘AL’ API, each code UHA novel yes yes smell/energy bug has the following properties: Id, BFU improvement yes No, just warning is shown summary, explanation, category, severity, priority, IWR novel yes No and additional links9 . This information is shown HAT novel yes No, just warning is shown to the developer when a code smell/energy bug is detected. Each code smell/energy bug is registered HSS novel yes No, just warning is shown in an issue registry class and is detected by a de- HBR novel yes No, just warning is shown tector class. The functionalities of detector class ERB improvement yes No, just warning is shown used by our implementation are given in additional Energy Bugs material10 . Fig. 1 gives an overview of the ‘AL’ RL improvement yes yes API (version 26.5.2 is used for the implementation VBS novel yes yes of detectors). The complexity calculation for the IB novel yes yes code smells HAA, HSS and HBR are done using DTWC=Data Transmission Without Compression, LT=Leaking Thread, NLMR=No Low Memory Resolver, PD=Public Data, RAM=Rigid Alarm Manager, LC=Lifetime Containment, ‘Metrics Reloaded’ plugin for Android Studio11 . UHA=Unsupported Hardware Acceleration, BFU= Bitmap Format Usage, IWR=Invalidate With- out Rect, HAT=Heavy AsyncTask, HSS=Heavy Service Start, HBR=Heavy Broadcast Receiver, Inclusion of New Code Smells/Energy Bugs. For ERB=Early Resource Binding, RL=Resource Leak, VBS=Vacuous Background Services, IB= Im- mortality Bug all undetected and partially covered code smells/ energy bugs (see Table 2 and 3), detection and refac- toring rules are defined based on the definitions bugs. Table 5 shows Android code smells/energy provided in additional materials and Android devel- bugs that are partially covered by the original ‘AL’ opment best practice guides12 provided by Google. tool and the improvements we implemented in our Table 4 shows a list of Android code smells and new ’xAL’ tool for each of them. Pseudo-code for energy bugs that are implemented in our ’extended implemented code smells and energy bugs are given Android Lint’ (xAL) tool. In ’Implementation’ col- in additional material13 . For most of the detected umn ’novel’ refer to code smells/energy bugs that code smells/energy bugs we offer corrections. In are not already present in the ‘AL’ tool. ’Improve- cases where we do not provide corrections to the ment’ refers to code smells /energy bugs that are developer, a warning is issued. Each implemented partially covered by the ‘AL’ tool and can be im- code smell/energy bug is tested on sample classes proved by inclusion of additional APIs/conditions which contains possible variations in which a se- in our new ’xAL’ tool. The last column of Table 4 lected code smell/energy bug can be present in the shows whether a correction is suggested by ’xAL’ code. In addition, we provide a description for each for the detected Android code smells and energy of the detected code smell/energy bug, with the aim to help developers in refactoring. We made 9 http://tools.android.com/tips/lint-custom-rules our tool open-source 16 . The ’xAL’ tool is compiled 10 https://figshare.com/s/84ae49a21551e6302d41. 11 13 https://github.com/BasLeijdekkers/MetricsReloaded https://figshare.com/s/84ae49a21551e6302d41 12 16 https://developer.android.com/topic/performance https://figshare.com/s/63c5b3e957f390432edf 74 8th International Workshop on Quantitative Approaches to Software Quality (QuASoQ 2020) Table 5 Receiver (HBR), Heavy Start Service (HSS), Invali- Proposed improvements in the Android Code Smells and date without Rect (IWR), No Low Memory Resolver Energy bugs detection (NLMR) and Unused Hardware Acceleration (UHA) CS/ API/Class already detected by API/Class detected by ’xAL’ tool as im- and Resource Leak (RL). JAR file for Paprika was EB ‘AL’ tool provement downloaded from their open-source repository20 . LT Detects thread class leak only. Detection of classes like an- (CS) droid.os.Handler and java.lang.Runnable that can lead to a thread leak14 . BFU Detects bitmap duplication, cre- Detection of Bitmap using 4.2. Evaluation Results (CS) ation in onDraw() and usability Bitmap.create(params. . . )15 . issues. This section presents the results of testing the tool ERB (CS) Detects creation of objects dur- ing DrawAllocation which can Detection of heavy APIs (of type: Android .location, android.media, an- on open source projects and compares its coverage be performed by lazy initializa- droid.database, android.hardware) that with PAPRIKA tool. tion should be initialized in lazy fashion1. RL Detects resources such as IO, Detection of resources like Camera, Media (EB) JDBC, static fields, wifi man- Player etc. [? ] 4.2.1. Evaluation on Open Source Apps ager, StringBuffer etc. CS =Code Smell, EB =Energy Bug, LTLeaking Thread, BFU= Bitmap Format Usage, ERB=Early Resource Binding, RL=Resource Leak The tool was tested on the nine applications selected from the F-Droid repository. Table 6 shows the results of the evaluation on open source applications. as a Jar file. The Jar file is placed in the .an- It lists the application name against the code smells droid/lint folder of the Android Studio installation, detected in it, true positives (TP), false positives typically located in USER-HOME. Android Studio (FP), false negatives (FN), precision (P), recall (R), is restarted for new detectors to take effect. Ap- total corrections available (TCA) and total applied plications can be analyzed for Android code smells correction (TAC) . and energy bugs in two ways17 , i.e., in-line analysis Some of the code smells/energy bugs (such as and whole-application analysis. ’Early Resource Binding’ (ERB), ’Heavy Async Task’ (HAT) and ’Heavy Broadcast Receiver’ (HBR)) did not appear in any of the applications under test. 4. Evaluation In the case of application ‘Kolabnotes’ two false negatives were detected, i.e. two instances of code 4.1. Evaluation Plan smell ’Lifetime Containment’ (LC) code smell. A We evaluated the ’xAL’ tool in two steps. First, possible reason could be declarations of interfaces in we evaluated the tool on a selection of open source non-lifecycle classes, which were not included in the apps, then we compared the tool’s performance to LC code smell definition. In the case of application that of the ‘PAPRIKA’ tool. ‘Sound Recorder’ two false negatives were detected, Evaluation on Open Source Apps. The evaluation i.e. two instances of code smells ’No Low Mem- includes testing on nine real-world applications18 ory Resolver’ (NLMR). A possible reason could be chosen from the F-Droid19 repository. The appli- that the class used by this application is deprecated, cations were chosen if the source code was in Java hence not covered by the implementation of our and the number of line of code was less than 30,000 ’xAL’ tool. In the case of applications ‘Kolabnotes’ (for ease of manual verification). We checked that and ‘Camera Roll’ one false positive (i.e., one in- each application can be compiled and executed on stance of the ’Data Transmission without Compres- a device without errors. sion’ (DTWC) code smell) was detected for each ap- Comparison with ‘PAPRIKA’. We considered plication. In the case of application ‘Calorie Scope’ state of the art tools such as ‘PAPRIKA’, ‘aDOC- one false positive was detected, i.e., one instance of TOR’, ‘SAAD’, ‘Chimer’ and ‘AL’ (implementation ’Resource Leak (RL) for a camera instance energy by Goaër [14]) as possible comparison candidates. bug. In the case of application, ’CameraColorPicker’ ’Chimer’ and the ’AL’ tool presented in [14] were five false positives (i.e. Lifetime Containment (LC) not available in open source. We chose ‘PAPRIKA’ code smell (4 instances) and Resource Leak (RL) as it had the largest number of overlapping code energy bug (1 instance)) were detected. In the smells/energy bugs with our ’xAL’ tool. These case of application, ‘Privacy- Friendly Weather’ two are Heavy Async Task (HAT), Heavy Broadcast false positives (i.e. two instances of Lifetime Con- tainment (LC) code smell) were detected. In the 17 https://figshare.com/s/84ae49a21551e6302d41 (See case of code smell Lifetime Containment (LC), a Tool Walk-through) possible reason for false positive could be that it 18 https://figshare.com/s/84ae49a21551e6302d41 (See Ta- flags abstract classes as interfaces as well. In the ble 1) 19 20 https://f-droid.com https://github.com/GeoffreyHecht/paprika 75 8th International Workshop on Quantitative Approaches to Software Quality (QuASoQ 2020) Table 6 Heavy Start Service (HSS), Heavy Broadcast Re- Results of evaluation on open source app using ‘xAL’ tool ceiver (HBR). For these smells, no false positives Detection Results were detected. ‘PAPRIKA’ did not detect any in- ID App CS/EB Detected TP FP FN P R TCA TAC stance of the code smells/energy bugs Unused Hard- 1 Odyssey UHA, NLMR, HSS, LC, IWR 11 0 0 1 1 6 6 2 Kolabnotes UHA, BFU, LT, DTWC, 18 1 2 1 0.9 7 7 ware Acceleration (UHA), Resource Leak (RL) and IWR, NLMR 3 Calorie Scope LC, NLMR, RL, VBS 12 1 0 0.9 1 13 13 Invalidate without Rect (IWR), which could be seen 4 Camera Roll UHA, BFU, DTWC, IWR, LC, NLMR, PD 21 1 0 1 1 16 6 in ‘FN’ column. 5 Bipol Alarm UHA, HSS, DTWC, NLMR 4 0 0 1 1 4 4 Table 8 shows a comparison of the code smells de- 6 Sound Recorder UHA, PD 7 0 2 1 0.8 7 7 tected by both ’xAL’ and ‘PAPRIKA’. ✓represents 7 CameraColorPicker UHA, BFU, NLMR, IWR, 12 5 0 0.7 1 17 12 LC, RL that a code smell is detected in a test application, × 8 Privacy-Friendly Weather UHA, LT, LC, NLMR 13 2 0 0.9 1 15 13 represents that a code smell was not detected in a 9 Reminders UHA, DTWC, NLMR 5 0 0 1 1 5 5 test application and empty cells show that the code TOTAL 103 10 4 – – 90 73 CS = Code Smell, EB = Energy Bug, TP = True Positive, FP = False positive, FN = False Negative, P= smell was not present in a test application. Code Precision, R= Recall, TCA = Total Corrections Available, TAC= Total Applied Corrections smell Heavy Async Task (HAT) was not present in any of the test applications hence not detected case of code smell Data Transmission without Com- by ‘PAPRIKA’ and our ’xAL’ tool. ’xAL’ was able pression (DTWC), a possible reason could be that to detect almost all the code smell instances that the ’xAL’ tool does not track instances that were were detected by ‘PAPRIKA’ tool. However, two in- compressed in another class. In the case of energy stances of ’No Low Memory Resolver’ (NLMR) code bug Resource Leak (RL), a possible reason for false smells were missed in application ‘Sound Recorder’ positives could be that code smell/energy bug was (as they used a deprecated class API). The ’Heavy handled pro-actively by the developer. For exam- Broadcast Receiver’ (HBR) code smell was also ple, for Resource Leak (RL), if the camera instance missed by our tool as the value for an upper limit was closed proactively by the developer in a method of computational complexity is set to five in ‘PA- other than onStop(). In this case, check on onStop() PRIKA’ and ten (as per McConnel [17]) in our ’xAL’ method is no longer required. tool. Corrections were available for 66.3% of the de- ‘PAPRIKA’ detected seven instances of false neg- tected Android code smells and energy bug in- atives for the code smells: Unused Hardware Accel- stances, out of which 84% of corrections were ap- eration (UHA) (5 instances) and Invalidate with- plied. 16% corrections were not applied, which out Rect (IWR) (1 instance) and energy bug Re- include false positives and instances of Public Data source Leak (RL) (1 instance). As compared to (PD) code smell (correction of this code smell al- ‘PAPRIKA’, our tool was able to detect Invalidate tered the functionality of the application under test). without Rect (IWR) code smell and Resource Leak These numbers are dependent on the type of code (RL) energy bug in ‘CameraColorPicker’ test appli- smell/energy bug and the frequency of its instances cation. Unused Hardware Acceleration (UHA) code in the application. smell was also detected in all five applications by our tool. Table 9 shows a compatibility comparison between ‘PAPRIKA’ and ’xAL’ to gain a better 4.2.2. Comparison with PAPRIKA understanding of the support offered by both tools The ‘PAPRIKA’ tool did not work on applications as well as their limitations. 1 to 4 that had AndroidX21 dependencies. Due The average precision, recall and F1-score for our to this inherent limitation of ‘PAPRIKA’, it was ’xAL’ were 0.93, 0.96 and 0.94, respectively. The av- only tested on applications 5 to 9. Refactoring of erage precision, recall and F1-score for ‘PAPRIKA’ code smells/energy bugs was not applied in any test were 1.0, 0.74 and 0.85, respectively. Hence, our application as the accessible version of ‘PAPRIKA’ ’xAL’ tool not only provides better Android code tool does not offer to refactor. smell/energy bug coverage but also improves upon Table 7 shows the results of the evaluation on the usability aspects of the tool in comparison to open source applications using ‘PAPRIKA’. It lists ‘PAPRIKA’ tool. the application name against the code smells de- tected in it, true positives (TP), false positives (FP), false negatives (FN), precision and recall. ‘PA- 5. Threats to Validity PRIKA’ was able to detect three types of code Our ’xAL’ tool only performs static source code smells namely: No Low Memory Resolver (NLMR), analysis of Android applications. Since static source 21 code analysis could be done during development re- https://developer.android.com/jetpack/androidx 76 8th International Workshop on Quantitative Approaches to Software Quality (QuASoQ 2020) Table 7 example, correction for Public Directory (PD) code Results of evaluation on open source apps using ‘PA- smell changes public directory to a private directory. PRIKA’ However, for an application that requires access to ID Test App CS/EB detected TP FP FN Precision Recall a public directory like Gallery, if it is changed to a 5 Bipol Alarm NLMR, HSS 2 0 1 1 0.67 private directory, the functional requirement will be 6 Sound Recorder NLMR 2 0 3 1 0.67 7 CameraColor Picker NLMR 6 0 1 1 0.67 in contradiction. But as the corrections can only be 8 PrivacyFriendly Weather NLMR 11 0 1 1 0.92 applied after the developer’s consent, such issues are 9 Reminders NLMR, HBR 4 0 1 1 0.8 less likely to occur. Correction/recommendations TOTAL 25 0 7 – – are offered for 66% of detected code smells/energy CS = Code Smell, EB = Energy Bug, TP = True Positive, FP = False positive, FN = False Negative, NLMR=No Low Memory Resolver, SS=Heavy Service Start, HBR=Heavy Broadcast Receiver bugs. For the rest of 34% code smells/energy bugs, only a warning is shown with hints for correction Table 8 (cf section 3.2.2). The decision of applying the sug- Code smell detection comparison between ‘PAPRIKA’ gested correction is left for the developers. Our tool and ’xAL’ does not cover third-party libraries used in Android App Bipol Sound CameraColor PrivacyFriendly Reminders applications. During development, we tested our Alarm Recorder Picker Weather tool against sample classes, which were injected CS P xAL P xAL P xAL P xAL P xAL with code smells/energy bugs by the authors of this HAT study. Hence there might be researcher bias in the HBR ✓ × HSS ✓ ✓ introduction of those code smells/energy bugs (in IWR × ✓ terms of coding style, location and variety), lead- NLMR ✓ ✓ ✓ × ✓ ✓ ✓ ✓ ✓ ✓ ing to higher accuracy in results. To mitigate this UHA × ✓ × ✓ × ✓ × ✓ × ✓ threat, the tool was evaluated on nine open-source RL × ✓ applications that already contained some of the CS= Code smell P=’PAPRIKA’, xAL= ’extended Android Lint’, HAT=Heavy AsyncTask, HSS=Heavy Service Start, HBR=Heavy Broadcast Receiver, IWR=Invalidate Without Rect, code smells and energy bugs. During the evalua- NLMR=No Low Memory Resolver, UHA=Unsupported Hardware Acceleration, RL=Resource Leak tion, we did not physically measure the changes in energy consumption of the applications under Table 9 test due to refactoring of code smells/energy bugs. Compatibility comparison between ’PAPRIKA’ and ’xAL’ The assumption that refactoring the selected code smells/energy bugs lead to energy optimization of Compatibility criteria PAPRIKA xAL Android applications is based on the related work Java version support Java 7 only versions >= Java7 such as [11, 14, 16]. Support for apps with Android X No Yes In-line warnings in Code Editor No Yes Navigation to LOC in Code Editor No Yes 6. Conclusion Individual code smell analysis No Yes Disabling detection of CS/EB No Yes We extended the tool ‘AL’ to detect and correct LOC=Line of code, CS/EB=CodeSmell/EnergyBug, xAL=’extended Android Lint’ Android-specific code smells and energy bugs that may lead to energy optimization in Android appli- cations. On top of the 261 issues already covered by peatedly, the support provided by our tool could ‘AL’, our extended tool ’xAL’ provides coverage for benefit developers. Implementation of a function- 12 Android-specific code smells (nine new and three ality may vary based an application’s architec- improved) and three energy bugs (two new and one ture/design and the coding style of a developer. improved). Moreover, ’xAL’ integrates directly in Hence, our definitions of code smells/energy bugs Android Studio IDE and gives control to the devel- might not cover every scenario related to a particu- oper for refactoring code smell/energy bugs, which lar code smell, leading to false positives and false was missing in other state of the art tools. We negatives in the results. For example, we only con- evaluated ’xAL’ on nine open-source applications; it sider lifecycle classes, i.e. Activity and Fragment detects code smells and energy bugs with an average for lifecycle dependent issues like Resource Leak precision, average recall and F1 score of 0.93, 0.96, and Leaking Thread. However, depending on the and 0.94 respectively. It accurately corrects 84% application architecture, lifecycle dependent compo- of selected code smells and energy bugs. Our tool nents might be called in non-lifecycle classes which offers better code smell and energy bug detection may go undetected. Moreover, some corrections coverage as compared to ‘PAPRIKA’. In the future, for code smells, and energy bugs might clash with we aim to evaluate ’xAL’ on a large data set of the functional requirements of the application. For applications, which will also help in analyzing the 77 8th International Workshop on Quantitative Approaches to Software Quality (QuASoQ 2020) correlation between the frequency of occurrences SANER (2017) 115–126. doi:10.1109/SANER. of code smells/energy bugs, and impact on energy 2017.7884614. consumption due to their refactoring. [9] G. Hecht, R. Rouvoy, N. Moha, L. Duchien, Detecting Antipatterns in Android Apps, 2nd ACM Int’l Conf. on Mobile Softw. Eng. and Acknowledgments Systems - MOBILESoft (2015) 148–149. doi:10. 1109/MobileSoft.2015.38. This work is supported by the Estonian Center of [10] Z. Xu, C. Wen, S. Qin, State-taint analysis for Excellence in ICT research (EXCITE), and group detecting resource bugs, Science of Computer grant PRG887 funded by the Estonian Research Programming (2018) 93–109. doi:10.1016/j. Council. scico.2017.06.010. [11] V. N. Huynh, M. Inuiguchi, B. Le, B. N. References Le, T. Denoeux, Improve the Performance of Mobile Applications Based on Code Opti- [1] I. Fatima, H. Anwar, D. Pfahl, U. Qamar, mization Techniques Using PMD and Android Tool Support for Green Android Development: Lint, LNCS (including subseries LNAI and A Systematic Mapping Study, in: 5th Int. LNB) 9978 LNAI (2016) V–VI. doi:10.1007/ Conf.on Softw. Technologies - ICSOFT, 2020, 978-3-319-49046-5. pp. 409–417. [12] F. Palomba, D. Di Nucci, A. Panichella, [2] A. Turner, How many people have A. Zaidman, A. De Lucia, Lightweight de- smarphones worldwide (Apr 2020), 2020. tection of Android-specific code smells: The URL: https://www.bankmycell.com/blog/ aDoctor project, SANER 2017 - 24th IEEE how-many-phones-are-in-the-world. Int’l Conf. on Softw. Analysis, Evolution, and [3] R. Verdecchia, R. Aparicio Saez, G. Procac- ReEng. (2017) 487–491. doi:10.1109/SANER. cianti, P. Lago, Empirical Evaluation of the En- 2017.7884659. ergy Impact of Refactoring Code Smells (2018) [13] H. Jiang, H. Yang, S. Qin, Z. Su, J. Zhang, 345–365. doi:10.29007/dz83. J. Yan, Detecting Energy Bugs in Android [4] H. Anwar, D. Pfahl, S. N. Srirama, Evaluating Apps Using Static Analysis, LNCS (including the Impact of Code Smell Refactoring on the subseries LNAI and LNB) 10610 LNCS (2017) Energy Consumption of Android Applications, 192–208. doi:10.1007/978-3-319-68690-5_ in: 45th Euromicro Conf.on Softw. Eng. and 12. Advanced Applications, SEAA, 2019, pp. 82– [14] O. L. Goaër, Enforcing green code with an- 86. doi:10.1109/SEAA.2019.00021. droid lint, in: 34th IEEE/ACM Int. Conf. on [5] A. V. Rodríguez, C. Mateos, A. Zunino, Automated Softw. Eng. Workshop - ASEW, M. Longo, An analysis of the effects of 2019. doi:10.1109/ASEW.2019.00018. bad smell-driven refactorings in mobile ap- [15] D. Maia, M. Couto, J. Saraiva, E-Debitum : plications on battery usage, in: Mod- Managing Softw. Energy Debt (2020) 162–169. ern Softw. Eng. Methodologies for Mobile [16] M. Couto, J. Saraiva, J. P. Fernandes, En- and Cloud Environments, 2016. doi:10.4018/ ergy Refactorings for Android in the Large 978-1-4666-9916-8.ch009. and in the Wild (2020) 217–228. doi:10.1109/ [6] C. Sahin, L. Pollock, J. Clause, How do code saner48275.2020.9054858. refactorings affect energy usage?, Int’l Sym- [17] S. McConnell, Code Complete: A Practical posium on Empirical Softw. Eng. and Mea- Handbook of Softw. Construction 9 (2011). surement - ESEM (2014) 1–10. doi:10.1145/ 2652524.2652538. [7] S. Habchi, R. Rouvoy, N. Moha, On the sur- vival of android code smells in the wild, Pro- ceedings - 2019 IEEE/ACM 6th Int’l Conf. on Mobile Softw. Eng. and Systems, MOBILESoft 2019 (2019) 87–98. doi:10.1109/MOBILESoft. 2019.00022. [8] A. Carette, M. A. A. Younes, G. Hecht, N. Moha, R. Rouvoy, Investigating the energy impact of Android smells, 24th IEEE Int’l Conf. on Softw. Analysis, Evolution, and ReEng. - 78