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