AASMP – Android Application Server for Mobile Platforms

Jian-Hong Liu1 Jing Chen2 Yi-Li Wu3 Pei-Li Wang4 Institute of Computer and Communication Engineering

Department of Electrical Engineering, National Cheng Kung University Tainan City, Taiwan, R.O.C.

{liuken1, q360040783, q360010964}@rtpc06.ee.ncku.edu.tw, jchen@mail.ncku.edu.tw2

Abstract— This paper presents the development of an Android Application Server for Mobile Platforms (AASMP). It is motivated by the widespread cloud computing and the popularity of mobile platforms, such as smart-phones and tablet computers, running Android system. The main purposes of developing this AASMP include: to allow deploying Android applications on a server to be accessed by client-side users, not necessarily operating an Android platform, through a browser software without installing any plug-in modules; to support offloading the execution of existing Android applications to powerful server-side environment with neither modifying nor porting needed; to lay a foundation for developing server-side Android applications or services which are provided with the resources normally limited on mobile platforms. AASMP fully supports Android applications and, when client-side platform is installed a device management daemon, it is capable of accessing motion sensing devices that are commonly equipped on mobile platforms. In addition, AASMP is built with a con-nection manager in order to concurrently serve two or more clients. Performance evaluation showed acceptable results although data transmission and networking may incur cost or overheads. AASMP therefore may serve as one demonstrating example in providing mobile platforms an alternative to re-mote access and sharing application programs.

Keywords— application server; mobile computing; Android; cloud computing; embedded systems; thin client.

I. INTRODUCTION Embedded system products nowadays are widespread

more than ever. In particular, smart phones, MP3 players, netbook or tablet computers, and other mobile or handheld personal devices with sophisticated functionalities including Internet access capability have become indispensable in our daily life. With the emerging technology of cloud computing, the model of delivering services through Internet for location-independent computing is becoming more and more popular. It is obvious, although might be arguable, that embedded system with the capability of Internet connectivity would benefit relatively more compared to most desktop systems in an environment of cloud computing. One of the major keys, as can be observed, to this would be offloading executing application software to one or more powerful platforms in the “cloud” via providing web-based services.

As browser software becomes one must-have application for accessing Internet, more and more web services as well as applications are deployed to be operated through browser software. However, quite many of those applications rely on support from associated plug-in modules installed into the browser software. Although installing plug-in modules is common in ordinary computer systems such as desktop PC or notebook computers, it becomes an issue in the arena of mobile platforms due to various reasons such as platform variety or system restrictions. This issue not only imposes difficulty and results in incurring extra cost in developing web-based services or applications, but also makes a hurdle in taking advantages of cloud computing when the browser is used as the main portal access to cloud computing.

In attempting to solve the issues mentioned above, an approach, namely ACES which stands for Application Cloud for Embedded Systems, has been proposed [11][12]. It provides a mechanism to help set up a cloud computing environment that supports offloading executing existing applications over Internet. The main goal is to achieve an execution platform based on Internet for embedded systems, which can be either a stand-alone cloud computing environment or part of another one, on which existing applications can be deployed as well as executed, and which is accessed using a browser with no plug-in installed. Most notably, ACES allows applications which are not developed for cloud computing to be deployed in the cloud without incurring any effort in either modifying or porting the applications. The development of ACES relies on a mechan-ism, on the server side, to transform the original application presentation into web presentation expressed by HTML and JavaScript, which are common features of typical browser software. Therefore, ACES requires, on the client side, only a plug-in-free browser to accomplish the benefit of cloud computing while allowing existing applications to be reusable in the environment of cloud computing. In addition, ACES can be applied to not only embedded systems but also ordinary computer systems such as desktop computers.

This paper presents the work in enhancing ACES through developing AASMP, short for Android application server for mobile platforms, which employs HTML5 technology and supports accessing client-side peripheral hardware devices. It

2013 IEEE 16th International Conference on Computational Science and Engineering

978-0-7695-5096-1/13 $31.00 © 2013 IEEE

DOI 10.1109/CSE.2013.100

643

2013 IEEE 16th International Conference on Computational Science and Engineering

978-0-7695-5096-1/13 $31.00 © 2013 IEEE

DOI 10.1109/CSE.2013.100

643

