A Remote Desktop Application For Android

The aim of this project is to develop a simple-to-use remote desktop application which enables users to remote view contents of their desktop and view, create, edit and delete files and folders remotely. The application runs on a portable device (such as a cell-phone or tablet) which fully supports the Android mobile platform and is equipped with features like WiFi, touchscreen, document editor etc. An important goal of this endeavour is to keep the application user-friendly and easy-to-use.

The application uses the same protocol as Microsoft Windows for file sharing. Thus, implementing and using the application in a domain environment where each user has access to specific files and folders makes sense. This also enables true mobility and control over the user-account in a university or office setting.

In conclusion, the application works perfectly when the target remote machine is in the same network as the mobile device. For accessing a domain share, the device needs to be connected to the domain via VPN (Virtual Private Network). The application is expected to work in the same fashion with a VPN like it does over an actual network.

Chapter 1

Introduction

1.1 Motivation

In computing, the term remote desktop refers to software or an operating system characteristic which allows applications, often including graphical applications, to be run remotely on a server while being displayed locally (1). In practise, the term remote desktop has a very broad meaning which could pertain to any of the specific uses of this feature. Also, each implementation of programs that enable remote access is different as the services provided by each of them vary.

Applications of remote desktop are numerous and depend on the setting in which it is used. An important use is in the domain environment where a central server machine (or group of servers) controls all the other clients that are connected to it. In such a situation, certain programs which need a lot of resources are run on the server and are accessed by the client computers via remote sharing. This approach eliminates the need for multiple licenses or expensive client machines. Network administrators can also use remote desktop to maintain and when required, troubleshoot a remote client machine. This reduces the need for a large number of technical support staff (2).

Remote desktop also serves as a handy utility for the end-user. It allows an employee to work from home by making available the same set of software and settings which are provided at office. A student can access all their important files and documents stored at the university computer without being physically present anywhere near the campus. A novice user can get help with installation of particular software remotely from an expert (3).

To use remote desktop, one needs specialised software. Though there are a plethora of remote desktop clients available for the desktop on all major operating systems, the options for mobile platforms are quite scarce. This is majorly due to a variety of operating systems in use and restricted resources available in mobile devices. In addition to it, the few usable solutions are either quite expensive or are no longer supported. This prompted me to take up the challenge of developing a practical, easy-to-use remote desktop application for the ultra-portable platform which needs no technical know-how to setup and run.

Chapter 2

Literature Survey

2.1 The Android Platform

Today, there exist a number of operating platforms for mobile devices. A majority of them are proprietary and are adopted by a handful of device manufacturers. Thus, developing for such platforms would provide little in way of commercial value to the application. Also, it will be available to only a small section of smartphone users. Porting the app to other mobile platforms is also not an alternative as this would require drastic changes in its code which would require additional man hours.

An exception to the above mentioned problem is the Android platform for mobile devices. Android is a software stack for mobile devices that includes an operating system, middleware [1] and key applications (4). Android was originated by a group of companies known as the Open Handset Alliance, led by Google. Today, many more companies which involve cellular service providers, OEMs and developers have invested in Android and have adopted it for their products (5). As can be seen from the following figure, the architecture of the platform is no different from traditional PC architectures.

Figure 1: The Android Architecture (Source: Wikimedia Commons)

The lowest layer of the architecture consists of the Linux kernel which has all the drivers needed to communicate with the hardware. This layer is also called the Hardware abstraction layer. The layer above it has android core libraries written in C/C++. It also has the Dalvik virtual Machine which provides inter-process abstraction. On top of the libraries is the API [2] layer which enables component re-use and better application design. The topmost layer has all core applications which ship with the OS.

An important attribute of the Android platform is that it is open-source. Thus, its source code is freely available which enables developers to use readily available APIs for developing robust applications quickly. Also, as the system requirements of Android are quite less, it is suitable for mid-range to ultra-high-end devices. As a result, Android can be seen in mobile phones, e-readers, PDAs and even netbooks (6). There is also an active developer’s community for Android which provides support via e-mail and web forums. Thus, it is not hard to see why Android provides an ideal platform for application development.

Figure 2: A typical home-screen for Android devices (Source: developers.android.com)

