Power Guru: Implementing Smart Power Management on the Android Platform

Hans Fredrik Unelsroed

Computer Science UCSB Email: hfu@cs.ucsb.edu

Per Christian Roeine

Computer Science UCSB Email: roeine@cs.ucsb.edu

Fahad Ghani
Computer Science UCSB Email: fahad@cs.ucsb.edu

AbstractImproving battery life in mobile devices has become a very important area of research. Other components, like the CPU, has had some major upgrades while batteries development has lacked the same progression. Our goal is to implement a smart power management system that looks at the currently running applications and gives the user suggestions on which applications should be killed in order to optimize the battery life of the device.

I. I NTRODUCTION Mobile devices have progressively become more powerful with power consuming technologies like GPS, WiFi, 3G and 3GS now inherent to them. Furthermore, more power hungry applications, for example video streaming applications like YouTube, are being built and used frequently by mobile phone users thereby putting more stress on battery life. However, the battery technology has not been able to keep up with this rapid progress and there is a need for mechanisms that manage the usage of battery in smart ways to improve battery life, at least till the battery technology catches up. Power Guru is an application for the Android 1.6 Platform that attempts to optimize the battery life of the device it is running on. It does this by asking the user which applications he/she wants to prioritize and then makes suggestions on which applications should be killed in order to maximize the remaining battery life. This idea is novel compared to previous work done in the eld because it gives the user suggestions, other solutions that deal with task management often give the user the information needed to make a decisions, but doesnt use that information in a way that automates a lot of the decision making. In order to show that our solution is more effective than existing solutions we will run through several typical usage scenarios and show how long the battery lasted, we will compare out application with other common approaches. The rest of this paper will be structured as follows. In Section 2 we will look at the motivation for doing power management and look at previous work done in the eld. Section 3 gives an insight into how our solution works. And Section 4 shows how well our solution is performing by doing quantitative evaluation. II. BACKGROUND Previous research has explored ideas at multiple levels of a phones usage: at the OS level, MAC layer, network layer (the

non-application layers) and application layer. The solutions that are in the non application layer are very unobtrusive to the user, they tend to be ne grained and use low level optimizations. Examples of OS level power management are optimizing the use of each CPU cycle, optimizing memory usage and can even include turning down screen brightness after a set amount of idle time. For example, CoolSpots [3] focuses on dynamically (based on bandwidth requirement) switching between bluetooth and wi to conserve power, whereas the authors of the paper Integrated power management for video streaming to mobile handheld devices[4], focus on integrating several optimizations at the OS level and middleware techniques. There have also been a lot of work at the hardware level, for example reducing the power consumed by the WiFi modes (eg. Wi PSM) and the bluetooth adapter (eg. BlueCore3).

Similarly, there have also been several applications developed lately which focus on power management on these devices. Such solutions tend to be more coarse and use more high level information. For example one such application made for iPhone is Battery Magic[6], which just provides the user the time left for a xed number of activities that they can do (like game play). There are such applications for Android platforms too: Battery Booster[1], which focuses on managing the hardware features by autonomously turning on/off 3G, WiFi, etc. However, it doesnt deal with process level management at all. There are process managing applications available too, for example ProcessManager[2]. Similar examples are: Task Panel, Advanced Task Killer, Task Manager and Fpt System Manager. All these applications more or less list all currently running applications with information about their memory consumption and give the user the ability to kill or suspend applications. But these applications contain no autonomous decision making or suggestions on which applications would be the best to kill in order to increase battery life. There are also applications that can modify CPU settings, this can be used to improve battery life by under-clocking the CPU, making the peak power consumption lower. But this solution naturally has some drawbacks, such as decreased peak performance.