is motivated by the widespread cloud computing and the popularity of Android system running on mobile platforms, such as smart-phones and tablet computers. The purposes of developing AASMP mainly are: to allow deploying Android applications on a server to be accessed by client-side users, not necessarily operating an Android platform, using a browser program without installing any plug-in modules; to support offloading the execution of existing Android applications to powerful server-side platforms with neither modifying nor porting needed; to lay a foundation for developing server-side Android applications or services which are provided with the resources normally limited on mobile platforms. Beside, the functionality of AASMP fully supports Android applications and, when the client-side mobile platform is installed a device management daemon, is capable of accessing hardware devices commonly equipped on mobile platforms, such as GPS or motion sensor. For example, the Google Map application running on AASMP could read the GPS data from client device. Fig. 1 depicts the operating scenario of AASMP that any mobile platform equipped with a HTML5 browser can login AASMP and execute Android applications on it.

The most significant feature of AASMP is that it can concurrently create a virtual Android smart-phone for each user on client side as the scenario shown in Fig. 1. With this AASMP, service providers can deploy Android applications or services on server without downloading to client-side platforms. In addition, it provides a billing solution based on the usage of application and may prevent application from unauthorized distribution or dumping from client devices.

Fig. 1. Scenario of AASMP

This paper presents the design and implementation of AASMP. Following this introduction, the remaining of this paper is organized as follows. Section II discusses some related works. Section III describes the system architecture and the implementation of AASMP. Section IV presents a demonstration while its performance evaluation is presented in Section V. Finally, Section VI concludes this paper and discusses possible future works.

II. RELATED WORKS Many research works focused on separating application

view from execution logic or transferring application view to

remote display have been done. The technology is commonly called thin client. As summarized in Table I, such system can be commented by its rendering program and the method of drawing image. While a service transmits the snapshot of an application, a program on client device is needed to receive and present this snapshot. Three types of such programs are observed: standalone special-purpose program, browser with plug-in and browser without plug-in. Using a browser as the client program appears more appreciated in fitting the trend since most, if not all, devices with Internet connection are equipped with a browser. However, such implementations usually rely on installing plug-ins for browser software and installing special-purpose application or plug-ins on client-side devices might be problematic as some devices are not allowed to do so. Therefore, rendering image without plug-in support in a browser would be the most suitable way, such as the system built with Flashproxy.

TABLE I. SUMMARY OF REALIZING THIN CLIENT Rendering

ProgramDrawing Method

Standalone program

Browser w/ plug-in

Browser w/o plug-in

Copy-and-PasteImage

Redar[19], Virtual Smart-

phone[2]

Universal plug-in[9],Auto-offloading framework[19]

Flashproxy[13]

Drawing Command THINC[1] Plug-in built-in Browser Built-in,

JavaScript

There are also many works on accessing remote devices.

A remote virtual peripheral framework [4] is introduced for controlling one machine by receiving input command from the other devices. For instance, the sensor device on modern smart-phone can be used as input devices to play a game running on PC. In order not to modify program, the authors utilize DBUS and character device on Linux to emulate devices which are virtually connected. The discovery and binding of peripheral devices are through UPnP. Tayor proposes a network device driver to support I/O devices that are separated by the network from application to which they are supplying data [16] [17]. It also does not require modification of origin program. This architecture makes the network invisible to both device and application. Thus, the application running on server can still access I/O devices on client-side devices.

TABLE II. WEB TECHNOLOGIES FOR BI-DIRECTIONAL COMMUNICATION

Create New Connection Data Flow Performance

Polling Yes Client-Pull Low Long Polling Yes Client-Pull Middle

XHR Streaming No Server-Push Good IFrame Streaming No Server-Push Good

WebSocket No Server-Push High

Websocket, part of HTML5, is a protocol which enables

bi-directional communication between client and server. It extends HTTP by removing the limitation on bi-directional communication. Therefore, a websocket connection must

644644

start with a normal HTTP connection. Then, a handshaking protocol is enforced to upgrade the HTTP connection to websocket connection. Table II lists several traditional web technologies which implement bi-directional communication based on legacy HTTP. Compared with these technologies, websocket provides best performance.

III. SYSTEM ARCHITECTURE In building an environment for AASMP, two techniques,