The screenshot above shows a ‘home’ screen of an android device. This device is a mobile phone and thus has applications such as contacts, phone and messaging on the home screen. A variety of tablet computers, electronic book readers and netbook computers also use android and have icons relevant apps on the home screen. The white bar on the top is the notification bar which works the same way as the notification area in Microsoft windows. It displays battery level, signal strength, time and current network connection.

2.2 Android Application basics

Applications for the android platform are written in the JAVA programming language. For deploying an application to a device, the java code is first compiled and then bundled into an android package which is in the “.apk” format. The latter operation is done by the Android Asset Packaging Tool or aapt.

In Android, every application runs in its own Linux process. Android starts the process when any of the applications code needs to be executed, and shuts down the process when it’s no longer needed and system resources are required by other applications. Each process has its own virtual machine (VM), so application code runs in isolation from the code of all other applications. No other application is aware about the existence of the other. By default, each application is assigned a unique Linux user ID. Permissions are set so that the application’s files are visible only to that user and only to the application itself.

2.3 Application components

A unique feature of the android platform is that each application can use a feature provided by some other application without having to actually implement it. This encourages code-reuse and saves precious man hours spent in development.

Unlike applications on most other systems, Android applications don’t have a single entry point for everything in the application (no main() function, for example). Rather, they have essential components that the system can instantiate and run as needed. There are four types of components:

2.3.1 Activities

An activity is a visual representation for any task that application intends to fulfil. For example, an activity could be a list of images in a gallery, a menu with settings for the user or a phonebook with contacts.

An activity can spawn another activity whenever an event occurs. In the phonebook activity, when a user clicks on a contact, another activity is created which allows the user to either call or send a text message to that contact.

Each activity has a “view” associated with it. This view provides visual elements such as text fields, buttons, checkboxes etc. These elements might have some listeners associated with them which trigger an action when interacted with.

2.3.2 Services

A service might not be visible to a user but it runs indefinitely in the background and could be used by an activity. For example, a service might play background music as the user attends to other matters, or it might fetch data over the network or calculate something and provide the result to activities that need it.

A prime example is a media player playing songs from a play list. The player application would probably have one or more activities that allow the user to choose songs and start playing them. However, the music playback itself would not be handled by an activity because users will expect the music to keep playing even after they leave the player and begin something different. To keep the music going, the media player activity could start a service to run in the background. The system would then keep the music playback service running even after the activity that started it leaves the screen.

Like activities and the other components, services run in the main thread of the application process. So that they won’t block other components or the user interface, they often spawn another thread for time-consuming tasks (like music playback).

2.3.4 Broadcast receivers

A broadcast receiver is a component that does nothing but receives and reacts to broadcast announcements. These announcements can be anything that are meant to inform user about occurrence of an event such as email arrival, low battery indication, change of track in the music player and so on. Applications can also initiate broadcasts – for example, to let other applications know that some data has been downloaded to the device and is available for them to use.

An application can have any number of broadcast receivers to respond to any announcements it considers important.

Broadcast receivers do not display a user interface. However, they may start an activity in response to the information they receive, or they may use the Notification Manager to alert the user. Notifications can get the user’s attention in various ways – flashing the backlight, vibrating the device, playing a sound, and so on. They typically place a persistent icon in the status bar, which users can open to get the message.

2.3.5 Content providers

A content provider makes a specific set of the application’s data available to other applications. They basically provide for interprocess communication. The content provider extends the ContentProvider base class to implement a standard set of methods that enable other applications to retrieve and store data of the type it controls. However, applications do not call these methods directly. Rather they use a ContentResolver object and call its methods instead. A ContentResolver can talk to any content provider to manage communication with processes.

Whenever there’s a request that should be handled by a particular component, Android makes sure that the application process of the component is running, starting it if necessary, and that an appropriate instance of the component is available, creating the instance if it is necessary.

2.4 A typical Android project directory structure

Figure 1 shows the directory structure of an android project named “filegetter”. Here, the first folder “src” holds the java source files for the project. These files contain actual java code which is written by the developers. In this case, the source files are held in a package named “hardik.test.browse”. The package helps to keep the source files together allowing easy access to data and variable within the project.

