=Paper=
{{Paper
|id=Vol-2767/paper10
|storemode=property
|title=Detection and Correction of Android-specific Code Smells and Energy Bugs: An Android Lint Extension
|pdfUrl=https://ceur-ws.org/Vol-2767/09-QuASoQ-2020.pdf
|volume=Vol-2767
|authors=Iffat Fatima,Hina Anwar,Dietmar Pfahl,Usman Qamar
|dblpUrl=https://dblp.org/rec/conf/apsec/FatimaAPQ20
}}
==Detection and Correction of Android-specific Code Smells and Energy Bugs: An Android Lint Extension==
https://ceur-ws.org/Vol-2767/09-QuASoQ-2020.pdf
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