Monitoring and Enhancement of Mobile System Performance

Android operating system, since its first start, is growing very fast and takes a large space in smart devices market. It is built and developed on Linux and designed basically for touch screen devices such as, mobiles, tablets, etc. Mobile devices are markedly complicated and feature-rich; therefore they are prone to reliability of software and performance problems. Because of the small resources, smart devices, such as CPU, RAM, suffer from problems. One of these problems is Software Aging (SA). SA is recognized in long running OSs as a shortage in resources, performance retreating, and finally failure. SA is looked at from two sides, namely the poor response time of application which represents the end user side and the shortage in metrics related to device resources, such as RAM and storage. In this paper, a set of eight experiments is conducted to distinguish SA in Android mobiles. These experiments are conducted to find the correlation between Launch Time (LT) with RAM and storage metrics covered in this paper. Statistical methods, such as Mann Kendall test, Sen’s slope, Spearman rank correlation, and Design of Experiment (DOE) are used to prove the correlation statistically. These experiments assist to detect SA, which will be helpful in the rejuvenation strategy of applications.

stimulate the system device, which represents the physical mobile with its H/W and S/W configurations, workload and kill frequency. The experiment was performed every five and sixty seconds, with configuration of workload events such as touches, switches, using Monkey tool and storage space usage, in two modes, namely full and normal. Resource utilization metrics (memory and storage) with system operations (garbage collection and tasks) were tested in relation with SA. In addition, an empirical analysis was performed on recent Android devices and pointed out the processes (System Server, Surface Flinger, and System UI) and components of Android OS (such as Activity Manager) affected by SA. Metrics useful as indicators of SA to schedule software rejuvenation actions were also tested. As a result of those experiments, it was recommended that Android software rejuvenation should select a measurement-based approach to be familiar with the workload conditions. An earlier report [9] determined the main objective of the research to discover SA in and to study the influence of warm rejuvenation strategy (application restart) in Android OS. It was concentrated on available memory as aging-related phenomena and utilized five experiments; experiments one and two were conducted to confirm whether aging can happen in Android; experiments three and four verified whether warm rejuvenation can work on Android aging recovery; experiment five was performed to find out whether Android SA is reversible. Also, a mathematical modelling (Markov chains) was implemented to predict the anticipated time for Android OS to go into the aging condition. As a result of those experiments, the presence of aging in Android was noticed. In addition, the warm rejuvenation (application restart) had a small influence on aging recovery or alleviation process. The authors assumed that the only way to deal with this issue when occurs is to reboot OS or use other unknown technology strategies that may be developed in the future.

SA Analysis and Metrics
This section will discuss the SA problem in main mobile resources such as RAM and storage.

A. SA in RAM
RAM is a valuable resource, precisely on smart phones. It is a critical resource for attaining good performance, but many studies showed that it is often affected by SA. Android provides a complicated mechanism to manage memory, both at the kernel level and the Android frame work level Some of these managements include application life cycle, application process caching, and reclaiming memory through OOMK and LMK [8]. When an application exits, activity manager service does not kill the process but instead places it in the Least Recently Used (LRU) list, in case the user returns to use it again to minimize application response time. The majority of Android devices have a restricted memory, and running applications in (out of memory) or (low memory) states will be high. Therefore, when most of the applications are launched, Android needs to free memory that influences the application LTs, which is the period between touching the application icon on screen (requesting an activity) until the first view of contents of screen for interaction. The LT of application plays a pivotal role in user experience of the application and, thus, memory metrics are included to analyse memory usage in the experiments and their effects on application LT. List of some memory metrics are shown in Table-1 [8].

B. SA in Storage Space
Internal storage is used to save files that are related to specific applications, where any other application cannot have access to them. The Android system provides an individual directory (private) for each application to organize any files the application requires [10]. The availability or not of storage space in experiments (in terms of free space) may or may not influence the app LTs. Hence, storage metrics are included to analyse the storage space usage. Some of storage metrics are shown in Table-2 [6].  [13], ADB tool [14], and /proc File System [15].

SA Statistical Methods
Several statistical methods are used to analyse the data collected over time. Some of statistical methods used in this paper include Mann Kendall (MK) test [16], Sen's slope estimator [16], Spearman's rank correlation coefficient [17], and Design Of Experiment (DOE) [18,19].