Figure 3: Directory structure of an Android project

The next folder is “gen” which consists of auto generated java files. These files are generated when the project is build/compiled. Information about variables, strings and layouts are stored in these files.

“Android 1.6” is the build of the android platform against which the application is being created. This is important as each build has some special classes which may not be present in an earlier one. “Referenced Libraries” consists of list of all third party or external libraries used for our project. In our case, it will consist of the JCIFS library (explained later).

The “assests” folder in generally unused and it may hold required files if needed.

The “res” folder has “drawable”, “layout” and “values” subfolders. Drawable consists of icons and other graphical elements of the application and is divided into three subfolders according to resolution of target device. The layout folder holds .xml layout files which decide elements like button, text box, list etc. for the application. The values folder is used for providing id for different components of the application.

The “AndroidManifest.xml” is an important element of an android project. In this file, all the activities and services of the application are described. Other elements such as application permissions for the application are also described.

Finally, the “default.properties” file has an entry for the build of target devices for which the application is being developed.

2.5 Android in the Market

According to a May report by market research group NDP, the Android operating system performed quite well in the first quarter (Q1) of 2010, moving past Apple to take the number-two position among smartphone operating systems. NPD’s wireless market research reveals that based on unit sales to consumers last quarter the Android operating system moved into second position at 28% behind Research In Motion’s Blackberry OS (36%) and ahead of Apple’s OS (21%) (7).

These figures indicate a rise in popularity in the android platform. Also a large range of available handsets means that consumers will be able to choose according to their needs and budgets. This increase in market share also means that more developers will be willing to develop for Android making it a competitive, mainstream product.

2.6 Remote Desktop Implementation

Currently, there exist a variety of applications for PC which use either proprietary or generic/open-source protocols for remote desktop implementation. All of these applications are based on the server-client model where the server side of the software operates on the target machine and the client application is run on the remote host. Either of the machines may function as client or server provided both of them are equipped with required software.

Figure 4: Implementation of a traditional client-server model (Source: acm.org)

Various protocols can be used for remote access. Each of these provides a specific set of functionalities that may be common to another protocol or unique to that particular protocol.

Listed below are some of the protocols used for remote access and file sharing. These are widely used in several desktop clients in the market today.

2.6.1 RDP (Remote Desktop Protocol)

It is a proprietary protocol developed by Microsoft which provides remote display and input capabilities over network connections for windows-based applications running on a server (8). The RDP is encapsulated within the TCP layer and uses separate virtual channels for carrying data, licensing information, encrypted information and so on. All versions of windows after windows XP support Remote Desktop via RDP. But only the ‘professional’ and ‘ultimate’ versions come with the Remote Desktop Server program which enables a user to share their screen (9).

2.6.2 RFB (Remote Framebuffer) Protocol

RFB is a simple protocol for remote access to graphical user interfaces. Because it works at the framebuffer level it is applicable to all windowing systems and applications, including Linux, Windows and Macintosh. It is primarily used by the VNC (Virtual Network Computing) software and its derivatives. By default, it uses TCP port 5900 for the client and port 5500 for the server (10).

2.6.3 SMB (Server Message Block)

The Server Message Block (SMB) Protocol is a network file sharing protocol which allows a client application in a network to read and write files on and request services from the server on the same network. The SMB protocol requires a secure and encrypted authentication method and is thus more secure than other file sharing methods. Microsoft provides an SMB client and server with its Windows operating system. For Linux based systems, a utility called Samba is freely available for using the protocol (11).

Chapter 3

Design

One of the major hurdles faced in designing a remote access client is to decide upon the protocol to be used. Out of the available ones mentioned before, the RDP and SMB protocols allow screen-capturing of the remote machine onto the client device. This allows the user to interact with the desktop in real-time. Both these protocols have been implemented successfully in a variety of programs for all three popular (Windows, Mac OS and Linux) desktop platforms. Upon deciding the project, the intent was to use one of these protocols for the application. But the following difficulties were experienced during the development phase.

3.1 RDP and RFB Implementation issues

3.1.1 Absence of library classes

