Tool Support for Green Android Development: A Systematic Mapping

Study

Iffat Fatima

, Hina Anwar

, Dietmar Pfahl

and Usman Qamar

College of Electrical and Mechanical Engineering, National University of Sciences and Technology, Islamabad, Pakistan

Institute of Computer Science, University of Tartu, Tartu, Estonia

Keywords:

Android Development, Code Refactoring, Energy Efﬁcient, Green Software Engineering, Mapping Study.

Abstract:

In order to make mobile apps energy efﬁcient, we must ﬁnd ways to support energy efﬁcient app development.

While there is a lack of support tools that aid practitioners in moving towards green Android development. Our

goal is to establish the state of the art with respect to support tools that aid green Android development and to

identify opportunities for further research. To achieve this goal, we conduct a systematic mapping study. After

applying inclusion, exclusion and quality criteria we selected 21 studies for further analysis. Current support

tools to aid green Android development were classiﬁed into three categories: Proﬁler, Detector and Optimizer.

Most Proﬁler tools provide a graphical representation of energy consumed over time at various levels. Most

Detector tools provide a list of energy bugs/code smells to be manually corrected by a developer for the

improvement of energy. Most Optimizer tools automatically generate refactored version(s) of APK/SC. The

most typical technique used by Detector and Optimizer tools is static source code analysis using a predeﬁned

set of rules. Proﬁler tools use a wide range of techniques to measure energy consumption. However, these

tools have limitations in terms of code smell/energy bug coverage, accuracy, and usability.

1 INTRODUCTION

With the growing awareness of global warming and

its causes related to human activities (Powell, 2019),

the information and communication technology (ICT)

as well as software engineering (SE) research com-

munities show growing interest in green software de-

velopment. Software systems have such a signiﬁcant

impact on our everyday lives that changes towards en-

vironmental sustainability can ripple to other systems

with which they interact and positively affect the in-

dustries in which they are used (Anwar and Pfahl,

2017). It was reported that the use of ICT can elimi-

nate 12.1 billion tons of CO

emissions per sector per

year till 2030 (GeSI, 2015). While these estimates

are promising, the current ICT and software develop-

ment practices are causing harm to the environment.

There is ample research on making the hardware en-

ergy efﬁcient but research on making energy efﬁcient

software is still emerging. With emerging technolog-

ical trends such as internet of things (IoT), the impor-

tance of portable devices like smartphones is imper-

ative. There were over 1.9 billion smartphones sold

in 2018 alone (Gartner, Inc., 2018b) and the numbers

are increasing every year. According to an online sur-

vey users spend most of their digital media time on

smartphones using mobile apps(Mindsea, 2019). In

the smartphone market, Android has the biggest mar-

ket share globally, i.e., 87.8% (Gartner, Inc., 2018a).

Portable devices like smartphones have limited hard-

ware resources such as battery and memory. There-

fore, Android apps need to be developed with energy

efﬁciency in mind. In this paper, we use the term

green Android development for research that is in-

tended to help developers design and implement en-

ergy efﬁcient Android apps. Recent studies focus on

novel energy proﬁling/enhancement tools and meth-

ods in mobile apps (Ardito et al., 2013; Banerjee

and Roychoudhury, 2016; Chung et al., 2011; Fer-

nandes et al., 2014; Kansal and Zhao, 2008; Pathak

et al., 2012). However, there is still a lack of informa-

tion, support infrastructure and tools for developers to

make energy efﬁcient applications (Anwar and Pfahl,

2017; Manotas et al., 2016). To better understand

what is available and what is lacking with regards

to support tools, we conducted a systematic mapping

study. Our results indicate that there are many differ-

ent support tools developed to help aid developers at

various levels, however, they are not open source and

require advance knowledge related to energy related

Fatima, I., Anwar, H., Pfahl, D. and Qamar, U.

Tool Support for Green Android Development: A Systematic Mapping Study.

DOI: 10.5220/0009770304090417

In Proceedings of the 15th International Conference on Software Technologies (ICSOFT 2020), pages 409-417

ISBN: 978-989-758-443-5

409

issues in Android apps. There is a need to develop

a consolidated support tool that covers all the energy

related issues and is simpler to integrate with current

integrated development environments (IDEs).

2 RELATED WORK

Secondary studies related to tool support for improv-

ing energy efﬁciency in Android development are

scarce. Some secondary studies (Fontana et al., 2011;

Kaur and Dhiman, 2019; Singh and Kaur, 2018) re-

viewed tools and techniques for improving the quality

of Java projects in the object-oriented paradigm (with

regards to performance or maintainability). Most An-

droid projects use Java as the programing language,

however, the support tools and techniques used for

Java projects reviewed by previous secondary studies

(Fontana et al., 2011; Kaur and Dhiman, 2019; Singh

and Kaur, 2018) cannot be effectively applied to An-

droid projects. Therefore, many specialized support

tools have been developed to improve the quality of

Android apps with regard to maintainability, perfor-

mance, security or energy. Li et al. (Li et al., 2017)

performed a systematic literature review to analyze

static source code analysis techniques and tools pro-

posed for Android to assess issues related to security,

