13-09-2013, 03:14 PM
Offloading Android Applications to the Cloud without Customizing Android
Offloading Android Applications.pdf (Size: 256.57 KB / Downloads: 32)
Abstract
Spreading more than twice as fast as PCs, smartphones
are quickly becoming the primary mean for Internet access.
However, smartphones today are still constrained by limited
computation resources such as CPU, memory and battery. In this
paper, we present a framework that automatically offloads heavy
back-end tasks of a regular standalone Android application to an
Android virtual machine in the cloud. This framework can be
deployed in the application layer without modifying the underlying
Android platform. It also features three metrics that consider total
response time, energy consumption and remaining battery life in
deciding whether a task should be offloaded.
INTRODUCTION
Spreading more than twice as fast as PCs, smartphones are
quickly becoming the primary mean for accessing various
services on the Internet. Hardware manufacturers and software
developers are racing to launch new models and applications to
entice mobile users on a global scale. One of the key advantages
of smartphones is their exceptional expandability that cannot be
rivaled by any conventional feature phone.
While the
expandability of a conventional feature phone is often bounded
by a carrier-specific system, most smartphones today are based
on a common platform on which developers everywhere in the
world can compete with each other to come up with killer-apps.
Smartphones today are not only bringing the vision of accessing
information anywhere and anytime[1] closer to reality, but also
becoming more useful every day in various imaginative ways,
such as augmented reality (AR), optical character recognition
(OCR) of handwriting, speech recognition and natural language
translation
EXTENDING FROM OUR PREVIOUS WORK
The framework proposed in this paper is an extension of our
previous work on Virtual Smartphone over IP[7]. This previous
work, as illustrated in Figure 1a), allows a user to create a virtual
Android image, which we call Virtual Smartphone, in the cloud
as a dedicated external execution environment of the user’s
physical smartphone. The user can offload an entire application
to the Virtual Smartphone and control the application through
PREREQUISITES
In order to transparently offload tasks to the cloud, we make
the following two assumptions on applications to be deployed on
our framework.
Implement Offloadable components as services
The Android architecture defines four types of application
components on Android: activities, services, content providers
and broadcast receivers[9]. The first two types of components
are of the most importance in the light of our framework. An
activity represents a single screen of user interface while a
service runs in the background. Our framework requires
developers to apply the Model-view-controller (MVC) design
pattern explicitly and rigorously to isolate the application logic
from the user interface. In particular, our framework assumes
that developers always implement compute-intensive tasks as
services and front-end user interactions as activities. This is a
fair assumption as it is encouraged and supported by the
Android architecture. We also assume that the activity and the
service run in two different processes. They can, however,
reside in the same or different application package files (APK).
DECISION METRICS
Our Service Offloader considers execution time, energy
consumption and remaining battery life in determining whether
offloading a certain service task would be beneficial at a given
moment. These considerations are expressed in three decision
metrics. In the following discussion, we refer to the physical
smartphones as clients and Virtual Smartphones as servers.
The first metrics deals with total time required to perform a
task. Let C be the number of instructions involved in a method
invocation, and Sc and Ss be the processor speed (instructions
per second) of the client and the server respectively. If the
amount of data transferred between the client and server is D
and the network throughput is T, the time it takes to transfer data
is D/T. The network latency is denoted as L. The subscripts u
and d denote upward (client to server) and downward (server to
client) transmissions respectively. With these we can derive the
relationship between execution speed and communication
overhead. In form notions, offloading of a task is beneficial if
the following is true.
CONCLUSION AND FUTURE WORK
In this paper, we have explored the design of an offloading
framework that enables an Android device to offload resource-
intensive work to a remote server in the datacenter. The design
decisions are driven by the intention to deploy the framework in
the application layer without modifying the underlying Android
platform and the application source code. In addition, we have
discussed three decision metrics that help our framework to
determine whether an operation should be offloaded given
various conditions of the smartphone.
As discussed in Section VI, the metrics we proposed in this
paper are only approximations. We plan to explore other
significant factors that may have impact on the computation and
energy cost models.