While implementing either RDP or RFB, one can use the ‘Robot’ class present in Java which can mimic the mouse, simulate keyboard interactions and capture the screen of a remote host over the network (12). This class is unfortunately absent in android and thus cannot be used. This makes it difficult to perform the above mentioned functions in android as no alternative classes exist.

Current RFB and RDP implementations on Android have made use of similar projects on the desktop environment by ‘forking’ [3] the source code from these projects. These existing projects use external libraries without proper documentation and at times are written in a non-java programming language. Thus, comprehending the original code and then forking it would take a lot more time than the projects duration.

3.1.2 Need for server side installation

Both the protocols (RFB and RDP) required a server side program running on the target machine. This program is bundled with server editions of most operating systems but require purchase on all other editions. Also, there may be compatibility issues if the server is running a RDP implementation and the device has a client using the RFB protocol. This will result into failed communication between the server and the client.

Due to the aforementioned issues, remote access will be implemented by using the SMB protocol.

3.2 Benefits of the SMB protocol

An enhanced version of the SMB called CIFS [4] (Common Internet File Sharing) has been in place since Windows 2000 and it provides a host of features when compared to other such protocols (13).

3.2.1 Greater accessibility

The SMB protocol for resource sharing has been used by Microsoft for their operating systems since Windows 95. In a domain environment, SMB is used to provide access to relevant resources to every user. In Linux too, a free utility called Samba which uses the SMB protocol, comes with most distributions. Thus, out-of-box functionality can be provided to any client requiring remote access.

3.2.2 Added security

CIFS provides flexibility to allow anonymous transfers as well as secure, authenticated access to resources. Policies can also be easily managed and changed whenever required

3.2.3 Support for slow connection

Access to shared resources and transfer of resources is also supported on slower connections. Thus, using a 3G or EDGE connection from a device will not be an issue while accessing remote files.

3.2.4 Performance and scalability

CIFS servers are highly integrated with the operating system. Thus they function as part of the OS and not third party programs. This guarantees maximum system performance at all times (13).

3.3 SMB Authentication Method

Authentication over SMB occurs mainly through the NTLM (NT Lan Manager) that works on systems using windows and on Linux/Unix distributions via the Samba server (14). NTLM is a challenge-response authentication protocol which uses three messages to authenticate a client in a connection oriented environment, and a fourth additional message if integrity is desired (15). The following figure shows exchange of messages between the client and server during authentication.

Figure 5: Message sequence to authenticate an SMB session

As seen in the above figure, the client negotiates protocol-specific options using the SMB_COM_NEGOTIATE request and the server replies with similar response messages as shown by (1) and (2) respectively. The client then sends an SMB_COM_SESSION_SETUP_ANDX request message. In cases where NTLM authentication is negotiated, within this message an NTLMNEGOTIATE_MESSAGE is embedded.

The server responds with an SMB_COM_SESSION_SETUP_ANDX response message within which an NTLM CHALLENGE_MESSAGE is embedded. The message includes an 8-byte random number, called a “challenge” that the server generates and sends in the ServerChallenge field of the message.

The client then extracts the ServerChallenge field from the NTLM CHALLENGE_MESSAGE and sends an NTLM AUTHENTICATE_MESSAGE to the server (embedded in an SMB_COM_SESSION_SETUP_ANDX request message).

If the challenge and the response prove that the client knows the user’s password, the authentication succeeds and the client’s security context is now established on the server. To acknowledge this, the server sends a success message embedded in an SMB_COM_SESSION_SETUP_ANDX response message.

3.4 SMB Packet Exchange

The following lists an example of a packet exchange between a client and a server via the SMB protocol (16).

The client and the server establish a NetBIOS [5] connection.

The client and server negotiate the Microsoft SMB Protocol dialect.

The client logs on to the server.

The client connects to a share on the server.

The client opens a file on the share.

The client reads from the file

The connection being full-duplex, file transfer can occur from both ends.

Chapter 4

Implementation

4.1 Flowchart

In any application, the flow diagram is an important figure that helps one visualize the interactions a user might have with the application and the possible outcomes of these interactions.

Figure 6: Flowchart

4.2 UML Use Case diagram