performance or energy. The authors reviewed work

published between 2011 and 2015 consisting of 124

studies. The review concluded that the majority of

static analysis techniques only uncover security ﬂaws

in Android apps. Degu (Degu, 2019) performed a sys-

tematic literature review to classify primary studies

with a focus on resource usage, energy consumption,

and performance in Android apps. The author has re-

viewed work published between 2012 and 2017. The

results did not provide an in depth review of support

tools in green Android development. None of the pre-

vious secondary studies has reviewed the literature

from the point of view of support tools developed

to aid green Android development. Most secondary

studies discussed above have covered published work

until 2015 and many of the reviewed tools in those

studies are now outdated/obsolete. Therefore, in this

paper, we provide a different view of literature by an-

alyzing recently developed support tools for energy

proﬁling, code optimization and refactoring in An-

droid development to improve energy efﬁciency.

3 RESEARCH METHODOLOGY

In order to be able to develop better support tools we

need to understand what is already available, what is

still needed, and how the problems in existing tools

could be overcome. Following the method described

in (Petersen et al., 2008) we formulated research

questions, then based on those research questions we

formulated a general search query and conducted the

search in the following online repositories for primary

studies: IEEE Xplore, ACM digital library, Science

Direct, and Springer. In this paper, we cover stud-

ies from 2014 to June 2019, as from 2014 onwards

the focus of many studies has been Android and en-

ergy efﬁcient app development, indicating a shift in

research focus.

3.1 Research Questions

We formulated the following research question with

three sub-questions.

RQ1: What state of the art support tools have been

developed to aid software practitioners in developing

energy efﬁcient Android apps?

RQ1.1: How do existing support tools compare to one

another in terms of the support they offer to practi-

tioners for improving energy efﬁciency?

RQ1.2: How do existing support tools compare to one

another in terms of techniques they use for offering

the support?

RQ1.3: What are the limitations of existing support

tools developed to help aid software practitioners in

developing energy efﬁcient Android apps?

3.2 Search Query

We derived search terms from the research goals and

research questions. We looked for alternatives and

synonyms of the search terms in studies we already

knew and reﬁned our search terms to return the most

relevant studies. We used the * operator to cover pos-

sible variations of the selected search terms in the

search query. Keyword OR was used to improve

search coverage. The AND NOT keyword was used

to eliminate papers that do not fall into the scope of

this study e.g. environmental, education and hard-

ware related papers that discuss energy efﬁciency so-

lutions. We did not use the search terms ’mobile

development’, ’apps’, ’sustainability’, ’green’, ’op-

timization’, ’recommendation’, and ’energy’ as they

were too high level and produced a larger corpus con-

sisting of higher number of irrelevant studies. The

search terms ’resource leak’, ’tool’, ’framework’, and

’technique’ were eliminated to avoid being too spe-

ciﬁc. The search query was applied to popular online

repositories (IEEE Xplore, ACM digital library, Sci-

ence Direct, and Springer). In each repository, based

on available advanced search options, ﬁlters were ap-

ICSOFT 2020 - 15th International Conference on Software Technologies

410

Table 1: Search query ﬁlter.

Sr. Filter Value

1 Publication year ≥ 2014

2 Content Format PDF

3 Content Type Journal Article, Conference Paper

4 Publication Area Software Engineering

plied to reﬁne the query results. Applied ﬁlters are

shown in Table 1. The search query was applied to

the titles, abstracts, and keywords of the papers.

Android develop* AND (energy efﬁci* OR energy

bugs OR code optimization OR code refactoring)

AND NOT (testing OR environment* OR edu* OR

hardware).

3.3 Screening of Papers

We removed duplicate papers and then deﬁned in-

clusion, exclusion, and quality criteria for further

screening of search results. The search results from

online repositories were ﬁrst loaded in Zotero

(an

open source reference management system) to cre-

ate a dataset of relevant studies. Using the feature

in Zotero duplicates studies were removed from the

dataset. Next, we manually applied inclusion, exclu-

sion (see Table 2) and quality criteria (see Table 3)

on the remaining papers. Abstracts of the papers and

structure of the paper were assessed for further qual-

ity assessment. A maximum quality score of 3 could

be assigned to a paper. If a paper was below a quality

score of 1.5 it was removed from the results.

3.4 Classiﬁcation and Data Extraction

To answer RQ1 and its sub-questions, we identiﬁed

the main keywords of the selected studies along with

the commonly used terms in the abstract to deﬁne

categories of support tools. Research methodology

and results of selected studies were additionally stud-

ied when needed. We kept extracted data in excel

spread sheets for further processing. During data ex-

traction, if there was a conﬂict of opinion it was dis-

cussed among authors of this paper until a consensus

was reached. To answer RQ1, a bottom-up merging

technique was adopted to build our own classiﬁcation

scheme (see Table 4). Once a classiﬁcation scheme

was established, we extracted data from each selected

study to identify its main contribution and assigned

the tool mentioned in the study to a category based on

the classiﬁcation scheme.

To answer RQ1.1, we extracted data form each se-

lected study to gather information about the kind of

support the identiﬁed tool offers based on the inputs

