2013 IEEE International Conference on Systems, Man, and Cybernetics
An Investigative Approach to Software Aging in Android Applications Jean Araujo∗† , Vandi Alves∗ , Danilo Oliveira∗ , Pedro Dias∗ , Bruno Silva∗ and Paulo Maciel∗ ∗ Informatics
† Academic
Center, Federal University of Pernambuco, Recife, Brazil Unit of Garanhuns, Federal Rural University of Pernambuco, Garanhuns, Brazil {jcta, valn, dmo4, phds, bs, prmm}@cin.ufpe.br∗
[email protected]†
Abstract—This paper proposes an investigative approach to indicators of software aging in applications developed for Android, a Linux-based operating system primarily designed for touchscreen mobile devices such as smartphones and tablets. Software aging is a degrading factor in systems, leading to poor performance, failures, and may ultimately result in system downtime. The methodology proposed identifies memory leaking in Android applications. In order to test the approach, case studies were performed with the Monkey tool as workload generator, employing Linux utilities to monitor the environment. Communication between the computer and the smartphone was handled with the ADB tool, a toolkit included in the Android SDK package. Experimental results confirmed both the effectiveness of the procedure and the existence of software aging phenomenon in the Foursquare application running on the Android OS platform.
on memory-related aging phenomena such as memory leaking, which are proven to have serious undesirable effects on system performance and availability [7]. The effect of the aging process on performance and battery consumption may be caused indirectly. The Android process manager is programed to load the memory with the largest number of applications possible, and when not being accessed remain paused without consuming CPU or network resources. Since they are allocated in RAM they can be restarted quickly and efficiently [8]. However, when an aging process is apparent, less space is available for caching other applications. In this situation the system may have to load some applications in other locations, not in RAM, thereby slowing down processes and increasing battery consumption, since it takes longer and consumes more energy to retrieve data this way. The study of software aging on the Android platform can help developers to keep control of their applications, preventing or eliminating degradation, enabling initiate immediate response to solve the issues related to memory consumption and avoiding unexpected failures on the system. The paper suggests an investigative approach to software aging, whereby it is possible to detect indicators of software aging through monitoring the memory utilization of an application, in this case Foursquare on the Android platform, when running continuously for a sustained period. The remaining parts of the paper are organized as follows: section II introduces some related works on software aging; section III discusses the fundamental concepts; section IV presents the proposed methodology; section V describes the adopted platforms and explores the experiment results; and finally section VI draws conclusions and suggests possible future works.
Index Terms—software aging, Android applications, memory leak, system control, ADB
I. I NTRODUCTION In recent years mobile phones have evolved from simple devices for making phone calls and sending SMS messages to sophisticated devices capable of running third-party software [1]. Such devices are now being used by millions of people around the world and their popularity continues to grow. Android [2] is an open-source software stack designed for mobile devices such as smartphones, tablets and music players, which delivers a complete software set, including an operating system, middleware, and key mobile applications [3]. Although the number of users is increasing year on year, Android remains in a state of development, and many theoretical and experimental researches have been conducted to test and improve this software since the first Android-powered phone was sold. The open nature of the Android OS offers programmers the freedom to access the platform’s capabilities [4], and whilst such accessibility encourages the development of attractive applications, it also introduces the risk of accidental failures, and the consequent frustration that this brings to users when a service becomes unavailable [5]. One major threat to availability is the phenomenon of software aging, an inevitable process where system processes suffer from performance degradation over the course of time. Monitoring such effects is an essential part of any aging characterization study [6]. The aim of this work is to evaluate the consequences of aging on an Android platform, focusing 978-1-4799-0652-9/13 $31.00 © 2013 IEEE DOI 10.1109/SMC.2013.213
II. R ELATED
WORKS
Monitoring the aging effects is essential to any aging characterization study. Many previous studies have implemented aging monitoring in different system levels, however to the best of our knowledge is that the discussion of aging effects in a Android environment is a barely explored topic. By considering application domains other than mobile computing, Controneo et al. [9] presents a software aging analysis at the Operating System level, investigating software aging sources inside the Linux kernel. Matias et al. [7] presented a 1229
study that explored the Linux operating system’s kernel using instrumentation techniques to measure software aging effects. A zero-downtime rejuvenation technique for the Apache web server is presented in [10], and adapted in [11] and [12] for Eucalyptus systems. The software aging effects in cloud computing environments were addressed in [6] and [13]. Those papers demonstrated the occurrence of faults in an Eucalyptus-based infrastructure due to the accumulation of memory leaks. In [11] and [12], rejuvenation strategies have been proposed for mitigating the downtime caused by the aging effects in that cloud computing framework. Matos et al. [14] shows some software aging issues, like memory leaking and the increase of CPU utilization during consecutive attachments of remote block storage volumes by means of Eucalyptus commands. Zhao et al. [15] proposed a software performance evaluation model called SPE based on Back-propagation neural network [16]. In order to validate the effectiveness of the proposed method and algorithms, the performance of the software affected by the aging phenomenon was evaluated using real data sets. Some metrics like load average, free memory, CPU usage and response time were observed. Study the systems performance is a basic step to investigate software aging effects. So, some performance evaluation studies related to Android OS can be observed. In [17], a performance comparison of Android virtual machines and Java virtual machines (JVM) is presented, and their energy consumption is discussed. A system that enables a investigation of an application launch procedure by modifying the Android system to capture events in the kernel and application frameworks associated with the application launch is proposed in [18]. Their evaluation demonstrated that the proposed system could point the time-consuming processes out and served to analyze performance. III. S OFTWARE AGING Software aging can be defined as a growing degradation of software’s internal state during its operational life [19]. The causes of software aging have been verified as the accumulated effect of software faults activation [20] during the system runtime [21]. Aging in a software system, as in human beings, is an accumulative process. The accumulating effects of successive error occurrences directly influence the aging-related failure manifestation. These effects gradually lead the system towards an erroneous state [21]. Such a gradual shifting is caused by aging effects accumulation, being the fundamental nature of the software aging phenomenon. It is important to highlight that a system suffers an aging-related failure due to the cumulative consequences of aging effects over the time. The aging factors [19] are the input patterns that exercise the code region where the aging-related faults may be activated. However, the related effect may be observable only after long run of the system. The time to aging-related failure (TTARF) is an important metric for reliability and availability studies of
systems suffering from aging [22], [23]. Previous studies (e.g., [10], [22], [6]) on the aging-related failure phenomenon show that the TTARF probability distribution is strongly influenced by the intensity with which the system gets exposed to aging factors such as system workload. Due to its cumulative property, the software aging phenomenon occurs more intensively in continuously running systems that are executed over a long time period. In long-running execution, a system suffering from software aging increases its failure rate due to the accumulation effect caused by successive errors that degrade the system internal state integrity. Problems such as data inconsistency, numerical errors, and exhaustion of operating system resources are examples of software aging consequences [19]. Since the notion of software aging was introduced [21], many researches have been conducted in order to characterize and understand this important phenomenon. IV. M ETHODOLOGY Recently, several applications have emerged for the Android environment, from those used simply to pass the time as some used for a important purpose as for patient monitoring. So, it is very important monitoring the resources utilization and to keep the application control running in the Android OS to get the expected results of the system. This section presents the proposed methodology for investigating and identifying memory leaking in Android applications. One of the principal consequences of software aging is poor device resource management, in particular memory consumption. One major memory-related phenomenon which indicates the existence of software aging is memory leak. Many memory leaking problems are difficult to detect, and there are few symptoms other than the slowing down of system performance and the steady increase in memory consumption [24]. Concisely put, memory leaking occurs when a process allocates memory during its execution, and continues to allocate more memory in each subsequent execution without deallocating that previously used. Eventually, if allowed to continue, the outcome would be a complete depletion of memory resources for the device. Figure 1 depicts an general view of the process adopted to perform software aging investigation. The description of each phase is presented afterwards.
Fig. 1.
1230
Software aging methodology diagram
A. Monitoring strategy A monitoring strategy proposed in [6] was adopted. Such a method uses shell scripts and was suitable to the Android environment. However, with Android being a Linux-based OS, many native Linux programs are not actually included in it, and therefore the data collection had to be simplified. For the purposes of this experiment, the top command [25] was employed to gather measures of resource consumption, such as memory utilization. A computer was used to collect information and generate the workload. Communication between computer and smartphone was handled with the Android Debug Bridge (ADB) [26]. This is a command line tool that allows a computer to control an Android-powered device through a USB link. ADB is a client-server program that includes three components: server, client and daemon. The server runs as a background process on the desktop machine and manages the communication between the client and the adb daemon running on the device. The client is invoked from a shell by issuing an adb command, whilst the daemon runs as a background process on each device instance [26]. ADB is a useful tool for developers to test their applications, and in the course of this work to investigate the effects of software aging, ADB was employed to monitor the device resources. A testbed was setup to perform the experiment (Figure 2). A computer was employed to simulate user requests and the resulting behavior of the workload was observed on a smartphone. The script responsible for monitoring all the applications running on the device is described below:
mise between the requirement to observe all important events whilst avoiding interference of the monitoring mechanism with the system behavior. B. Workload generator To investigate software aging effects such as memory leaking in Android applications the environment had to be monitored under intense operating conditions where it would be prone to failure. To monitor the environment under normal conditons and simply wait for the effects of aging to become apparent might have taken days, months or even years, and indeed might have never even occured [6]. Therefore, it was necessary to generate a workload capable of stressing the system and accelerating the failure process. For this purpose, the Exerciser Monkey [27] application was adopted. Monkey simulates random touches, clicks, and other user events and is commonly used by Android designers to stress-test applications in the development stage. If executed without specifying options, Monkey launches in a quiet (non-verbose) mode, randomly sending events to all packages installed on the target [27]. A typical Monkey command line is shown below: $ adb -s shell monkey -p 300
Monkey employs the ADB tool to send commands to a specified device via a prompt. The -s command contains the device serial number. Command -p specifies the package to be stressed, and 300 is the number of pseudo-random events sent by Monkey. A shell script was created to automatize the workload generation and set to run at 1 second intervals. It should be stated that the workload was designed to accelerate possible faults and the occurrence of aging symptoms, and the time values chosen were not meant to imitate real conditions.
$ adb -s shell “top” >> top-log.txt
Where: • the $ symbol is the command line prompt; • adb starts an ADB communication; • -s directs an ADB command to a specific emulator/device instance, referred to by its adbassigned serial number; • shell starts a remote shell command in the target emulator/device instance; • top is the command program that collects information about device resource utilization; • >> symbols add the output data to a specific file; • top-log.txt is the file where all the information is stored.
C. Stress test The preliminary stress test was performed over a short time period. The objective was to stress each environment resource and attempt to uncover any aging effect. If no aging effect was observed then the cycle ended. However, if any aging effect was detected then the next stage in the procedure was invoked and a new experiment performed over a longer time frame. The next stage is detailed in Section V V. E XPERIMENTAL S TUDY
Fig. 2.
In order to test the efficiency of the approach, a testbed environment was set up in accordance with the specifications in section IV. As previously stated, Foursquare was selected for the experiment. The Foursquare Android application [28] is a location-based social networking website for mobile devices currently being used by over 25 million people worldwide. Amongst its current users is NASA (the National Aeronautics and Space Administration), which is applying Foursquare as a tool to share the locations of Curiosity , the Mars rover, while it explores the surface of the planet [29].
Testbed environment
Data was collected every 10s by executing the script described above. The sample frequency was chosen as a compro-
1231
The testbed employed a desktop machine (Intel Core 2 Duo, CPU E7500 @ 2.93GHz, 4 GB of RAM, and a 500 GB SATA hard disk) to generate the workload using Windows 7 Professional 64-bit (6.1, Build 7601) Service Pack 1 operating system, and a smartphone Samsung Galaxy Ace S5830 (800 MHz ARM 11 CPU, 278 MB of RAM, 158 MB internal storage, and 2GB microSD) to run the Android OS v2.3.4 (kernel version 2.6.35.7). These devices were selected because they possess an average configuration when compared to the wide range of devices available in the market today. A. Data Analysis The advantage of utilizing the top command to monitor system resources is that it collects information on all the the processes running at any point in time. Since in the initial stages it was unknown which processes, if any, were going to demonstrate indicators of aging, it was not necessary to select one specific process to monitor. However, the drawback was the analysis of the large log file generated. The solution was to filter the log file data with Bash scripts that search for words of interest and return only the specified information.
(a) Resident memory
B. Result Analysis The data collected in the experiments indicate certain significant aging effects in Foursquare. Other important processes to the Android OS such as system server and zygote were also considered, but since no significant results relating to aging were detected they were not included in the analysis. The effectiveness of the approach is demonstrated by the results discussed below. Figure 3 illustrates the resident memory and virtual memory usage by Foursquare (com.joelapenna.f oursquared) during the first experiment where large increases in the utilization of both resources are evident. Comparing the respective values at the beginning of the experiment and at the end, the resident memory increased by about 200 MB and virtual memory by 425 MB. Such results indicate that when applying the Monkey tool to imitate touch operations, the Foursquare process experiences the effects of software aging. Additionally, it should be highlighted that the experiment ran for just 35 minutes, therefore in actual environments where applications run uninterruptedly for hours or even days and where much larger number of different processes are involved, the amount of wasted memory would probably be much higher than reported here. Virtual memory basically uses hard disk as an extension of RAM, but on mobile devices, which lack a hard disk, the Android OS employs flash memory to perform this task. Flash memory is slower then RAM, and application execution time increases as virtual memory utilization grows. Thus, it can be shown that software aging not only impacts the application availability, but also its performance. To determine if the approach interfered with the functioning of the Android OS, the resource usage of the adb and top processes were also monitored. Figure 4 illustrates the resident and virtual memory utilization of both processes. Results
(b) Virtual memory Fig. 3.
Memory utilization in Foursquare process: First experiment
shows that the use of resident memory is very small. At the beginning of its monitoring, the top process (blue line) uses only 0.4 MB which then decreased to about 0.3 MB. The adb process (red line) began by using only about 0.2 MB, and continued as such until the end of experiment with little variation. The virtual memory utilization was a bit higher than resident memory, but still relatively low. T op used 1 MB, and adb used about 3.4 MB. Considering these figures it can be stated that the interference caused by the workload and monitoring mechanisms was irrelevant when compared to the entire environment. In addition, no aging symptoms were observed. To verify whether this behavior persisted in the long term, a further experiment needed to be to executed, from which it would be possible to draw consistent conclusions. This time the experiment was performed over a 72 hour period. Figure 5 illustrates the results for resident and virtual memory usage in Foursquare (com.joelapenna.f oursquared) during the second experiment. Again, large increases in the utilization of both resources were observed. Resident memory utilization was stable during part of the experiment, but there were some growth peaks which reached 150 MB, finally stabilizing close to 140 MB. Similar behavior was observed concerning virtual
1232
Fig. 4.
(a) Resident memory
(a) Resident memory
(b) Virtual memory
(b) Virtual memory
Memory utilization in top and adb process: First experiment
Fig. 5.
Memory utilization in Foursquare process: Second experiment
VI. F INAL R EMARKS memory. There were periods of stability, but utilization reached peaks approaching 340 MB towards the end of the experiment. Figure 6 illustrates resident and virtual memory utilization of adb and top in the second experiment. Resident memory utilization by adb increased slightly, but top utilization exhibited the same behavior as in the initial experiment. Virtual memory utilization showed a large growing when compared to the rst experiment, however top employed only 1 MB, and adb only about 5 MB of virtual memory, and such results confirm that the monitoring strategy did not significantly interfere in system behavior. A simple visual comparison of memory behavior in both experiments illustrates that the growth rate in Foursquare process was largely linear in the first, whereas the second exhibited peaks of growing, using less memory. It is worth noting that the Monkey application simulates random user touches and clicks. Therefore, it may spend hours on a single screen or just a few seconds. So, we believe that this randomness in the workload is related to the diference showed in both experiments. It is also very important to stress that the smartphone was powered off at the end of each phase, and only turned back on at the initiation of a new experiment.
In this paper, we use existing tools to propose an approach for monitoring and detecting memory leak in Android applications. The Monkey tool was used to generate a stressful workload, whose goal is to accelerate the software aging, identifying more quickly its effects. Linux utilities were used to collect information about resources utilization of the device. The communication between devices was only possibile using the ADB tool. The results indicates the effectiveness of our approach, and allowed to detect a software aging effect (memory leak) in Foursquare application to Android. As future work, we have intend to investigate the effects caused by software aging in the response time of Android applications. VII. ACKNOWLEDGMENTS We would like to thank the Coordination of Improvement of Higher Education Personnel – CAPES, National Council for Scientific and Technological Development – CNPq, Foundation for Support to Science and Tecnhonology of Pernambuco – FACEPE and MoDCS Research Group for their support. R EFERENCES [1] E. Chin, A. P. Felt, K. Greenwood, and D. Wagner, “Analyzing interapplication communication in android,” in Proceedings of the 9th inter-
1233
[11]
[12]
[13]
(a) Resident memory [14]
[15]
[16] [17] [18]
[19]
(b) Virtual memory Fig. 6.
Memory utilization in top and adb process: Second experiment [20]
[2] [3] [4] [5]
[6]
[7]
[8]
[9]
[10]
national conference on Mobile systems, applications, and services, ser. MobiSys ’11, 2011, pp. 239–252. Philosophy and goals. Android Open Source Project. Available in: http : //source.android.com. Android: Overview. Open Handset Alliance. Available in: http : //www.openhandsetalliance.com. D. Felker, Android Application Development For Dummies. Wiley, 2010. M. Cinque, “Enabling on-line dependability assessment of android smart phones,” in Proceedings of the 2011 IEEE/IFIP 41st International Conference on Dependable Systems and Networks Workshops, ser. DSNW ’11. Washington, DC, USA: IEEE Computer Society, 2011, pp. 286–291. [Online]. Available: http://dx.doi.org/10.1109/DSNW. 2011.5958783 J. Araujo, R. Matos Junior, P. Maciel, , and R. Matias, “Software aging issues on the eucalyptus cloud computing infrastructure,” in Proceedings of the IEEE Int. Conf. on Systems, Man, and Cybernetics (SMC’11), Anchorage, USA, 2011. R. Matias, I. Beicker, B. Leitao, and P. Maciel, “Measuring software aging effects through os kernel instrumentation,” in Proc. 2nd Int. Workshop on Software Aging and Rejuvenation (WoSAR’10), in conjunction with 21th IEEE Int. Symp. on Software Reliability Engineering (ISSRE’10), San Jose, USA, Nov. 2010. C. Hoffman, “HTG Explains: Why You Shouldn’t Use a Task Killer On Android,” http://www.howtogeek.com/127388/ htg-explains-why-you-shouldnt-use-a-task-killer-on-android/, 2012, [Online; accessed 19-February-2013]. D. Cotroneo, R. Natella, R. Pietrantuono, and S. Russo, “Software aging analysis of the linux operating system,” 2012 IEEE 23rd International Symposium on Software Reliability Engineering, vol. 0, pp. 71–80, 2010. R. Matias and P. J. Freitas Filho, “An experimental study on software
[21] [22] [23]
[24] [25] [26] [27] [28] [29]
1234
aging and rejuvenation in web servers,” in Proc. of 30th Annual Int. Computer Software and Applications Conference (COMPSAC’06), Chicago, Sep. 2006. J. Araujo, R. Matos Junior, P. Maciel, F. Vieira, R. Matias, and K. S. Trivedi, “Software rejuvenation in eucalyptus cloud computing infrastructure: a method based on time series forecasting and multiple thresholds,” in Proceedings of the 3rd International Workshop on Software Aging and Rejuvenation (WoSAR’11) in conjuction with the 22nd annual International Symposium on Software Reliability Engineering (ISSRE’11), Hiroshima, Japan, 2011. R. Matos Junior, J. Araujo, P. Maciel, F. Vieira, R. Matias, and K. S. Trivedi, “Software rejuvenation in eucalyptus cloud computing infrastructure: A hybrid method based on multiple thresholds and time series prediction,” International Transactions on Systems Science and Applications, vol. 8, pp. 1–16, 2012. J. Araujo, R. Matos Junior, P. Maciel, R. Matias, and I. Beicker, “Experimental evaluation of software aging effects on the eucalyptus cloud computing infrastructure,” in Proceedings of the ACM/IFIP/USENIX International Middleware Conference (Middleware’11), Lisbon, Portugal, 2011. R. Matos Junior, J. Araujo, V. Alves, and P. Maciel, “Experimental evaluation of software aging effects in the eucalyptus elastic block storage,” in Proceedings of the IEEE Int. Conf. on Systems, Man, and Cybernetics (SMC’12), Seoul, Korea, 2012. J. Zhao, K. S.Trivedi, Y. Wang, and X. Chen, “Evaluation of software performance affected by aging,” in Proc. 2nd Int. Workshop on Software Aging and Rejuvenation (WoSAR), in conjunction with 21th IEEE Int. Symp. on Software Reliability Engineering (ISSRE’10), San Jose, Nov. 2010. S. Russell and P. Norvig, Artificial Intelligence: A Modern Approach, ser. Prentice Hall Series in Artificial Intelligence. Prentice Hall, 2010. P. K. Kundu and K. Paul, “Android on mobile devices: An energy perspective,” in Computer and Information Technology (CIT), 2010 IEEE 10th International Conference on, 29 2010-july 1 2010, pp. 2421 –2426. K. Nagata and S. Yamaguchi, “An android application launch analyzing system,” in Computing Technology and Information Management (ICCM), 2012 8th International Conference on, vol. 1, april 2012, pp. 76 –81. M. Grottke, R. Matias, and K. Trivedi, “The fundamentals of software aging,” in Proc of 1st Int. Workshop on Software Aging and Rejuvenation (WoSAR), in conjunction with 19th IEEE Int. Symp. on Software Reliability Engineering, Seattle, Nov. 2008. A. Avizienis, J. Laprie, B. Randell, and C. Landwehr, “Basic concepts and taxonomy of dependable and secure computing,” IEEE Transactions on Dependable and Secure Computing, vol. 1, pp. 11–33, 2004. Y. Huang, C. Kintala, N. Kolettis, and N. D. Fulton, “Software rejuvenation: Analysis, module and applications,” in Proc. of 25th Symp. on Fault Tolerant Computing, FTCS-25, Pasadena, 1995, pp. 381–390. Y. Bao, X. Sun, and K. S. Trivedi, “A workload-based analysis of software aging and rejuvenation,” IEEE Transactions on Reliability, vol. 54, pp. 541–548, 2005. R. Matias Jr., K. S. Trivedi, and P. R. M. Maciel, “Using accelerated life tests to estimate time to software aging failure,” in Proc. of the 2010 IEEE 21st Int. Symp. on Software Reliability Engineering, ser. ISSRE ’10. Washington, DC, USA: IEEE Computer Society, 2010, pp. 211– 219. Z. Xu and J. Zhang, “Path and context sensitive inter-procedural memory leak detection,” in Proc. of the 8th Int. Conf. on Quality Software, Washington, DC, USA, 2008, pp. 412–420. R. Blum, Linux Command Line and Shell Scripting Bible. Wiley Publishing, Inc, May 2008. Android debug bridge (adb). Android Developers page. Available in: http : //developer.android.com/tools/help/adb.html. Uiapplication exerciser monkey. Android Developers page. Available in: http : //developer.android.com/tools/help/monkey.html. Foursquare. Foursquare.com, Inc. Available in: https : //f oursquare.com/. Nasa’s curiosity rover checks-in on mars using foursquare. National Aeronautics and Space Administration (NASA). Available in: http : //www.nasa.gov/home/hqnews/2012/oct/HQ1 2 − 341C uriosityF oursquare.html.