Use cases are used to identify and partition system functionality. They separate the system into actors and use cases. Actors represent roles that can are played by users of the system. Those users can be humans, other computers, pieces of hardware, or even other software systems. The only criterion is that they must be external to the part of the system being partitioned into use cases. These actors can interact with the system in a variety of ways which create various outputs. The outputs may be for the users or for other components of the system.

Figure 7: Use cases

The figure above shows a user’s interaction with the application. The user can access the Remote resources provided they are logged in to the remote share. Similarly, they can download a file to the local resources only if the file is present in the remote share.

Chapter 5

Results

5.1 Experimental Setup

For evaluating the results, the application was used on an android handset with Android platform version 2.2. The remote server was a laptop running windows 7. Files and folders were shared using the SMB protocol with mandatory authentication to all shared resources. The target machine and the mobile device were both connected to the same wireless network.

5.2 Application Screenshots

Figure 8: On Start-up

As seen above, the user is presented with a tabbed view with local file system selected. Different icons are used for various datatypes.

Figure 9: Local Photo folder

Seen above is the photo folder located on the memory card of the device. The two green arrows on the top represent ‘up’ and ‘back’ buttons which are used for navigation.

Figure 10: Login screen

Login screen on clicking the “Remote” tab.

Figure 11: Unsuccessful login (pop-up appears)

Figure 12: Remote download

Downloading remote file to memory card on click.

Figure 13: Operations on remote file

Bibliography

1. Remote Desktop Software. Wikipedia. [Online] [Cited: 25 June 2010.] http://en.wikipedia.org/wiki/Remote_desktop_software.

2. Remote desktop. TopBits – Tech Community. [Online] [Cited: 25 June 2010.] http://www.topbits.com/remote-desktop.html.

3. 5 Best Remote Desktop and administration application. TechieZone. [Online] [Cited: 25 June 2010.] http://techiezone.in/reviews/5-best-remote-desktop-and-administration-application/.

4. About the Android Open Source Project. Android. [Online] [Cited: 26 June 2010.] http://source.android.com/about/index.html.

5. Philosophy and Goals. Android. [Online] [Cited: 26 June 2010.] http://source.android.com/about/philosophy.html.

6. List of Android Devices. Wikipedia. [Online] [Cited: 26 July 2010.] http://en.wikipedia.org/wiki/List_of_Android_devices.

7. Android shakes up U.S. smartphone market. NDP. [Online] [Cited: 7 July 2010.] http://www.npd.com/press/releases/press_100510.html.

8. MSDN Remote Desktop Protocol. MSDN. [Online] [Cited: 4 July 2010.] http://msdn.microsoft.com/en-us/library/aa383015.aspx.

9. Understanding the Remote Desktop Protocol (RDP). Microsoft Support. [Online] [Cited: 5 July 2010.] http://support.microsoft.com/default.aspx?scid=kb;EN-US;q186607.

10. Richardson, Tristan. The RFB Protocol – Version 3.8 (2009-11-24). RealVNC. [Online] [Cited: 10 July 2010.] http://www.realvnc.com/docs/rfbproto.pdf.

11. Server Message Block Protocol. Search Networking. [Online] [Cited: 25 July 2010.] http://searchnetworking.techtarget.com/sDefinition/0,,sid7_gci214214,00.html.

12. Java Remote Desktop Administration. The Code Project. [Online] [Cited: 21 July 2010.] http://www.codeproject.com/KB/IP/RemoteAdminJava.aspx.

13. CIFS. Protocol Base. [Online] [Cited: 20 July 2010.] http://www.protocolbase.net/protocols/protocol_CIFS.php.

14. Integrating additional services. Samba.org. [Online] [Cited: 2 August 2010.] http://www.samba.org/samba/docs/man/Samba-Guide/DomApps.html.

15. Microsoft NTLM. MSDN (Microsoft Developers Network). [Online] [Cited: 5 August 2010.] http://msdn.microsoft.com/en-us/library/aa378749(VS.85).aspx.

16. Microsoft SMB protocol packet exchange scenario. Microsoft Developers Network (MSDN). [Online] [Cited: 10 August 2010.] http://msdn.microsoft.com/en-us/library/aa365236(v=VS.85).aspx.