of the tool, outputs of the tool, recommendation(s)

https://www.zotero.org/

Table 2: Inclusion/Exclusion criteria.

Inclusion Exclusion

Primary studies should be related to

software engineering with a focus on

energy efﬁciency in Android apps.

A tool/automated technique for code

optimization and refactoring or en-

ergy proﬁling was presented for green

Android development.

We considered only conference and

journal articles for which full text was

available.

Studies focused on energy efﬁciency

with respect to hardware or environ-

mental issues or present secondary

data were excluded. The work pre-

sented in a thesis or book chapter is

usually published in relevant journals

or conferences as well. Therefore,

theses, magazine articles, book chap-

ters, work-in-progress papers, and pa-

pers that were not in English were

also excluded.

Table 3: Quality assessment criteria.

ID Description Rating

1 Does the paper clearly state contribution(s) that is di-

rectly related to improving energy efﬁciency in Android

apps?

2 Is the research method adequately explained? 1

3 Are threats to validity and future research directions

separately discussed?

TOTAL 3

Table 4: Categories of support tools.

ID Category Description

CP Proﬁler A software program that measures the energy consump-

tion of an Android app or parts of apps.

CD Detector A software program that only identiﬁes and detects en-

ergy bugs/code smells in an Android app.

CO Optimizer A software program that identiﬁes energy bugs/code

smells as well as refactor source code of an Android

app to improve energy consumption.

made by authors based on the output of the tool, code

smells/energy bugs and measurement covered by the

tool. In general, a code smell is deﬁned as a sur-

face indication that usually corresponds to a deeper

problem in the system (Fowler, 2002) and an energy

bug is deﬁned as error in the system (application, OS,

hardware, ﬁrmware, external conditions or combina-

tion) that causes an unexpected amount of high energy

consumption by the system as a whole (Pathak et al.,

2011). In the light of these deﬁnitions, we looked for

Android speciﬁc code smells and energy bugs in the

studies.

To answer RQ1.2, a classiﬁcation scheme was

needed to classify techniques used in support tools

for improving the energy efﬁciency of apps. We

used the bottom-up approach to build this classiﬁ-

cation scheme by combining the specialized analy-

sis methods/techniques into more generic higher-level

techniques. The identiﬁed generic techniques along

with their deﬁnitions are described in Table 5. Once

we had established the classiﬁcation scheme, we ex-

tracted data from the abstract and research methodol-

ogy of each selected study and assigned it to a cate-

gory deﬁned in the classiﬁcation scheme. To answer

RQ1.3, we studied the results, threats to validity and

conclusion of selected studies and summarized the

Tool Support for Green Android Development: A Systematic Mapping Study

411

limitation of support tools in each category.

4 RESULTS

4.1 Screening

As a result of running the search query and apply-

ing ﬁlters (see Table 1) on search results, 1462 stud-

ies were found from the selected online repositories.

These studies were loaded into the Zotero software

for the screening and removal of duplicates, the total

number of papers were reduced to 1377 after dupli-

cate removal. Inclusion and exclusion criteria were

applied to the remaining studies and the number was

reduced to 566. We read abstracts of these studies and

looked at the paper structure to assign them a qual-

ity score based on quality criteria. After applying the

quality criteria, the number of selected studies

was

reduced to 21. (See Tables 6, 7, and 8)

4.2 Classiﬁcation and Analysis

In this section, we present the result

for RQ1 and its

sub-questions RQ1.1 to RQ1.3.

RQ1: What state of the art support tools have been

developed to aid software practitioners in developing

energy efﬁcient Android apps?

To answer RQ1, the classiﬁcation scheme deﬁned in

Section 3.4 was adopted and the selected studies were

divided into categories: 1) Proﬁler, 2) Detector, 3)

Optimizer, based on the support tool they offer to

aid green Android development. Table 9 gives an

overview of the distribution of selected studies in each

category along with the total number of tools in each

category. Figure 1 shows the number of publications

each year. The color in bars indicates the number of

tools in each category each year. From 2014 to 2017

we can see a decrease in the number of Proﬁler tools

while an increase in the number of Optimizer tools.

At least one Detector tool has been published every

year from 2014 to 2018. In 2019 (till June), no new

support tool has been published.

RQ1.1: How do existing support tools compare to one

another in terms of the support they offer to practi-

tioners for improving energy efﬁciency?

To answer RQ1.1, we provide a list of all the tools

identiﬁed in each category. In Table 10

the column

input provides information about what is the input for

each tool. The column output provides information

about the support the tool offers based on the input.

For additional information, e.g., list of selected studies, additional tables

and ﬁgures, see URL: https://ﬁgshare.com/s/7e78f2469727c31d2957

Figure 1: Number of publications per year per category.

Studies in the category Proﬁler offer support to the

practitioners by providing tools that can measure the

energy consumed by whole/parts of an app or device

sensors used in the apps. The measured information is

usually presented to practitioners as graphs for energy

consumption over time. Studies in the Proﬁler cate-

gory do not recommend when, where and how prac-

titioners can use the information from these graphs

during development to improve the energy consump-