The Designed Module
The designed module of the paper consists of many parts, including experiment setup, experiment design, experiment factors and levels, and experiment plan. A. The Experiment Setup.
The following represents a complete view of the experiment platform which consists of several parts:  The testbed: The conducted experiments were implemented on Samsung Note3 mobile phone equipped with 3GB of RAM and 32GB of internal storage. The mobile was installed with an Android 5.0 Lollipop operating system. A PC computer with 8GB RAM and 500GB hard disk was used to send user events and inject them into the mobile to gather the required information. The OS installed on the PC was 64-bit Ubuntu 18.04.1 LTS.  User events generator: to simulate user events, Monkey tool was used to generate such events like, touch, motion, trackball, navigation, majornavigation, syskeys, appswitch, anyevent, flip, and pinchzoom. In each experiment, 10,000 events were injected into the mobile with 500 milli second (ms) throttle (delay) between each group of events. These events stress the mobile OS over a period of time in order to accelerate the appearance of SA.
 Test applications: Two sets of applications were used in the experiments, namely the third party applications which were downloaded from play store. and system applications which were already installed by the manufacturer and cannot be uninstalled in the mobile phone.  Data collection: In this part, eight experiments were conducted with different combinations of factors at each level. Each experiment was conducted t for one hour. During each experiment, five applications (third party applications or system applications) were launched and killed periodically every thirty seconds. A bash script was developed in order to launch and kill applications, generate events, collect data, and save the collected data to files in order to analyse them later using statistical methods mentioned in section 4. The collected data are: -The applications LTs that are collected every thirty seconds and represent user perceived response metrics.
-RAM and Storage information that is collected every thirty seconds and represent system perceived response metrics. In this paper, dumpsys, logcat and /proc were used to gather the aforementioned metrics. Statistical methods were used for analysing the collected data to discover the existence of SA in the mobile.

B. The Experiment Design
The experiment design ( Figure-1) is passing through many steps. Collecting LTs of applications with RAM and storage metrics information was performed every thirty seconds. The median value was selected from the collected LTs of applications every thirty seconds at each time period. The MK test and the Sen's slope estimator were applied to the median LTs of applications with RAM and Storage metrics information every thirty seconds to check for trends and finding the slopes, respectively. The Spearman's rank correlation coefficient was applied between the slopes of RAM metrics and the slopes of median LTs of applications collected every thirty seconds to find the metrics that affect the LTs of applications. The same method was applied to the slopes of storage metrics and the slopes of median LTs of applications collected every thirty seconds to find the metrics that affect the LTs of applications.

C. The Experiment Factors and Levels
To stress the Android OS broadly and to bring out the hidden SA issues, the tests were run under many different configurations and stress applications, which represent the factors of the experiment plan. Three factors were considered in this paper and derived the experiment plan by varying the combinations of levels of these factors according to DOE (Table-3). A full factorial design of the experiments conducted on the mobile was adopted (Table-4).

Results and discussion
In this stage, the Sen's slope estimator for median LTs of applications, RAM metrics, and storage metrics was computed statistically. These Sen's slopes (values) were used to find the correlation between LT degradation with RAM and storage metrics, using Spearman's rank correlation coefficient. The Spearman's rank correlation coefficient was used to compute the correlation between median LT slopes of applications and memory metrics slopes across all the conducted eight experiments. The results of the correlation test are shown in Table-5. Correlation values between negative one to positive one, except zero value, imply that the correlation exists as the LT and memory metric both increase or decrease at the same time, or when one increases and the other decreases. -0.143 0.736 By taking a significance level of 95% (α = 0.05), no one of memory metrics was found to be correlated to LT in a statistical significance way, according to the p-values of the metrics (P>0.05). The results of the correlation between LT and RAM metrics did not mean that there was no correlation at all in all metrics, for two important reasons: - The duration of the experiment, which was one hour, could be increased to many hours or until the device will be in an unstable condition. This might show a correlation between LT and memory metrics. - The type of workload could also be a cause of this correlation result. In the same manner, Spearman's rank correlation coefficient was also used to compute the correlation between median LT slopes of applications and storage metrics slopes across all experiments. The results of the correlation are shown in Table-6. By taking a significance level of 95% (α = 0.05), sectors read and reading time metrics were correlated to LT with a statistical significance (P-value<0.05). The results of memory metrics were also affected by the duration of the experiment and the type of the workload used during it.

. Conclusions
Eight experiments with different factors and levels were conducted in order to recognize the existence of SA in Android mobiles. LT, memory metrics, and storage metrics were used for the detection of SA. The results of the experiments showed that none of memory metrics has an influence on LT of the applications in experiments conducted every thirty seconds, according to p-values greater than 0.05. Also it was noted that sectors read and reading time metrics were correlated to LT of the applications in experiments conducted every thirty seconds.