namely XHTML5 and Remote Device Access (RDA) are developed as its foundation. XHTML5 provides an execution environment on server side to run Android applications while accessing motion senor devices on client-side mobile plat-form is enabled through RDA. Fig. 2 depicts the architecture of AASMP which shows Clients, Connection Manger (CM), System Manager (SM), and Virtual Execution Environment (VEE). Once a client connects to AASMP, one VEE will be created by SM to serve the client. An Android application program can then be executed on the Android emulator in the VEE. The communication between client and AASMP is accomplished by HTTP that is handled and managed by CM. Therefore, client-side user can operate the browser running on mobile platform to run Android applications on AASMP. The details are described in the following subsections

..

.

Fig. 2. The Architecture of AASMP.

A. XHTML5 As described above, one of the purposes of this work is

executing applications at remote server and allowing users to interact with these applications from mobile platforms. This is achieved through XHTML5, which. as the name implies, is the combination of X server and HTML5.

HTML5 is the next version of HTML standard and it is still under development. It introduces various features to make browser software easy to include and handle complex content, such as multimedia or graphic drawing, without any plug-ins installation. XHTML5 incorporates two features of HTML5, namely canvas and websocket. Canvas is used to draw graphics, on the fly, in web pages and provides many functions to support 2D drawing, while websocket improves

the communication by setting up a full-duplex channel so that the server can proactively push data to client instead of waiting for being pulled by client.

X window system (the latest version is commonly known as X11) is a software system which includes a set of network protocols. It provides a basis for implementing graphic user interfaces (GUI) for networked computers and consists of X server and X clients. An X client, also called X application, executes its application logic and requests X server to draw user interface while X server assumes the responsibility of managing the display hardware and handling the drawing request from X client. The interaction between X server and X client is the basis of X application development. At the start of an X application, it must firstly connect to an X server. After the connection is successfully built, the X client typically listens on events forwarded from X server or sends requests to X server. As a general pattern, an X application executes looping to handle events and send requests based on processing events. The interaction between application logic and user interface in X window system can be manipulated to fit the functional requirements of AASMP.

Fig. 3 shows the architecture of XHTML5 and outlines the basic flow of control and data. When the client-side user operates the browser running on mobile platform to execute applications on server, the connection is set up between the client and the server, which relies on HTTP protocol. In order to have better efficiency, once the connection arrives at CM, CM will upgrade this HTTP connection to websocket connection. CM is implemented using libwebsocket [22].

Fig. 3. The Architecture of XHTML5.

After the websocket connection is built, the name of the application to be launched on server side will be sent to SM through CM. SM, then, starts a VEE to execute the selected application. SM also takes the charge of terminating a VEE in response to the request issued by CM. A VEE is composed of an X application and an X server. The selected application is thus the X application in VEE. For AASMP, it is Android emulator. SM has three main components, namely X server manager, application manager and input handler, as shown in Fig. 3. The X server manager takes the charge of starting and

645645

terminating an X server for each selected application, while the application manager is responsible for launching the selected application to run on its paired allocated X server. In other words, a VEE is created for each request of launching an application from client. The relationship of each pair of allocated X server and the selected application is maintained by SM. The SM therefore is capable of serving more than one request from different clients concurrently.

The input handler of SM takes the charge of handling keyboard and mouse input events triggered on client side. These events are captured and sent back to SM. According to the information of X servers kept in SM, these events will be fed to the corresponding X server as shown in Fig. 3.

In order to run any X application in VEE with neither modification nor porting, the X window commands related to drawing and displaying must be intercepted and manipulated by the X server. Table III lists these related commands. The X server in Fig. 3 is modified to redirect theses command to client via CM. On client side, the new feature of HTML5, namely canvas, is used to implement a drawing function library and the received X commands are parsed to draw or display the result on web page by utilizing canvas API. The transmission of X window commands between client and CM is achieved through websocket described earlier.

The XHTML5 described can be applied to execute all X applications. The development of AASMP, however, needs a way to execute Android applications on server. This is done by porting the Android emulator provided by Google, which is an X application and open source software. Therefore, Android applications can be executed in server-side Android emulator and the output produced by the applications can be redirected and displayed on client-side mobile platform. In addition, the touch events triggered on client side are sent to server and translated into mouse events.

TABLE III. INTERCPTED X WINDOW COMMANDS