tion of their apps. Studies in the category Detec-

tor offer support to practitioners by developing tools

that present as output lists of energy bugs/code smells

causing a change in energy consumption of apps. In

some studies, authors further discuss how the output

produced from their tool could be used to improve the

energy consumption of apps. We present this infor-

mation in Table 11 as a list of recommendations pro-

vided by those studies in the Detector category along

with a reference to the selected study. We deﬁne rec-

ommendation as; a ﬁx for an energy bug/code smell

that can be applied in a ﬁnite number of steps/actions

in a speciﬁc context.

Studies in the category Optimizer offer support to

practitioners by developing tools that present as out-

put refactored source code of apps optimized for en-

ergy. The studies in this category do not explicitly

give the recommendation to the developers about how

to optimize the source code for energy efﬁciency as

the tools automatically refactor the code.

RQ1.2: How do existing support tools compare to one

another in terms of techniques they use for offering

the support?

To answer RQ1.2 we discuss in detail techniques used

in each tool for improving the energy efﬁciency of

apps. Table 12 gives an overview of tools and tech-

niques along with the reference to selected studies.

We observed that no tool in any category used a com-

bination of techniques. Each tool could be easily clas-

siﬁed into exactly one category of techniques (deﬁned

in Section 3.4).

Proﬁler. Proﬁling tools measure the energy con-

sumption of the software and the used hardware re-

ICSOFT 2020 - 15th International Conference on Software Technologies

412

Table 5: Categories of techniques used for providing support to aid green Android development.

ID Technique Deﬁnition

T1 Byte code manipu-

lation

A technique that injects code in the Smali ﬁles of the app under test. The injected code is either a log statement or an energy evaluation function.

These statements help ﬁnd out the part of the source code that consumes a speciﬁc amount of energy at runtime.

T2 Code Instrumenta-

tion

A technique that instruments the app, using instrumented test cases that are capable of running speciﬁc parts of the app, in such a way that it is

run in a speciﬁc environment while calling known methods/classes of the app under test. It uses ﬁnite state machines and device speciﬁc power

consumption details to measure energy consumption.

T3 Logcat Analysis A technique that uses system level log ﬁles to obtain energy consumption information provided by OS for the app under test. These logs are

compared with application level logs to give graphical information about the energy consumption of the app.

T4 Static Source code

Analysis

A technique that uses the source code of the app and analyses it using one or combination of the following methods: control ﬂow graphs

analysis, point-to-analysis, inter-procedural, intra-procedural, component call analysis, abstract syntax tree traversal or taint analysis.

T5 Search-based algo-

rithms

A technique that uses a multi-objective search algorithm to ﬁnd multiple refactoring solutions and the most optimal solution is selected as ﬁnal

refactoring output by iteratively comparing the quality of design and energy usage.

T6 Dynamic Analysis A technique based on the identiﬁcation of information ﬂow between objects at run time for the detection of vulnerabilities in the app under test.

It monitors the spread of sensory data during different app states.

Table 6: Number of studies extracted per online repository.

Sr. Repo. # of papers Conference

Papers

Journal

Articles

1 IEEE Xplore 832 621 211

2 ACM Digital library 478 454 24

3 Springer 130 95 35

4 Science Direct 22 4 18

Table 7: Number of articles per screening step.

Sr. Step in the screening of papers # of papers

1 Search string results after applying ﬁlters 1462

2 Remove duplicates 1377

3 Apply inclusion and exclusion criteria 566

4 Apply quality criteria 21

Table 8: Quality score assigned to each selected study.

Study ID Quality Score

S3, S6, S15, S18, S13 2.5

S1, S2, S4, S5, S8, S9, S10, S16, S19 2

S11, S12, S14, S17, S20, S21, S7 1.5

Table 9: Distribution of studies in each category.

ID Selected Studies # Tools

CP S6, S14, S16, S12, S13, S20, S19 7

CD S1, S3, S4,S5, S8, S9,S7, S17 8

CO S10, S11, S15, S18 S2, S21 6

sources. Proﬁlers [S6, S16, and S14] were designed

to inject logging statements into the Smali ﬁles to

gather relevant log data. This data was then trans-

formed as needed and matched against pre-deﬁned

API names or method names to identify energy in-

tensive APIs and methods in the program. In these

proﬁlers, Dumpsys or System level logs or ADB data

plotted on a graph was used to measure energy us-

age. Another group of proﬁlers analyzed the paths in

source codes using ﬁnite state models (FSM) or inter

procedural control-ﬂow paths. The authors of [S19]

created a dynamic model that instrumented the app

to measure its power consumption. Methods were in-

voked using tests and were classiﬁed into three differ-

ent levels (classes, packages, and projects) based on

their energy consumption. The classiﬁcation was then

presented graphically. The authors of [S12] modeled

energy consumption as an FSM model by collecting

Table 10: List of support tools and their inputs and outputs.

Ct. Tool Input Output ID

Orka APK ECG S6

SEPIA AE ECG S12

Mantis PBC Program CRC predic-

tors

S13

CP AEP SL, PID

via ADB

ECG S14

E-Spector SL, AL

via ADB

ECG S16