III. I MPLEMENTATION Our application is to be implemented on Google Android Dev phone G1, which runs the Android 1.6 rmware and is one of the rst android powered mobile phones. To develop our application we are using the public APIs exposed by Google. Inherent to any battery managing application is an algorithm to nd out the most power hungry applications and let the user know about them. The user can then decide which applications he wants to keep and which he wants to terminate. PowerGuru works on a similar work-ow but also helps the user to make that decision by providing suggestions. There is a direct correlation between the amount of CPU time an application takes up and the amount of battery it uses up[6]. Therefore we use the CPU time the application is taking up to nd out the most power hungry applications. We also nd out the hardware features an application is using. If an application uses an internet connection, then it will eat up more power during transmissions over the wi (GPRS, 3G, bluetooth) network. Using both these factors, we calculate an applications Power Rating with more the power rating, the more power hungry the application is. We also calculate a system wide power rating which we use to determine the remaining battery life. Currently we do this by summing all the power ratings of the running applications and then using that sum as an indicator of how fast the battery will be drained. If the sum is between 0 and 25 we estimate that the power usage is low, between 25 and 50 is medium and over 50 is high. We plan on implementing a more dynamic algorithm for this part later. So far we have focused on the ground work of our application and we have a working user interface (UI) along with a code structure that gets all the necessary information about battery status from the OS and uses this information together with information about the currently running processes to determine what applications should be killed. However, we are facing several difculties in getting the process specic information from the OS, specically the CPU time and the battery statistics. After a long search we realized that there are no ways to get this information from the public developer APIs. There are two possible ways to evict this information from the OS: (a) using the system les present in the /proc folder of the android OS lesystem, (b) loading our own android OS image into the development environment and working with private APIs, i.e. APIs not released in the ofcial Android SDK. Even though the former method is simpler and effectively provides CPU information about all the processes, it is not very reliable and furthermore we are not able to extract information about the hardware features such as wi and bluetooth. The second method offers more detailed information availability and should give much more reliable results. However, since these APIs are not public and ofcial, technical support for them is very lacking and thus it could take way more time to use them for development. Secondly, using private APIs is risky as they might not be supported in future releases of the Android OS, thereby leading to possible

failure of the application on them. But looking at the limited information method (a) gives us, it might be a better idea to go with the second method. The UI of the system is intended to be as simple as possible for ease of use. When the application is started, a list of current running processes or applications is given to the user along with their power ratings. The processes are classied into low, medium and high power consuming applications according to these ratings. The application also calculates the remaining battery life with the current load. The user is asked to select the applications that he wants to prioritize (i.e. the applications he wants not to be killed) and then the application suggests the non-prioritized power hungry apps that could be killed. IV. E VALUATION Evaluation of battery life is a difcult task because of several factors, mainly the amount of time it takes to drain the battery once and run a new test. Evaluating battery life time cannot be done on an emulator, rst of all because there is no support in the Android emulator software, and second, it would not have provided accurate results. Also there could be several extraneous factors which may affect the battery life and may lead to erroneous results. For evaluation of effectiveness of our application, the metric we will use is the battery life (in hours). We are currently in the process of collecting battery life time for various scenarios of phone usage: standby, no data communication, with data communication (for combinations for all three modes: WiFi, 3G and blutooth), call time, and other active applications (number and duration of running). After the implementation is completed and PowerGuru is deployed on the phone, we will conduct the same experiments and measure the battery life time to nd out if the application helps increase the battery life time or does it itself eat too much power so as to decrease the lifetime. We will also record the remaining battery life estimated by PowerGuru at various times (3 times should be good) for all scenarios and measure if the estimation is accurate as the battery drains out. Also, it would have been a good idea to run the tests for at least two different mobile phones. However, because of a lack of availability of another android phone (and sufcient time), we wont do this. Perhaps, as we go ahead developing the application, we will be able to nd more use cases and test cases to evaluate the applications performance. V. P LAN FOR THE REMAINING FOUR WEEKS Our main focus right now is to evaluate and iterate the algorithms for determining remaining battery time and for assigning power ratings to applications. We also need to connect the UI with the rest of the code, currently they are in two different projects. R EFERENCES
[1] http://www.androlib.com/android.application.com-sangodroidbatteryboosterfull-zAjw.aspx [2] http://curvesh.com/apps/processmanager.htm

[3] CoolSpots: Reducing the power consumption of wireless mobile devices with multiple radio interfaces, Trevor Pering, Y.Agrawal, R.Gupta, Roy Want [4] Integrated power management for video streaming to mobile handheld devices, S.Mohapatra, R. Cornea, Nikil Dutt, Alex Nicolau, N. Venkatasubramanian [5] http://developer.android.com/ [6] Battery Magic, www.myNewApps.com, Apple appstore