CreateWindow PolyLine RenderCompositeGlyphs32 ConfigureWindow PolySegment RenderCompositeGlyphs16 MapWindow PolyPoint RenderCompositeGlyphs8 UnMapWindow PolyArc RenderCreatePicture FreePixmap PolyFillArc RenderFreePicture CopyArea FillPoly RenderTrapezoids PolyText8 PutImage RenderComposite PolyFillRectangle RenderAddGlyphs

B. Remote Device Access In addition to touch events, modern mobile applications

generally require more complex input events, such as device rotation. Thus mobile platforms are equipped many sensors nowadays. For instances, geolocation is obtained from GPS sensor, and gyro sensor can be used to check gravity. The XHTML5 described above can only manipulate touch events and keyboard events from mobile platforms. This limitation is because that browser has not enough permission to access hardware devices. Therefore, remove device access (RDA) is developed to compensate this shortfall.

RDA intends to enable Android applications running on server side to access sensor devices equipped on client-side mobile platform. Fig. 4 outlines the architecture of RDA and shows its four components, namely Remote Device Manager (RDM), Virtual Device (VD), Device Management Daemon (DMD), and HAL. As their names imply, RDM manages accessing the client-side devices from VEE. VD serves as the virtual device corresponding to client-side device. DMD is a program installed on client-side mobile platform to help access the sensor devices. HAL is the hardware abstraction layer of Android.

Fig. 4. The Architecture of Remote Device Access (RDA)

In order to make an Android application on server side execute as if it is executing on an actual mobile platform, VD is used to play the role, on server side, of a device equipped on the client-side actual mobile platform. RDM serves as another input handler of SM in XHTML5 and manages the device access according to the mapping of client and VEE. RDM must manipulate bi-directional data flows between the server and the client. Therefore, RDM feeds data readings from client-side device to Android emulator and conveys device control command issued from Android emulator to client side. For instance, GPS readings are collected by client device and sent to server. Similarly, but in opposite direction, commands issued to control the client-side vibrator are sent to client-side device from server.

To realize RDA, both Android framework and Android emulator, must be modified to incorporate the functionality of RDM. HAL is provided in Android as a set of interfaces in the framework to access hardware device. However, the system image running on the emulator does not implement the HAL well. Hence, more devices must be added to the HAL. In addition, devices access also needs to intercept or emulate and redirect to RDM as the virtual device in Fig. 4. In case the device access is a control command sent from emulator, RDM sends the command to the corresponding client-side device. If the device access is a read request, RDM requests a read from client and waits for the request data then returning to emulator. The device types currently supported are GPS, vibrator, and sensor. The sensor device could be any sensor device Android supported, such as accelerometer, magnetic field and gyroscope.

646646

C. Device Management Daemon Because accessing hardware device can not be achieved

from browser software, a special program is needed to be installed on client-side platform for this purpose and Device Management Daemon (DMD) serves this role in AASMP. DMD is designed as an Android application and running as an Android service which can execute in background. It uses websocket to handle the communication of bi-directional data flow although it is a separate program from browser software. To client-side users, DMD is simply an installable program which can be downloaded and installed on any Android platform.

Fig. 5. Device Management Daemon

Fig. 5 shows the components of DMD. The Connection Handler manipulates the communication between server side and client side, regarding accessing devices, using websocket connection. The requests sent from server are processed by Virtual Device Manager (VDM). At its startup, VMD will initialize all the supported devices and wait for commands to control or read the devices.

IV. DEMONSTRATION To demonstrate and verify the development of AASMP,

a test environment is set up, as shown in Fig. 6, for the purposes. A server running with all components of AASMP is set up and connects to Internet through wired network (Ethernet). Several mobile or handheld Platforms with Wi-Fi connectivity are prepared to login AASMP, which connect to Internet through a Wi-Fi access point. In addition, Android smart-phone is used for testing the functionality of AASMP through 3G connections. The demonstrations are divided into two parts. One is the demonstration of XHTML5 using browser software on a laptop computer and the other one is AASMP demonstration including RDA.

Fig. 7 shows the demonstration of XHTML5. A laptop computer running Linux operating system is used as the client-side platform. The LCD at front in Fig. 7 is the display of the laptop computer that shows a browser connecting to the server. The screen at back in Fig. 7 is display of AASMP that shows the application program executed by the client. The launched programs, namely xcalc and gnomine, in Fig. 7(a) and (b) are classic programs in X window. Figure 7(c) demonstrates input mouse event on browser and the display of both server and client show the same frame.