SEMA PID,

MVC

Log of Energy con-

sumption

S20

Keong et. al SC ECG S19

Wu et al. SC List of energy bugs S1

Kim et al. PBC List of energy bugs S3

Statedroid APK List of energy bugs S5

CD PatBugs SC List of detected warn-

ings

SAAD APK List of energy bugs S9

aDoctor SC List of code smells S4

GreenDroid PBC,CF List of energy bugs +

severity level

S17

Paprika APK,

List of code smells S7

DelayDroid APK Refactored APK S2

HOT-PEPPER APK Most energy efﬁcient

APK, Refactored SC,

and List of refactoring

S10

CO Asyncdroid SC Refactored SC S11

EARMO APK Refactored APK S15

EnergyPatch APK Refactored APK S18

Nguyen et al. SC Refactored SC S21

Ct.=Category , SC=Source Code, APK=Android Package Kit,

PBC=Program Byte Code, SL= System Log ﬁles, AL= Application

Log ﬁles, PID= Process ID, ADB=Android Debug Bridge, CRC= Computa-

tional Resource Consumption, AE= Application Events, CF= conﬁguration

Files, MVC= Measurements of Voltage and Current, ECG= Energy

consumption graph, PM=PlayStore Metadata.

Table 11: Recommendation given by authors of studies in

’Detector’ category.

Category: Detector

ID Recommendation

S1 Energy bug (related to listener leaks) caused due to control ﬂow issues

in apps could be ﬁxed by adding and removing interface listeners and

correct handling of Android lifecycle callbacks.

Energy bugs (related to texture transfers, image and frame rending) in

graphic intensive apps could be ﬁxed in three ways:

S3 (1) Loop invariant graphic textures should be moved out of the loop.

(2) Group related images together for efﬁcient rendering.

(3) Identify identical frames to prevent redundant frame drawing.

Tool Support for Green Android Development: A Systematic Mapping Study

413

Table 12: Overview of support tools showing the technique

used for offering support to developers.

Techniques

Ct. Tool T1 T2 T3 T4 T5 T6 ID

Orka X S6

SEPIA X S12

Mantis X S13

CP AEP X S14

E-Spector X S16

SEMA X S20

Keong et. al X S19

Wu et al. X S1

Kim et al. X S3

Statedroid X S5

CD PatBugs X S8

SAAD X S9

GreenDroid X S17

Paprika X S7

aDoctor S4

DelayDroid X S2

HOT-PEPPER X S10

CO Asyncdroid X S11

EARMO X S15

EnergyPatch X S18

Nguyen et al. X S21

events from an Android device. By executing the in-

strumented unit tests the line of source code with the

energy consumption issue was identiﬁed. The authors

of [S13] sliced the program into executable slices for

generating feature predictors. Predictors were gener-

ated based on some predeﬁned metrics which quanti-

ﬁed energy consumption. The authors of [S20] mea-

sured energy consumption by encapsulating the code

blocks with energy evaluation functions. Sampling

collector extracted energy consumption and a runtime

manager extracted application information from OS.

Detector. The authors of [S17] used JPF to statically

analyze the state space of the app to ﬁnd the usage

of sensors and wake locks. The utilization of sen-

sory data was deﬁned by a coefﬁcient. The authors of

[S7] converted APK ﬁles into byte code using SOOT

which is a static source code analyzer. The converted

code was then used to identify and report various anti-

patterns in code. The authors of [S5] identiﬁed re-

source intensive items in an app using control-ﬂow

graphs (CFGs). Using resource protocols as a guide

a taint-like analysis was performed on CFGs. In the

study [S1] valid inter-procedural control-ﬂow paths

were analyzed in each callback method and its tran-

sitive callees, in order to detect energy draining op-

erations related to missing deactivation behaviors. In

the study [S3], a static analysis tool SOOT was used

to ﬁnd energy bugs in graphics intensive mobile apps

along with point-to analysis tool, SPARK. Energy

bugs were identiﬁed based on the frequency at which

GPU was being used to perform certain actions e.g.

texture transformations etc. The authors of [S8] used

ﬂexible bug pattern speciﬁcation notation (FBPSN)

to specify bug patterns. The source code was trans-

formed to CFGs which were used to detect bugs with

the help of FBPSN speciﬁed bug patterns. In the study

[S9] the APK ﬁles were analyzed using APKTool

and resource leak were analyzed using SAAF. Lint

was used for layout defect analysis. ’SAAF’ inter-

nally uses inter-procedural, intra-procedural and com-

ponent call analysis and resource leak detection. The

output from ’Lint’ was passed through a ﬁlter based

on a set of rules deﬁned in a defect table to generate

the report. The results of both these tools are used to

generate the respective reports. In the study [S4] an

abstract syntax tree of classes was traversed to apply

a set of detection rules based on a speciﬁc set of code

smells.

Optimizer. The authors of [S2] introduced the tool

DelayDroid which used static analysis and byte code

refactoring using ASM library to ﬁnd the parts of

code that performed energy intensive network related

tasks and batched them together to perform those

tasks at a delayed interval to reduce energy consump-

tion. The tool Hot-pepper was presented in [S10]

