CHAPTER ONE

INTRODUCTION

The rapid development of technology has led to a shift in how we communicate with the world. Computers themselves have also changed significantly since their inception, from analogue machines, to large electromechanical computers and transistor computers. Nowadays, many people own personal computers, varying from desktops to laptops. In addition, they are also using smaller, portable computers such as tablets and smartphones. Each iteration of devices enabled us to accomplish tasks that were previously not possible.  The rise of smartphones has enabled us to remain connected with everything, regardless of our location. They are capable of accessing the internet, with applications ranging from social media networks to banking services. With over 3 billion users as of June 2014 [1], this technology has affected a significant portion of the world. However, the smartphone itself was also developed through a series of iterations.

Initially, smartphones were large, bulky, expensive, and only used in enterprise settings. One of the first multipurpose phones was the IBM Simon, released in 1993 [1]. The purpose of this device was to create a “Swiss Army Knife” phone that combined many features. It functioned as a mobile phone, a PDA and a fax machine.  The device was much larger than the modern-day smartphone and costed $899 USD, the equivalent of approximately $1500 USD in 2017.

Development of smartphones continued, with devices such as the Nokia 9110, Blackberry 5810, and the Palm Treo 600. Each device introduced functions that would become standard features on modern smartphones, such as keyboards, e-mail, web browsing, and coloured screens. Another notable inclusion is the Palm Pilot, a personal digital assistance device

(PDA). While the Palm Pilot was not a phone, it offered many smartphone features such as calendars, contact lists, e-mail and web browsing. These devices were then used in conjunction with the cellphones of that time.

The major shift into modern smartphones came from Apple in 2007, when the iPhone was released [1].  The Apple Smartphone featured a 3.5-inch capacitive touch screen, and combined the aspects of a phone, an iPod, and internet access. It also removed features such as keyboards and stylus’ in favour of touchscreen interaction. The following year, the Android operating system was released on the HTC Dream. Android is an open source mobile operating system. While the initial adoption of Android was slow, as of 2016 it represents 81.7% of the smartphone market.

Figure 1: Older smartphones from 1993-2003 [1]. 

Statement of problem

The smartphone can be viewed as an extension of the computer, allowing us to perform the same tasks on a pocket-sized device. Developers have embraced this medium and created accessible mobile equivalents of the online services that we use. In addition, they are also creating new, unique applications by leveraging the variety of sensors on the device. However, they must compensate for the lack of resources in comparison to traditional computers.

Despite the rapid growth of this technology, this service has not been perfected and has substantial room for improvement. A large amount of research has led to the current state of smartphones, and much more is required to tackle the outstanding issues that remain. One of the biggest issues that researchers face is the limitations due to battery life. While smartphones are capable of many tasks, their battery dictates how much they can accomplish. This problem can be addressed in a few ways. Developing energy efficient applications would reduce the strain on the battery. This could be accomplished by creating best practices and encouraging developer adherence. However, the challenge of this approach is enforcing these practices upon the community. As applications can be created by anyone, it would be impossible to ensure that all applications meet strict, energy-related guidelines. Instead of monitoring how applications are created, a more viable alternative would be to monitor how applications are run. By examining how energy is consumed on a device, feedback can be given to the user on how to extend their usage.

Research Question

The research question to answer is can an application monitor a user’s device to determine the average consumption rate of every application? The proposed solution would track the active applications and remaining battery percentage on a user’s device, also known as the state of charge (SOC). These readings would then be analyzed in order to determine how much battery life each application consumes. This information is currently unavailable to developers programmatically due to limitations of the Android API. Access to this information can provide a foundation for predictive methods that manage battery consumption based on user behaviour. Examining battery life is an important component of smartphone progression, as it is the power source of the device. The small nature of mobile devices limits the size of the battery, therefore energy conservation and consumption optimization play an integral part in addressing this issue. As user expectations of smartphone functionality increases, a greater strain will be placed on its battery. Therefore, it is important to examine areas of battery conservation to ensure a user can complete their tasks before their battery is depleted.

While battery saving applications and other conservation techniques exist, battery life continues to be an issue, meaning current implementations are insufficient. The majority of battery saving applications approach the problem by suppressing and limiting the user’s functions. They provide a convenient hub to toggle the resource-heavy functionality of the device. However, this approach limits the user experience, as they must manually alter and manage their levels of consumption. In addition, this is also a tedious process that users can forget to do during their daily routine.

My contributions to the topic are as follows: Designed an application that reads in user battery information and saves it to a server, analysed the data in order to predict the consumption rates of each application, discussed the limitations of this approach and changes that may be required, and created a set of sample data lasting 3 months for future use.