Fig. 6. The Test Environment for AASMP

The second part of the demonstration shows accessing AASMP from mobile platforms and the results of remote device access. DMD, as mentioned earlier, is firstly installed on client-side platforms. The picture Fig. 8(a) shows the UI of DMD. There is an input field to set the IP address of AASMP. The start service button and stop service button in the UI are used to activate and deactivate DMD respectively. In order to activate RDA, DMD must be activated before using browser to login AASMP. However, if the function of RDA is not needed, the part of DMD can be ignored.

(a) gnomine: A minesweeper game

of X Window

(b) xcalc: A calculator program of

X Window

(c) Demonstration of input from client device

Fig. 7. Demonstration of XHTML5

Fig. 8(b) and Fig. 8(c) show operating the browser on mobile platform to use AASMP services. An HTC Butterfly, which is an Android smart-phone, is used here. The web page displayed by AASMP includes three buttons which are used to launch Android, send special input events, and resize the display. When Android is launched, its booting process can be seen on the web page, as shown in. Fig. 8(c).

647647

(a) UI of DMD

(b) Login Page

(c) Android executing

on AASMP

Fig. 8. AASMP Demonstration

Fig. 9 and Fig. 10 demonstrate accessing gravity sensor and GPS respectively. The client-side mobile platform used in this demonstration is Nexus 7 which is an Android tablet. Fig. 9 shows running an Android game program on AASMP, which uses gravity sensor to control trajectory of a moving ball. When the game executes, the user can slant the Nexus 7 to control the moving ball. DMD will send the readings of gravity sensor back to the server as requested by RDM. The game application running on AASMP can get the readings, control and display the moving ball.

Fig. 9. Demonstration of Accessing Gravity Sensor

Fig. 10. Demonstration of Accessing GPS

Fig. 10 demonstrates accessing the GPS on Nexus 7. The device on the left in Fig. 10 is the Nexus 7 that is executing

Google Map on AASMP. Google Map then shows the map according the location and movement of the client, which is determined from GPS readings. Furthermore, the application will track the client’s trajectory and update the map. There is a pointer showing the location and moving direction of the mobile platform. To prove the correctness, the right side in Fig. 10 is another mobile platform running on itself the same application program, Google Map.

The two features of AASMP, XHTML5 and RDA, can be executed independently. Therefore, mobile platform not supported by DMD can still use XHTML5 to access AASMP service, and a browser software supporting HTML5 is the only requirement. Table IV lists the platforms tested in this work. The table also lists the browsers executed on these platforms. As described earlier, DMD is implemented as an Android application, only Android platforms support RDA.

TABLE IV. TEST OF AASMP ON MOBILE PLATFORMS

Mobile Platform Browser Support of

XHTML5 Support of

RDA Nexus 7 Chrome Yes Yes

HTC Butterfly Chrome Yes Yes

iPad Mini Safari Yes No Mac Mini Safari Yes No

Laptop Chrome Yes No

V. PERFORMANCE EVALUATION This section presents the performance evaluation on

AASMP, including the latency of network transmission and update of remote device access. Although the overheads of network transmission may impose negative impact upon the performance and can not be overlooked, it is not considered here due to the unpredictable conditions of network traffic.

A. Network Transmission ACES, which is our previous work [11], is compared

with AASMP in this section. Figure 11 shows the RTT (round-trip time) of these two systems. ACES uses AJAX to transmit data and AASMP relies on websocket. The RTT is measured by issuing a request from client side and calculating the returning time of the request. From the result, websocket shows significant improvement at RTT. This is of much help in reducing the response time of AASMP.

Fig. 11. RTT of Websocket and AJAX

648648

Fig. 12 shows the bandwidth consumption of these two systems. In Fig. 12(a) a sliding text program is used that a text continually moves across. Instead of transferring entire bitmap, XHTML5 only transfers the string of text. Hence, XHTML5 is more efficient than ACES. However, Fig. 12(b) shows the results of running a movie playing program that frequently updates entire screen display. Because ACES transfers compressed data, ACES consumes less bandwidth than XHTML5.

(a) Sliding Text

(b) Playing Movie