which detected energy smells using the Paprika tool

and computed the energy consumption of code smells

using the Naga-Viper tool. Corrections were made

using a tool called SPOON that used static analy-

sis for transformation. The authors of [S11] pre-

sented a tool developed on top of the Eclipse refac-

toring engine which converted AsyncTask to Intent-

Service in order to improve the asynchronous opera-

tions. In the study [S15] a novel tool EARMO was

presented which created code abstractions to search

for anti-patterns based on QMOOD metrics. To cor-

rect anti-patterns in the app, the ReCon tool was used.

In [S18] a framework was presented that had three

main components: Design extractor, refactoring com-

ponent and code generation component. Design and

defect expressions were generated from EFG using

deterministic ﬁnite automata. Their intersection was

Table 13: Android energy bugs detected by each tool in ’De-

tector’ and ’Optimizer’ categories.

Tool

VBS

TMV

TDL

NCD

Ref

Wu et al. X S1

GreenDroid X X S17

Kim et al. X S3

Statedroid X X X S5

PatBugs S8

SAAD X X X X X X S9

Paprika X X S7

aDoctor X X S4

DelayDroid X S2

HOT-

PEPPER

X X S10

Asyncdroid X S11

EARMO S15

EnergyPatch X X X X S18

Nguyen et al. S21

RL=Resource Leak, WB=Wake-lock Bug, VBS=Vacuous Background Services, IB=

Immortality Bug, TMV=Too Many Views, TDL= Too Deep Layout, NCD=Not Using

Compound Drawables, UL= Useless Leaf, UP=Useless Parent

ICSOFT 2020 - 15th International Conference on Software Technologies

414

Table 14: Android code smells detected by each tool in the ’Detector’ and ’Optimizer’ categories.

Tool

Ref

DTWC

IDFP

IDS

ISQLQ

IGS

LIC

MIM

NLMR

RAM

LWS

UHA

BFU

UIO

IWR

HAT

HSS

HBR

IOD

ERB

Wu et al. S1 X X X

Kim et al. S3 X

Statedroid S5 X X

PatBugs S8 X

SAAD S9

ADoctor S4 X X X X X X X X X X X X X X

Paprika S7 X X X X X X X X X X X X X

GreenDroid S17 X

DelayDroid S2

HOTPEPPER S10 X X X X X X X X X X X X X

AsyncDroid S11 X

EARMO S15 X X X

EnergyPatch S18 X

Nguyen et al. S21 X X

DTWC=Data Transmission Without Compression, DR=Debuggable Release, DW=Durable Wake-lock, IDFP=Inefﬁcient Data Format and Parser, IDS=Inefﬁcient Data

Structure, ISQLQ=Inefﬁcient SQL Query, IGS=Internal Getter and Setter, LIC=Leaking Inner Class, 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 Ser-

vice Start, HBR=Heavy Broadcast Receiver, IOD=Init ONDraw, ERB=Early Resource Binding

used to refactor the code. The authors of [S21] used

PMD and Android Lint to create an Eclipse plugin for

refactoring of source code. PMD created an Abstract

Source Tree (AST) to analyze code and apply the pre-

deﬁned rules. Table 13 lists Android energy bugs

that are covered by tools in the Detector and Opti-

mizer categories. Android energy bugs

TMV, TDL,

UL, UP are detected by 10% of the tools, whereas RL

is detected by 80% of tools, in the Detector category.

However, none of the tools in the Optimizer category

covers them. RL and VBS energy bugs are detected

by 30% and 50% of the tools in the Optimizer cat-

egory, respectively. Table 14 shows which Android

code smells

are covered by which individual tools

in Detector and Optimizer categories. Android code

smell

ERB is not detected by any tool in the Detector

category but 17% of tools in the Optimizer category

cover them. Android code smells such as LWS, LC,

RAM, PD, ISQLQ, IDFP, DR, and DTWC are de-

tected by 13-25% of the tools in Detectors category

but none of the tools in Optimizer category can iden-

tify these smells.

RQ1.3: What are the limitations of existing support

tools developed to help aid software practitioners in

developing energy efﬁcient Android apps?

Proﬁler. Tools included in this category had several

limitations. Energy measurements were less accurate

as compared to measurements taken with an external

device. The error rate was high. Limitations on what

could be proﬁled e.g. energy consumption of only

some parts of the app were proﬁled or only framework

or only app or only kernel level proﬁling was pro-

vided. The impact of techniques like code injections

and extensive logging came with an execution over-

head and might have affected the ﬁnal energy costs.

Resources used by software based proﬁler might not

be accounted for in the energy costs. Only a limited

number and formats of input were handled by these

proﬁlers. Model based energy proﬁling approaches

might ignore the run time information about apps.

Detector. Tools included in this category had sev-

eral limitations. As most of the tools in this category

were using static source code analysis techniques to

offer support, they might produce some false posi-

tives/negatives. Some of these tools used open source

static source code analyzer, which could affect their

results and accuracy. A limited number of Android

code smells/energy bugs were identiﬁed using each

tool and most of the tools did not cover multi-threaded

programs and multiple interacting objects.

