This blog post is from the work - “The
Power of System Call Traces: Predicting the Software Energy
Consumption Impact of Changes” that has been accepted at CASCON 2014 to be held at Toronto from 3-5 November 2014 .
The work relates the energy consumption of android applications to
system calls made by the application. You can find the work here
Limited battery life is a pressing
issue for the common smart phone users. This has forced the
developers to consider the energy profile of their application.
However, profiling energy consumption of an application requires
special external instrumentation for measuring the current and voltage
reading to estimate the power consumption. Studies have shown that on
device measurements are not reliable. Thus, developers for the most
part are clueless about the impact of software change on their
application's energy profile.
System calls, act as buffer between the
OS and the applications to provide the OS services and resources to
the applications. It is hence, interesting to consider the
relationship between the energy profile and system call trace of the
application. So, we considered two applications – Firefox and
Calculator on Android. We took 101 and 156 versions of the
Calculator1 and Firefox2 applications
respectively, with each version being separated by one commit in
To get the system call trace, we use
the strace tool , that needs to be cross compiled for
Android3. The strace executable cross-compiled needs to be
placed either on the phone or even on a system that's connected to
phone. To trace an application just use “strace -c appProcessID”,
after starting the application4.
If it is on the system,
connected to phone, the command can be run from the adb shell. For
the Calculator application, we had 26 different system calls made,
while for the Firefox we had 53 different system call invocation.
will also like to device a particular test sequence, for the
applications, which can then be emulated on the phone using the
monkey script runner. To devise the tests, you will need to emulate
the test sequence on the android emulator, which ships with the
Andorid studio. Just enable the developer options tool on the device,
which helps to note the pixel values of the screen. To emulate a
touch action on the phone, we note the pixel value at the screen
where touch is made. Similarly, for a swipe action , we note
starting and ending pixels on the screen. The emulator provides the
note the pixel values at each tap or swipe on the
Using this noted sequence, we need to build the
monkey script, that can be run on the phone using the monkey runner,
that also ships with the android -sdk, and needs android-ndk.
a special test bed to measure the energy use, called Green
Miner. We tried to establish the
relationship between system call counts and energy usage of the
applications. We did multiple tests for each version to see whether,
a change in the system call trace leads to a significant change in
the energy use. To achieve this, we use the Student's t-tests
to establish whether the two consecutive versions are same with
respect to system call profile and energy consumption. Now,
developers are not statisticians, so we tried to formulate a rule of
thumb to help them say whether they should be concerned when their
system call count change.
so, we calculate simple frequency of occurrence of this phenomenon,
“Significant Change in system call count leads to significant
change in energy consumption”. To see the significant change in
the applications, system call count, strace the previous version and
as well strace the next version after the change in the application
code, multiple times, say 10 times. Then to see whether the change in
the system call count is significant, use the t-tests.
Example below shows the same in R, where the 3-D matrix sysCounts,
contains the system call counts for the ten runs for a version:
<- array(0,dim=c( 100,26 ))
<- array(0,dim=c(26, 10 , 101))
Read the data to noSysCalls matrix */
(i in 1:(noVersions-1))
saves the result of the Student's t-test.
To test the significance of change between versions we need to see
p-value < 0.05.
the Calculator application results were astounding, some system calls
like pread, or stat64
had 100% frequency
of occurrence of this phenomenon while on an average for each system
call, this phenomenon occurred 58% of the times. For the Firefox,
application, with the sheer number of system calls as compared to the
Calculator application, this average frequency rate is 25%. Hence,
with once in four times, a system call's count changes significantly
from the previous one, we can say that there is a change in the
energy profile of the application.
saves the developers from the worry of setting up an exclusive and
expensive instrumentation to measure the power use, to see the impact
of software change on the energy. They just need to use the strace
to profile the system calls. Hence, developers just need to notice
the change in the system calls profile, and hence can expect the
change in energy use of their applications.