=Paper=
{{Paper
|id=Vol-2953/SEIM_2021_paper_7
|storemode=property
|title=Navitas Framework: A Novel Tool for Android Applications Energy Profiling
|pdfUrl=https://ceur-ws.org/Vol-2953/SEIM_2021_paper_7.pdf
|volume=Vol-2953
|authors=Vladislav Myasnikov,Alexey Shaposhnikov,Stanislav Sartasov,Egor Gordienko,Olga Aphonina,Alan Gamaonov
}}
==Navitas Framework: A Novel Tool for Android Applications Energy Profiling==
https://ceur-ws.org/Vol-2953/SEIM_2021_paper_7.pdf
Navitas Framework: A Novel Tool for Android
Applications Energy Profiling
Vladislav Myasnikov∗ , Alexey Shaposhnikov† and Stanislav Sartasov‡ ,
Egor Gordienko§ , Olga Aphonina¶ and Alan Gamaonov∥ ,
Saint Petersburg State University
∗ vladislav.myasnikov@bk.ru
† st069259@student.spbu.ru
‡ stanislav.sartasov@spbu.ru
§ egor.gordienko.00@gmail.com
¶ o.aphonina@gmail.com
∥ st061582@student.spbu.ru
Abstract—In a modern world smartphones became a com- developers [3]. One of the valuable results in this field are
monly used electronic devices performing numerous day-to-day energy-efficient refactorings — code changes that don’t change
tasks and much more. But they require battery power to operate. application behavior, but reduce its energy footprint [4].
It is well-known that computationally intensive programs as
well as those using different smartphone peripherals tend to But how bad is particular code from an energy consumption
discharge the battery much quicker then their less intensive perspective? Do we really need to apply a refactoring to it? To
counterparts, leading to a decreased operating time. To make
an application energy-aware, developers need tools to analyze its answer these questions a developer needs to measure power
energy consumption. In this paper we present an open-source drain of an application, module, procedure or test, therefore
software framework to create such tools, Navitas Framework, as a power metering tool which is reliable and easy to use is
well as its practical application — an Android Studio IDE plugin required. We think that such a tool should become an integral
to profile energy consumption of an application, Navitas Profiler. part of development culture instead of being used only during
We describe design and architecture of the framework, outline
plugin capabilities and demonstrate its usage. energy bug fixing sessions.
Keywords—energy efficiency, green software engineering, mo- Some successful frameworks and tools were created previ-
bile development, energy profiling, Android, software power
metering ously, but we identify two essential gaps we would like to fill
with our software:
I. I NTRODUCTION
• Overall level of IDE integration is still regretfully low.
”My phone discharged!” In a modern world this phrase is a Only a handful of tools can be run inside IDE, and among
known source of frustration for billions of people. By the end those who can, not every profiling scenario useful to
of 2023 it is projected for a number of smartphone users to developers is supported.
reach 4.3 billion with Android OS still being a leading mobile • To our knowledge, no power metering software con-
OS [1]. siders multi-threading to be an important factor. Multi-
As smartphone components require electrical power to threaded applications, while being common under mobile
operate, a battery provides a fixed level of voltage and a vari- operating systems for more than a decade, introduce an
able current. When battery charge level is low, voltage level additional level of complexity to energy consumption
drops beyond a certain threshold, where it is not enough for measurement or estimation.
smartphone components to work properly. As smartphone pe-
ripherals tend to consume more power during high workloads
With this considerations in mind we present Navitas Frame-
than during idle states, it can be seen why computationally
work and Navitas Profiler plugin for Android Studio IDE.
intensive or network-intensive software spend battery charge
more rapidly than its less intensive counterparts. The less time This paper is organized as follows. In Section 2 we lay out
remains for the user to work with an application, the worse the context of our work in terms of Android OS capabilities
the user experience. along with the related works. In section 3 the design of Navitas
While advances in materials and electronics in the last years Framework is discussed. Section 4 adds more details to
helped to offset this problem by introducing more capacious specific modules of a framework and describes the capabilities
batteries or power-saving processors, the issue of energetically of the Navitas Profiler plugin. Experiments used to prove
inefficient software is still important. Green software develop- framework validity are described in Section 5. In Section 6
ment views energy consumption considerations as important as we list current limitations of our framework and outline future
performance metrics [2], but it is still not so popular amongst work.
Copyright © 2021 for this paper by its authors.
Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).
II. OVERVIEW measurement framework and significantly complicates model
computation.
A. Related works
We conducted a systematic literature review (SLR) on the B. Industrial grade frameworks
power metering frameworks for Android OS [5]. The main
Only a handful of the reviewed frameworks has a source
classification point for different approaches in software energy
code or an application available for reuse, and even less
consumption estimation is whether power is directly measured
support modern versions of Android OS. However, there is
or indirectly estimated.
a number of tools that are used in the industry to assess
Direct measurement means that some metering agent, either
application energy consumption.
internal or external to Android device, is directly measuring
BatteryHistorian [15] is a background system events an-
voltage, current or even power. The simplest way is to connect
alyzing utility for Android OS. It is a direct measurement
external digital multimeter to battery contacts of a smartphone
framework using internal smartphone sensors through OS API,
and work with an application in question or launch a unit
but energy consumption is represented as a battery charge
test. At the same time multimeter will write power readings
percentage which is prone to battery degradation and not
[6], [7], [8]. Alternatively one can use internal power sensors
precise enough to estimate power drain for a short-running
of a smartphone itself [9], [10], [11]. Such a tool can get
test.
a good power consumption reading for entire smartphone,
Android Studio Energy Profiler [16] is a plugin for Android
experimental design may narrow it down to a level of a
Studio IDE. It shows power drain in relative terms during
single application. For a more detailed report the source code
application execution. While the information on the model
is instrumented with additional logging instructions to mark
itself is very sparse, we consider it to be indirect estimation
method or code beginning and end, and two sources of data
framework based on a component working time model. We
— power readings and application execution trace [9], [4] —
carefully note that this model is device-agnostic and it is
are generated and aligned. Instrumentation energy overhead
not clear how accurate does it represent real device energy
should also be estimated and accounted [4].
consumption.
Indirect estimation means that profiling software is ag-
gregating some code execution information and relates it to Our conclusion is that while there were interesting research
energy consumption using some model, therefore we also call projects, and some of the tools see practical use, only Android
this approach model-based. Studio Energy Profiler is integrated with Android Studio IDE,
but it has its own limitations.
One of the ways to build a model is to estimate bytecode
energy consumption by evaluating an energy consumed by a
C. Multi-threading in Android OS and its challenges to energy
number of specific instruction types using weighted sum (for
consumption measurement
example, conditional statements, loops, float-point arithmetic
etc.) [12]. Direct measurement framework can be used to Android OS fully supports multi-threading. Multi-threaded
obtain weight coefficients. This approach allows to evaluate applications are common nowadays, as it is a good way
energy consumption of a test run without even running it. It to distribute computational load among the processor cores.
can be further advanced by accounting library functions [4]. This idea became even more lucrative with the advent of
Another way to make an indirect estimation framework is big.LITTLE2 processor architecture [17], where processor
to base an estimating model on time percentage that specific cores are no longer homogeneous, but instead they are grouped
hardware component was active or worked at a specific into clusters based on their computational capabilities and
frequency from the finite set [13]. Each value is multiplied power requirements.
by regression coefficient, and the total sum is found. While it Every Android application is being executed as a separate
is not difficult to track system events like peripheral switching process having its own threads. A process currently running
on and off to aggregate this data, the challenge lies in CPU in foreground or able to appear on the screen has its threads
power estimation. Let’s model CPU power consumption as a assigned to foreground control group, while other processes
sum of idle consumption and active per core consumption. have their threads assigned to background control group. It is
For the sake of discussion let’s assume those values are important to note a heavy disparity in processor time between
constant. CPU consumes more power when multiple cores those groups: foreground threads get about 95% of time, while
are active compared to a single-core computation. Due to background threads get the rest of it.
the Peukert’s law [14] the real battery capacity under higher To our knowledge, none of the energy consumption frame-
power consumption is smaller than under a lower one, and this works specifically target multi-threaded applications, and only
difference is considerable [13]. Thus using a single coefficient an approach from a single paper can be directly extrapolated
for each instruction type is insufficient for accurate power to multi-threaded case [13], however the corresponding source
consumption estimation in a multi-threaded case. A model to code or an application is not available. It is a challenging
account this effect requires power drain value for each combi- task to understand individual thread impact on overall energy
nation of peripherals currently turned on [13]. This information consumption. It is possible to understand when the thread
is challenging to be obtained experimentally, requires direct was actively executing by ftrace system calls [18] and to
homogenize peripheral energy consuption over time by con- Both types of sensors can produce a series of time marks
trolling DVFS governor. However, as noted previously, CPU and instant power readings. The main deciding factor is the fre-
power consumption greatly varies depending on a number of quency of analog-to-digital converters. For external sensors a
cores under active payload. It is currently an open question if typical value is 10 KHz, therefore power difference at intervals
there is a correlation between this variable power consumption of 100 µs can be captured. This frequency is considered in the
and the data in CPU power profile and, more importantly, how literature as appropriate for capturing code power consumption
to adjust measurement and analysis processes to account this on a method level [12], and in our observations the most
variation. To our knowledge, no other papers or profiling tools power-consuming methods typically run at least for a 1 ms or
documentation answer these questions as well. in loops lasting longer than that. In the case of internal power
sensing frequencies of 1 Hz or less are not unheard of [21],
III. Navitas Framework DESIGN and that severely limits a number of profiling scenarios.
A. Conceptual approach For the model-based approaches, time-based models are al-
ready well-suited for multi-threaded scenario, however special
Direct measurement approach can easily be extended to a
calibration should be done to address simultaneous multi-core
multi-threaded case. If program execution trace is not used
processor and graphic card load, as their energy consumption
in the framework, then application energy consumption is
might change non-linearly when a number of active cores
an aggregate of energy consumption for all its threads, so
or GPU multiprocessors increases. As for the models based
the measurement process would not be different from single-
on instruction or function energy consumption estimation,
threaded case. While our understanding of underlying energy
this approach is limited in multi-threaded environment. Power
consumption would be limited, in some scenarios this is
coefficients for specific instructions may not reflect under-
exactly what is required — to measure total power footprint
lying peripherals usage. In real life scenarios programs are
of an application. If execution trace is used then thread ID
interacting with smartphone peripherals which are at least as
information can be added to each trace entry, and by splitting
consuming as CPU [22] and are independent from proces-
execution trace by thread IDs one may obtain traces for
sor execution. While a function call to decrease the screen
each thread in application. Aligning this information with
brightness might be estimated in terms of power drain, the
multimeter power readings will give us a timeline of energy
side effect of reducing screen power footprint cannot be
consumption with respect to modules, methods or functions
reduced to processor instruction energy consumption. Second,
being executed at that time.
library functions power consumption is often dependent on its
A key component for the metering software using a direct
input length (i.e. data transmission functions) and cannot be
measurement approach is a hardware sensor. Sensors capturing
accurately presented by linear coefficient.
momentary current and voltage can be used for power sensing
The following points were the most important when we
as well as dedicated power sensors. In general, smartphone
made a decision on the conceptual approach for the Navitas
electronics operates at a constant voltage, and a good power
Framework:
estimate could be achieved by using only an ammeter and a
• External sensors require money to acquire and a certain
manufacturer specification for peripheral working voltage as a
constant1 . If such a device is integrated in a smartphone itself, qualification to be properly used.
• While direct measurement approach using internal sen-
we call it an internal power sensor, otherwise it is an external
sensor. sors was promising at first, we quickly found out that on
Android OS provides a number of APIs for getting power our test devices sensors’ frequency was not stable and
reads from internal sensors. With a root access to a smart- high enough for practical use.
• Instruction and function-level power estimation have in-
phone a developer may directly read files from proc folder
for momentary power state [7]. Alternatively, one can use herent conceptual flaws for multi-threaded analysis.
• Time-based models often have a support from manu-
batterystats power logging utility and download it after
test case is finished [19]. Both these options allow a high facturers in the form of power_profile.xml — an
degree of customization, i.e. they may or may not include XML file containing the values of electrical current for
information of currently active peripherals like Wi-Fi or GPS various modes of operation of the devices installed in the
modules. smartphone. This file can be obtained without root access
External sensors like Monsoon [20] cost money to acquire, and can be used as an initial set of weighted coefficients
so their acquisition might be a limiting factor. Being an for our model.
• Execution data for time-based models can be obtained
external device to a smartphone they don’t capture information
on active peripherals at the time of metering. When aligning using Android API calls and utilities.
application traces with external measurement data, in order In the end, we choose Navitas Framework to follow time-
to properly synchronize time marks one should synchronize based indirect estimation approach.
timings between different devices [7]. B. Reporting units
1 Battery voltage level drops with the discharge, but it is pretty constant for From our SLR we knew that there is no uniformity in re-
Li-Ion and Li-Pol batteries from 90% to 20% porting units that other frameworks use [5]. Some frameworks
used absolute values like Joules, Watts or Amperes, other used
battery discharge percentage or relative non-dimensional units
[16]. As raw data from power_profile.xml contained
values measured in milliamperes (mA), voltage can be found
in device specification, and execution time is obtained from
test or application execution trace, Joules and battery charge
percentage were two main reporting units candidates.
Each recharge cycle for Li-ion batteries inevitably shortens
their discharge time under the same drain, therefore estimating Fig. 1. Navitas Framework workflow. Grey background is for Android Studio
battery time change can only be done with a context of how tasks, black background is for the framework tasks
old a battery is and how many recharge cycles it was run
through [14]. As controlled experiments tremendously differ
IV. Navitas Framework AND Navitas Profiler
from real-time smartphone usage where screen brightness is
IMPLEMENTATION
high and multiple peripherals may be active at the same time,
high battery drain might be observed. Because of Peukert’s law A. High-level overview
resulting battery time from such a drain can be estimated, but it Android Studio is currently one of the most popular IDEs
will be lower than in experimental environment. We conclude among Android developers [26], and while at the time of
that reporting in Joules results in a simpler estimation model. writing it is a natural choice to develop a profiling tool for it, a
more general approach would be to develop a framework based
on the current compiling tools and practices and a specific
C. Instrumentation and its overhead
extension or plugin for Android Studio.
Source code instrumentation is not necessary if a it can Internally, Android Studio runs a set of Gradle tasks to
be manually updated with all necessary logging information, compile and run Android applications. Those tasks are IDE-
however automated approach is preferred, for instance by agnostic and can be reused in other IDEs. We extend this set
applying source code transformation using javassist li- of tasks with Navitas profiling tasks, and the overall workflow
brary [23] or BCEL [24]. We concur with the literature that can be seen in Fig. 1.
method start and end should both be instrumented to provide Our first custom task instruments the application code
a proper call hierarchy [9]. Instrumentation trace from a code at the compilation stage with additional instructions to log
execution should also be profiled for energy consumption execution trace and thread information. After the compilation
in order to deduct it from total power spending for better is completed, we additionally initialize target device logging
metering accuracy [4]. For multi-threaded case instrumentation facilities to trace component activity information. Then after
code should be adjusted to include a thread ID for each log the test run is finished we download these logs along with
entry. We decided to calculate contribution of each device at execution traces to a computer and format component usage
the measurements results analysis phase. statistics report.
Various test runners can be supported independently from
power profiling Gradle tasks. Currently we use JUnit as a
D. Tests vs. application runs default test runner, and its capabilities are fully supported.
Both single tests and test sets can be profiled, and the profiling
There are two ways of deploying an instrumented applica- results are shown for each test (see Fig. 3). Proof of concepts
tion for power profiling ([25], [7], [6]). Tests are designed for were also made for Espresso and MonkeyRunner frame-
conducting repeatable executions of the same scenario under works.
the same conditions, and they are more suitable for controlled Navitas Profiler plugin for Android Studio is an orchestra-
experiments. Different test runners like MonkeyRunner, tor. It manages what code to instrument, what tests to run and
JUnit or Espresso can be used for Android applications what device to use for it. It also handles the energy coefficients
([7], [12]). Application run means launching the entire in- for target devices and it also runs the model against obtained
strumented application on a test device and conducting some component usage statistics and displays energy consumption
manual interaction with it. In general it can’t be as repeatable report to the user.
as a test due to human involvement, but it helps to make an
overview of general application power drain. A the same time B. Framework instrumentation
tests may be checking application in an uncharacteristic way The instrumentation of application code occurs during com-
compared to a real usage. piling and packaging. We used Transform API library
Overall, in our opinion the choice between application runs which allows third-party plugins to manipulate compiled files
and tests lies in a particular profiling scenario, because the before they are turned into dex files.
boundary between the use cases for both approaches is blurry. To transform the code one needs to create a class and
While Navitas Framework is agnostic to the level of workload implement Transform interface to register the code trans-
execution, we choose test runs due to simplicity of integration. formation. The main instrumentation logic is implemented
in the overridden transform method. For each of the different brightness levels to model weight coefficients and
instrumented files, the necessary imports are added to the summing the results. These coefficients are obtained by inter-
beginning. Furthermore, for all methods of each class, methods polating power values from the power_profile.xml file
of the Javassist library are applied — insertBefore for minimum and maximum brightness. Timing information
and insertAfter. A string containing Java code is passed is obtained from batterystats log, which contains screen
as a parameter. Even though Kotlin is now the primary brightness change events. Each event includes time since last
development language for Android, many applications are still batterystats reset in milliseconds and one of the five
written in Java, so adding Java code allows us to ensure the brightness levels: dark, dim, medium, light, bright.
correct operation of the original programs in both languages,
D. Framework execution trace and component usage statistics
as full interoperability is maintained between Kotlin and Java.
acquisition
Our experience shows that code instrumentation at compilation
phase is faster than APK disassembling and instrumenting After all the tests are completed, execution logs and compo-
mentioned in earlier works. nent status are downloaded from the test device. As logcat
Logcat is a command line tool that prints a log of system logs contain a lot of additional information, but each entry type
messages, including a stack trace, when the device generates structure is regular, pattern matching using regular expressions
an error, and other messages may be written by a custom is used to extract actual data. Then thread execution traces
application using the Log class. Logcat is convenient to use are separated from one another, and the obtained data is
because in addition to the message itself it adds information aggregated into a JSON files. These files are then processed
about the current time (up to milliseconds), process ID and the by high-level tools based on Navitas Framework, but we also
thread ID. The code we instrument into methods adds method keep the file format open if a user wants to process the data
name to execution trace logs and accesses system API to trace with some custom tool.
component activity. Activity data is then passed to Logcat. E. Navitas Profiler implementation
C. Framework component activity data acquisition and model Navitas Profiler is a plugin for Android Studio based
formulas on Navitas Framework tasks and developed to provide a
Among the components of a smartphone which affect en- practitioner a high-level tool to profile energy consumption
ergy consumption the most important is the processor. Android of Android applications during the development process and
OS has special time-in-state files in the /sys directory visualize power consumption based on profiling results while
that contain information about the time each processor core being integrated with the IDE itself.
spent at a specific frequency. The data in these files is stored
in pairs like