Optimizer. Tools in this category had several limita-

tions. Refactored APK/SC generated by the tools did

not offer acceptable trade off in most cases with per-

formance, usability or other non-functional require-

ments. The refactoring done by tools needed manual

veriﬁcations. Only a limited number of Android code

smells/ energy bugs were automatically identiﬁed and

corrected by these tools. Manually applying the refac-

torings suggested by these tools required expertise in

programming and energy related issues. Many tools

in this category were also dependent on static source

code analysis techniques therefore, they might pro-

duce false positives/ negatives.

Tool Support for Green Android Development: A Systematic Mapping Study

415

5 DISCUSSION

Based on the results of RQ1 and its sub-question

RQ1.1 we observed that the selected studies focus

on a speciﬁc niche of code smells, energy bugs and

software metrics. There is a need for generic support

tools that can cover the functionalities of all three cat-

egories of tools discussed in the results section. From

the results of RQ1.2, the support tools in Proﬁler cate-

gory used many different techniques. The tools in De-

tector and Optimizer categories frequently used static

source code analysis technique, which might result in

producing false positive and false negatives. In all

categories, none of the tools use a combination of

techniques. Static source code analysis techniques

do not cover dynamic issues e.g. issues related to

Async. Therefore, hybrid techniques need to be used

for the development of new tools using a combina-

tion of static and dynamic analysis. For the devel-

opment of better support tools, the evaluation of the

tools on industrial projects should be increased. Most

of the current support tools were only evaluated us-

ing open source data sets and there are indications

(see related work) that industrial development is dif-

ferent. Therefore, the industry relevance of the sup-

port tools might not be obvious because they are not

evaluated in industrial settings. Software based met-

rics that affect energy consumption need to be clearly

identiﬁed and correlated to improve code smell detec-

tion. Results from studies that focus on correlating the

structure of source code to software metrics could be

used for this purpose. In addition, non-intrusive tech-

niques should be used to collect metrics. Based on

the results of RQ1.3, the current state of the art tools

could be extended into complete frameworks by com-

bining them with one another or combining them with

other industrially famous code analyzers like Android

Lint, Check Style, Find Bugs and PMD. The results

from the selected studies could be expanded to in-

clude cross project predictions and corrections for en-

ergy bugs. Analysis and inclusion of multi-threaded

programming approaches in the experiments could be

another direction for future researchers.

From the discussion, we list desired functionalities in

the new breed of support tools to aid green Android

development:

• Must be integratable with the Android Studio.

• Must have full coverage of Android speciﬁc en-

ergy bugs.

• Must be able to handle multi-threaded programs.

• Must be able to handle multi interacting objects.

• Must have an interface consistent with the An-

droid studio to increase usability.

• Must have elaborated help and documentation

available ofﬂine for every function and command.

• Must have complete coverage of object oriented

(such as all 22 Fowler) code smells

• Must have complete coverage of Android speciﬁc

code smell.

• Must have the capability of proﬁling energy con-

sumption of app at all levels such as method level,

class level, package level, and Kernel level.

• The energy level must be represented in graphs.

• Energy graphs must be linked to source code. I.e.

from graph user could be directed to the codes

causing a change in energy consumption.

• Must be able to handle both static and dynamic

analysis of source code.

• Must offer trade-offs with other non-functional re-

quirements in the form of recommendations.

• Must provide a preview of refactor-

ing/optimization choices on the code before

applying them.

6 THREATS TO VALIDITY

The search query and classiﬁcation of selected stud-

ies could be biased by the researchers knowledge. We

mitigated this threat by deﬁning the inclusion, exclu-

sion and quality criteria for the selection of the stud-

ies. Conﬂicting opinions were discussed among au-

thors of this paper until a consensus was reached. In

order to avoid false positive and false negatives in the

search results, we used the wildcard character (*) to

maximize coverage and the keyword AND NOT to

remove irrelevant studies. The results of the search

strings were manually checked and further reﬁned by

the authors. Online repositories continuously update

their databases to include new publication, therefore,

executing the same query might yield some additional

results that were not included in this study. We al-

ready knew about many relevant studies and we re-

captured almost 85% of them when we executed the

search query. On each online repository the search

mechanism is slightly different we tried to keep the

query as consistent as possible, but there might be

slight difference due to the difference in search mech-

anism provided by different online repositories. Some

selected studies use the terms code smells and energy

bugs interchangeably which could affect the classi-

ﬁcation. To mitigate this threat we used the selected

deﬁnitions (c.f section 3.4) for code smells and energy

bugs to correctly classify the studies in the right cat-

egory. We focused particularly on the support tools

ICSOFT 2020 - 15th International Conference on Software Technologies

416

for energy proﬁling, code optimization and refactor-

ing of code smells/energy bugs to help aid green An-

droid development. Other types of support tools, such

as tools for interface optimization, third-party library

detection etc., were not in the scope of this study. We

plan to cover such tools in future work.

7 CONCLUSION

To get an overview of the state of the art and to ﬁnd

research opportunities with respect to support tools

available for green Android development, we con-

ducted a mapping study. Based on our analysis the