Fig. 12. Transmission Byte of XHTML5 and ACES

B. Remote Device Access Latency As described previously, the request of accessing device

is forward to client-side platform. Thus, some latency incurs between the request and the response of the request. Two approaches about data update of remote device are designed and the latency of each approach is measured. Fig. 13 depicts the first approach which adopts active update and DMD will periodically transmit sensor readings to AASMP while RDM receives and stores the data into a queue. When a request is received from Android emulator, RDM returns data from the queue. In the other approach, as showing in Fig. 14, DMD only returns sensor data after receiving request from RDM. Table V lists the measured latency of these two approaches. Apparently the active one shows more efficiency.

TABLE V. REMOTE DEVICE ACCESS LATENCY

Approach Min. Max. Avg. Std. Dev. Active (tA) 12 37 13.55 2.50 Passive (tP) 226 920 539.39 52.78 Unit: micro-second (μs)

AndroidEmulator

Remote Device

Manager

DeviceManagement

Daemon

Send Data

Send Request

Return Data

Send Request

Return Data

Send Data

tA tA

Fig. 13. Active Update of Remote Device Reading

Fig. 14. Passive Update of Remote Device Reading

VI. CONCLUSIONS This paper presents the development of AASMP, which

attempts to address the issues in running Android application on server side for mobile platforms over Internet. There are two features of the development, namely XHTML5 and RDA. XHTML5 provides the base execution environment to run Android applications while RDA enables application running on server side to access motion sensing devices equipped in a client-side mobile platform. The main advantage of AASMP is that existing Android applications can be deployed in their original format on the server without any modification. For client-side users, as XHTML5 utilizes HTML5, their mobile platforms, not necessarily running Android system, require only a compatible browser software without installing any plug-in modules to access AASMP. The RDA feature, due to the Android nature, currently supports Android platforms only. It is hoped that, on server-side, AASMP not only can offload the execution of Android applications to a more powerful environment, but also can lay the foundation for developing applications or services which are provided with the resources normally limited on mobile platforms.

There is still some space for further improvement on AASMP. First, supporting more devices, such as camera, audio, or storage, can be added to increase the functionality of AASMP. Second, a mechanism of remote application service access can be developed in order to allow an Android application to access remote service deployed on server side.

649649

Third, a disconnection between client and server would cause the running application to be closed. This introduces another startup time of Android emulator after reconnection from user. Therefore, a mechanism can be developed to maintain the application running status while the connection with client is lost and bringing back the application when the connection is re-established. Fourth, to alleviate the usage of network bandwidth in transmitting uncompressed data, an adequate data compression algorithm would be very useful. Finally, but not the least, supporting application migration in AASMP environment can be added. The mobility of mobile platform makes its distance to a server vary. Migrating an application to a server close to the client-side platform will reduce network latency and achieves better performance.

ACKNOWLEDGMENT This work is partially sponsored by National Science

Council (NSC) of Republic of China under the contracts NSC101-2221-E-006-270 and NSC102-2218-E-006-008.

REFERENCES [1] Ricardo A. Baratto, Leonard N. Kim, and Jason Nieh, “THINC: A

Virtual Display Architecture for Thin-Client Computing,” Proc. ACM Symposium on Operating Systems Principles, 2005.

[2] Eric Y. Chen and Mistutaka Itoh, “Virtual Smartphone over IP,” Proc. IEEE International Symposium on a World of Wireless Mobile and Multimedia Networks (WoWMoM), 2010.

[3] Eric Chen, Satoshi Ogata, and Keitaro Horikawa, “Offloading Android Applications to the Cloud without Customizing Android,” Proc. IEEE International Conference on Pervasive Computing and Communications Workshops (PERCOM Workshops), 2012.

[4] Felipe Gil-Castineira and Raja Bose, “Remote Virtual Peripheral Framework - Enabling Dynamically Composed Devices,” Proc. IEEE Consumer Communications and Networking Conference (CCNC), 2011.

[5] Takahiro Hirofuchi, Eiji Kawai, Kazutoshi Fujikawa and Hideki Sunahara, “USB/IP - a Peripheral Bus Extension for Device Sharing over IP Network,” the FREENIX Track, Proc. 2005 USENIX Annual Technical Conference, 2005.

