Context: While Android applications sufer 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'.
4) provide an interface consistent with the Android applications. They detected energy bugs like CamStudio 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 Anrent 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 Usrespectively. 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 ‘Auin 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 opentics 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
Setter methods whereas most commonly detected
energy 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 [
The ‘HOT-PEPPER’ toolkit [
Android-specific code smells and produced a corrected version of the APK without developer intervention. 3. Design
‘Statedroid’ tool [10] performed a taint-like analysis 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 covTheir rule set covered only a limited number of ers the limitations of previously developed tools in Android code smells. However, the tool ofered 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, flexcausing 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 extenEnergy estimation was done using ‘PETrA’. The sion: ‘aDOCTOR’ tool has a precision and recall of 98%.
Jiang et al.[13] used ‘SAAF’ for resource leak anal- • The tool should be open source or provide ysis and ‘AL’ for layout defect analysis in Android the ability to extend or customize it to add rules for detection and refactoring of code smells/energy bugs. • The tool should be able to perform static
analysis. • The tool should be integrate-able with Android studio IDE as it is the oficial IDE for
Android development [
Android Studio code editor. • The tool should provide a mechanism to list detected code smells/energy bugs along with their description. Criteria AL PMD SB SL SQ ST Open Source ✓ ✓ ✓ ✓ ✓ ✓ Customization API ✓ ✓ X ✓ ✓ X Source Code Analysis ✓ ✓ X ✓ X X Byte Code Analysis ✓ X ✓ X ✓ ✓ Android Studio Integration ✓ ✓ ✓ ✓ ✓ X Inline issue warning/hint ✓ X X ✓ ✓ X List of detected code smells/energy bugs ✓ ✓ ✓ ✓ ✓ ✓ Allows adding refactoring rules ✓ X X X X X
AL = Android Lint, SB = SpotBugs,SL= SonarLint, SQ = SonarQube, ST= SOOT
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 [
Next, we compared the three shortlisted tools: pLlienmt’e(nxtAatLio)ntodoelt.ails of our new ’extended Android ‘AL’, ‘PMD’, and ‘SL’ for Android-specific code smell and energy bug coverage (See Table 2 and API Overview. ‘AL’ provides an embedding API 3). ‘AL’, ‘PMD’, and ‘SonarLint’ can cover many that allows adding custom rules. In order to crediferent types of issues in code (code smell, bug ate custom rules, the ‘AL’ embedding API proor error is referred to as ‘issue’ in these tools). For example, ‘AL’ can detect 261 diferent types of 8https://figshare.com/s/84ae49a21551e6302d41 Android-specific issues 7. Majority of these issues are related to syntax and styling of the code. We could 1http://tools.android.com/tips/lint-custom-rules 2https://spotbugs.github.io/ 3https://www.sonarlint.org/features/ 4https://docs.sonarqube.org/latest/extend 5https://github.com/Sable/soot/ 6https://developer.android.com/studio/build/optimizeyour-build 7http://tools.android.com/lint/overview vides many class APIs. In the ‘AL’ API, each code smell/energy bug has the following properties: Id, summary, explanation, category, severity, priority, and additional links9. This information is shown to the developer when a code smell/energy bug is detected. Each code smell/energy bug is registered in an issue registry class and is detected by a detector class. The functionalities of detector class used by our implementation are given in additional material10. Fig. 1 gives an overview of the ‘AL’ API (version 26.5.2 is used for the implementation of detectors). The complexity calculation for the code smells HAA, HSS and HBR are done using ‘Metrics Reloaded’ plugin for Android Studio11.
Inclusion of New Code Smells/Energy Bugs. For all undetected and partially covered code smells/ energy bugs (see Table 2 and 3), detection and refactoring 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 ofer 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 sein 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 our tool open-source 16. The ’xAL’ tool is compiled 9http://tools.android.com/tips/lint-custom-rules 10https://figshare.com/s/84ae49a21551e6302d41. 11https://github.com/BasLeijdekkers/MetricsReloaded 12https://developer.android.com/topic/performance 13https://figshare.com/s/84ae49a21551e6302d41 16https://figshare.com/s/63c5b3e957f390432edf CS/ API/Class already detected by API/Class detected by ’xAL’ tool as imEB ‘AL’ tool provement 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 (CS) ation in onDraw() and usability Bitmap.create(params. . . )15.
issues.
ERB Detects creation of objects dur- Detection of heavy APIs (of type: (CS) ing DrawAllocation which can Android .location, android.media, anbe performed by lazy initializa- droid.database, android.hardware) that 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. [? ]
ager, StringBufer etc.
CS =Code Smell, EB =Energy Bug, LTLeaking Thread, BFU= Bitmap Format Usage, ERB=Early Resource Binding, RL=Resource Leak 4.2. Evaluation Results
4.2.1. Evaluation on Open Source Apps 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 efect. 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 Memincludes 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 ineach application can be compiled and executed on stance of the ’Data Transmission without Compresa 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 ifve 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 Containment (LC) code smell) were detected. In the 17https://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 18https://figshare.com/s/84ae49a21551e6302d41 (See Ta- flags abstract classes as interfaces as well. In the ble 1) 19https://f-droid.com 20https://github.com/GeofreyHecht/paprika Table 6 Heavy Start Service (HSS), Heavy Broadcast ReResults 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 inID App CS/EB Detected TP FP FN P R TCA TAC stance of the code smells/energy bugs Unused Hard213 CKOaodllyoasrbsineeoyStceospe ILUUWCHH,RAAN,,,NLNMLBLMMFRU,RR,R,LHL,STVS,,BLSDCT,IWWCR, 111812 101 020 0.911 0.911 1673 1367 wInavraeliAdactceelweriathtioount (RUeHctA()I,WRRes)o, uwrhceichLecaokul(dRbLe) saenedn 54 CBaipmoelrAalaRromll UUNHHLMAA,,RHB,FSPSUD,,DDTTWWCC,, NIWLMR,RLC, 214 10 00 11 11 146 46 in T‘FaNbl’ec8olsuhmowns. a comparison of the code smells de6 Sound Recorder UHA, PD 7 0 2 1 0.8 7 7 tected by both ’xAL’ and ‘PAPRIKA’. ✓represents 7 CameraColorPicker LUCH,AR,LBFU, NLMR, IWR, 12 5 0 0.7 1 17 12 that a code smell is detected in a test application, × 8 WPreivaathcyer-Friendly 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 CS = Code Smell, EB = TEOneTrgAyLBug, TP = True Positive, F1P03= Fa1ls0e posi4tive,–FN =–False N9e0gative,7P3= 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 incompressed 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 ‘PAother 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 negtected Android code smells and energy bug in- atives for the code smells: Unused Hardware Accelstances, out of which 84% of corrections were ap- eration (UHA) (5 instances) and Invalidate withplied. 16% corrections were not applied, which out Rect (IWR) (1 instance) and energy bug Reinclude 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 applismell/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 ofered 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 avonly 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 ofer 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 detected 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 code analysis could be done during development re21https://developer.android.com/jetpack/androidx
Android-specific code smells and energy bugs that may lead to energy optimization in Android applications. 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 develmight 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 ofers 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