current support tools were classiﬁed into three cate-

gories 1) Proﬁler, 2) Detector, 3) Optimizer. The main

ﬁndings of the paper are that most Proﬁler tools pro-

vide a graphical representation of energy consump-

tion over time. Most Detector tools provide a list

of energy bugs/code smells to be manually corrected

by a developer for the improvement of energy. Most

Optimizer automatically convert original APK/SC to

a refactored version(s) of APK/SC. The most typi-

cal technique in Detector and Optimizer category was

static source code analysis using a predeﬁned set of

code smells and rules.

ACKNOWLEDGEMENTS

This work is supported by the Estonian Center of Ex-

cellence in ICT research (EXCITE), the group grant

PRG887 funded by the Estonian Research Council.

REFERENCES

Anwar, H. and Pfahl, D. (2017). Towards greener software

engineering using software analytics: A systematic

mapping. In Proc. of the 43rd Euromicro Conf. on

Soft. Eng. and Advanced Applications. IEEE.

Ardito, L., Procaccianti, G., Torchiano, M., and Migliore,

G. (2013). Proﬁling power consumption on mobile

devices. In Proc. of the 3rd Int. Conf. on Smart Grids,

Green Communications and IT Energy-aware Tech.,

pages 101–106.

Banerjee, A. and Roychoudhury, A. (2016). Auto-

mated re-factoring of android apps to enhance energy-

efﬁciency. In Proc. of the Int. Workshop on Mobile

Soft. Eng. and Sys. ACM Press.

Chung, Y.-F., Lin, C.-Y., and King, C.-T. (2011). ANE-

PROF: Energy proﬁling for android java virtual ma-

chine and applications. In Proc. of the 17th Int. Conf.

on Parallel and Distributed Sys. IEEE.

Degu, A. (2019). Android app memory and energy perfor-

mance: Systematic literature review. IOSR J. of Comp.

Eng., 21.

Fernandes, T. S., Cota, E., and Moreira, A. F. (2014). Per-

formance evaluation of android applications: A case

study. In Proc. of the Brazilian Symp. on Computing

Sys. Eng. IEEE.

Fontana, F. A., Mariani, E., Mornioli, A., Sormani, R.,

and Tonello, A. (2011). An experience report on us-

ing code smells detection tools. In Proc. of the 4th

Int. Conf. on Soft. Testing, Veriﬁcation and Validation

Workshops. IEEE.

Fowler, M. (2002). Refactoring: Improving the design

of existing code. In Extreme Programming and Ag-

ile Methods — XP/Agile Universe, pages 256–256.

Springer Berlin Heidelberg.

Gartner, Inc. (2018a). Gartner says huawei secured no. 2

worldwide smartphone vendor spot, surpassing apple

in second quarter 2018. Accessed: 2019-08-30.

Gartner, Inc. (2018b). Gartner says worldwide end-user de-

vice spending set to increase 7 percent in 2018; global

device shipments are forecast to return to growth. Ac-

cessed: 2019-08-30.

GeSI (2015). Smarter2030 ict solutions for 21st century

challenges. Technical report.

Kansal, A. and Zhao, F. (2008). Fine-grained energy proﬁl-

ing for power-aware application design. ACM Perfor-

mance Evaluation Review, 36:26–31.

Kaur, A. and Dhiman, G. (2019). A review on search-

based tools and techniques to identify bad code smells

in object-oriented systems. In Harmony Search and

Nature Inspired Optimization Algo., pages 909–921.

Springer Singapore.

Li, L., Bissyand

e, T. F., Papadakis, M., Rasthofer, S., Bar-

tel, A., Octeau, D., Klein, J., and Traon, L. (2017).

Static analysis of android apps: A systematic litera-

ture review. Info. and Soft. Tech., 88:67–95.

Manotas, I., Bird, C., Zhang, R., Shepherd, D., Jaspan, C.,

Sadowski, C., Pollock, L., and Clause, J. (2016). An

empirical study of practitioners’ perspectives on green

software engineering. In Proc. of the 38th Int. Conf.

on Soft. Eng. ACM Press.

Mindsea (2019). 25 Mobile App Usage Statistics To Know

In 2019. Accessed: 2019-08-05.

Pathak, A., Hu, Y. C., and Zhang, M. (2011). Bootstrap-

ping energy debugging on smartphones. In Proc. of

the 10th ACM Workshop on Hot Topics in Networks.

ACM Press.

Pathak, A., Hu, Y. C., and Zhang, M. (2012). Where is the

energy spent inside my app? In Proc. of the 7th ACM

european conf. on Computer Sys. ACM Press.

Petersen, K., Feldt, R., Mujtaba, S., and Mattsson, M.

(2008). Systematic mapping studies in soft. eng. BCS

Learning & Development.

Powell, J. (2019). Scientists reach 100 Bulletin of Science,

Tech. and Society, 37:183–184.

Singh, S. and Kaur, S. (2018). A systematic literature re-

view: Refactoring for disclosing code smells in ob-

ject oriented software. Ain Shams Eng. J., 9(4):2129–

2151.

Tool Support for Green Android Development: A Systematic Mapping Study

417