[6] Yasujuki Honda, Takatoshi Okagawa, Ken Uchiyama, Shunsuke Kurumatnai, Masashi Toyam, Eric Y. Chen, Kazunori Ozawa, Daisuke Mizuno, and Jun Takada, “Thin Client Technology for Mobile Service Platform,” Proc. World Telecommunications Congress (WTC), 2012.

[7] Shih-Hao Hung, Chi-Sheng Shih, Jeng-Peng Shieh, Chen-Pang Lee, and Yi-Hsiang Huang, “Executing mobile applications on the cloud: Framework and Issues,” Computers & Mathematics with Applications, Vol. 63, Issue 2, pp. 573-587, 2012.

[8] Karthik Kumar, Jibang Liu, and Yung-Hsiang Lu, “A Survey of Computation Offloading for Mobile Systems,” Mobile Networks and

Applications, Mobile Networks and Applications, vol. 18, issue 1, pp. 129-140, 2013.

[9] Chia-Chen Kuo, Ping Ting, Ming-Syan Chen, and Jeng-Chun Chen, “Design and Implementation of a Network Application Architecture for Thin Clients,” Proc. the 26th Annual International Computer Software and Applications Conference, 2002.

[10] Youming Lin and Di Francesco, “Energy consumption of remote desktop access on mobile devices: An experimental study,” Proc. IEEE the 1st Internaltional Conferenc on Cloud Networking (CLOUDNET), 2012.

[11] Jian-Hong Liu, Jing Chen, Yi-Chuan Tai and Chen-Hao Shish, “ACES - Application Cloud for Embedded Systems,” Proc. the 11th IEEE/IPSJ International Symposium on Application and the Internet (SAINT), 2011.

[12] Jian-Hong Liu, Jing Chen, Yu-Chin Tsai, Yi-Chuan Tai and Chen-Hao Shish, “Supporting Audio Streaming in Application Cloud for Embedded Systems,” Proc. the 3rd International Symposium on Advances in Embedded Systems and Applications (ESA-2012) in conjunction with the 9th IEEE International Conferences on Embedded Software and Systems (ICESS2012), 2012.

[13] Alexander Moshchuk, Steven D. Gribble, and Henry M. Levy, “Flashproxy: Transparently Enabling Rich Web Content via Remote Execution,” Proc. the 6th International Conference on Mobiel Systems, Applications and Services, 2008.

[14] Barun Kumar Parichha and T. A. Gonsalves, “Remote Device Support in Thin Client Network,” Proc. the 3rd Annual ACM Bangalore Conference, 2010.

[15] Peter Simoens, Filip De Turk, Bart Dhoedt, and Piet Demeester, “Remote Display Soulutions for Mobile Colud Computing,” IEEE Computer, vol. 48, issue 8, pp. 46-53, 2011.

[16] Cynthia Taylor and Joseph Pasquale, “A Remote I/O Solution for the Cloud,” Proc. the 5th IEEE International Conference on Cloud Computing (CLOUD), 2012.

[17] Cynthia Taylor, “The Networked Device Driver Architecture: A Solution for Remote I/O,” Ph.D. Thesis, University of California, San Diego, 2012.

[18] Masashi Toyama, Shunsuke Kurumatani, Joon Heo, Kenji Terada, and Eric Y. Chen, “Android as a Server Platform,” Proc. IEEE Consumer Communications and Networking Conference (CCNC), 2011.

[19] Yang Zhang, Xue-tao Guan, Tao Huang, and Xu Cheng, “A Heterogeneous Auto-Offloading Framework Based on Web Browser for Resource-constrained Devices,” Proc. the 4th International Conference on Internet and Web Applications and Services, 2009.

[20] Yuedong Zhang, Zhenhua Song, Dingju Zhu, Zhuan Chen, and Yuzhong Sun, “Redar: A Remote Desktop Architecture for the Distributed Virtual Personal Computing,” Proc. the 5th International Conference on Grid and Cooperative Computing, 2006.

[21] Saman Zonouz, Amir Houmansadr, Robin Berthier, Nikita Borisov and William Sanders, “Secloud: A Cloud-based Comprehensive and Lightweight Security Solution for Smartphones,” Computer & Security, accepted manuscript, 2013.

[22] libwebsockets, http://git.warmcat.com/cgi-bin/cgit/libwebs ockets/.

650650