A Remote Desktop Application For Android Essay Example

is no need for multiple licenses or expensive client machines. Network administrators can also utilize remote desktop to maintain and troubleshoot remote client machines whenever necessary. This reduces the requirement for a large technical support team (2).

Remote desktop is a useful tool for various users. It enables employees to work from home with the same software and settings as in the office. Students can access their important university files without being on campus. Novice users can receive remote help from experts for software installation (3).

To utilize remote desktop, you need specialized software. Although there are several remote desktop clients available for desktop computers on major operating systems, the options are limited for mobile platforms due to the various operating systems and limited resources on mobile devices. Additionally, the few viable solutions either come at a high cost or are no longer supported. This inspired me to create a practical and user-friendly remote desktop application for ultra-portable platforms that doesn't require technical expertise for setup and operation.

Chapter 2

At present, there are various proprietary operating platforms exclusively utilized by a handful of device manufacturers for mobile devices. As a result, creating applications for these platforms would have limited commercial potential and only target a fraction of smartphone users. Additionally, attempting to adapt the app to other mobile platforms is impractical since it would require substantial code modifications and additional time commitments.

The Android platform for mobile devices is unique in addressing the previously mentioned problem. It comprises an operating system, middleware, and key applications, forming a software stack. The initiative was led by Google through the Open Handset Alliance, garnering support from various entities such as cellular service

providers, OEMs, and developers who have embraced Android for their offerings. Notably, its architecture resembles that of traditional PC architectures depicted in the accompanying figure.

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

The architecture of the system is composed of multiple layers. The lowest layer is the Hardware abstraction layer, which includes the Linux kernel and hardware communication drivers. Above this layer, there are android core libraries written in C/C++ and the Dalvik virtual Machine that provide inter-process abstraction. Next is the API layer, which allows for component re-usability and improves application design. Lastly, at the topmost layer, all pre-installed core applications are located.

The Android platform is distinctive because it is open-source, meaning that its source code can be freely accessed. This enables developers to utilize available APIs and rapidly develop powerful applications. Moreover, Android has minimal system requirements, making it suitable for various devices like mobile phones, e-readers, PDAs, and netbooks (6). The active developer community for Android offers support through email and web forums. Therefore, Android is an excellent platform for application development.The typical home-screen for Android devices can be found on developers.android.com (Figure 2).

The image displayed above depicts the 'home' screen of an android device, such as a mobile phone. This particular screen encompasses various applications including contacts, phone, and messaging. Additionally, other devices like tablet computers, electronic book readers, and netbook computers employ android and exhibit icons for their respective apps on their home screens. Positioned at the top of the screen is a white bar functioning as a notification bar akin to that found in Microsoft Windows. It showcases details regarding battery level, signal strength, time, and current network connection.

Android applications

are created with the JAVA programming language and then compiled into an android package called ".apk" using the Android Asset Packaging Tool (aapt).

Android operates each application in a separate Linux process, which is started and shut down as necessary. Each process has its own VM, enabling the code to run independently. Applications are unaware of each other and have unique Linux user IDs. Permissions limit file access to only the user and the application itself.

The android platform enables applications to utilize features from other applications, eliminating the need to create them anew and enhancing efficiency by leveraging existing code. This significantly reduces development time and effort.

Android applications differ from other systems in that they do not have a singular entry point or "main()" function. Instead, they comprise of various components that the system can generate and execute as required. These components are classified into four types.

An activity is a visual representation of an objective that an application intends to fulfill. It can take on different forms, like a gallery with images, a menu for user preferences, or a phonebook exhibiting contacts.

An event in the phonebook activity can trigger the creation of another activity, which allows the user to choose between calling or sending a text message to a contact when that contact is clicked.

The "view" of each activity contains visual components such as text fields, buttons, and checkboxes. These components can have listeners associated with them, triggering an action upon interaction.

A service remains active in the background and can be accessed by an activity even if it is not visible to the user. Examples of services include playing background music or retrieving data

from the network and performing calculations for activities that need them.

One example is a media player that plays songs from a playlist. The player application would probably have several activities for selecting songs and starting playback. However, the actual music playing would not be controlled by an activity because users expect the music to keep playing even if they exit the player and do other things. To make sure the music doesn't stop, the media player activity could start a background service. This way, the system will continue running the music playback service even when the launching activity is no longer visible.

Activities, among other components, and services are executed on the main thread of the application process. However, in order to prevent blocking other components or the user interface, services often create a separate thread for tasks that require more time, such as music playback.

A broadcast receiver is a component that receives and responds to broadcast announcements. These announcements can be anything that informs the user about events, such as email arrival, low battery indication, and track changes in a music player. Applications can also initiate broadcasts, informing other applications that data has been downloaded and is available for use.

An application can have multiple broadcast receivers that can respond to various important announcements.

Broadcast receivers lack a user interface but can trigger an activity or employ the Notification Manager to alert the user. Notifications employ various methods, including backlight flashing, device vibration, and sound, to grab the user's attention. They typically include a persistent icon in the status bar that users can tap to view the message.

A content provider is responsible for granting other

applications access to a specific set of data from an application. This is done by implementing a standardized set of methods that allow for the retrieval and storage of data controlled by the content provider. However, rather than directly utilizing these methods, applications utilize a ContentResolver object and call its methods instead. The purpose of a ContentResolver is to facilitate interprocess communication by enabling communication with any content provider.

Android ensures that the application process of a specific component is running when there is a request to be handled by that component. If necessary, Android starts the process and creates an instance of the component to fulfill the request.

Figure 1: The directory structure of an android project called "filegetter" is depicted here. The initial folder, named "src", houses the java source files for the project. These files consist of actual java code, written by the developers. In this particular scenario, the source files are located in a package named "hardik.test.browse". This package facilitates the organization of the source files, enabling convenient access to data and variables within the project.

Figure 3: Directory structure of an Android project

The "gen" folder is where the auto-generated java files are stored. These files contain information on variables, strings, and layouts. They are generated during the project's build or compile process.

The application is being developed for Android 1.6, a specific version of the Android platform. Each build has its own classes that are not present in older versions. The project includes a list of third-party or external libraries used, which can be found under "Referenced Libraries". One of these libraries is the JCIFS library, which will be

explained later.

The "assets" folder is not often used, but it can be used to store any required files.

The "res" folder contains the subfolders: "drawable", "layout", and "values". In the "drawable" subfolder, there are icons and graphical elements for the application. This subfolder is divided into three based on device resolution. The "layout" folder has .xml layout files specifying buttons, text boxes, and lists. The "values" folder assigns IDs to different components of the application.

The "AndroidManifest.xml" file is a crucial component of every Android project, containing information about the activities and services within the application, as well as the required permissions for its functioning.

Finally, the "default.properties" file contains information about the build of target devices for which the application is being developed.

In May, a report from market research group NDP revealed that in the first quarter of 2010, the Android operating system surpassed Apple and secured the second position among smartphone operating systems. NPD's wireless market research indicated that, based on consumer unit sales, Android OS captured a 28% market share last quarter. This placed it behind Research In Motion's Blackberry OS with a 36% share and ahead of Apple's OS with a 21% share.

The popularity of the android platform is evident from these statistics. Additionally, the availability of a diverse range of handsets allows consumers to select one that meets their requirements and budget. This rise in market share also entices more developers to engage with Android, transforming it into a competitive and widespread product.

At present, there are different PC applications that use proprietary or generic/open-source protocols to enable remote desktop functionality. These applications operate on a server-client model, with the target

machine having the server side installed and the remote host running the client application. If both machines have the required software installed, they can function as either client or server.

Figure 4 depicts the execution of a conventional client-server model (Source: acm.org).

There are several remote access protocols available, each offering unique features. While certain functionalities may overlap, others are exclusive to specific protocols.

Here is a compilation of frequently utilized protocols for remote access and file sharing, which are extensively employed in various desktop clients found in today's market.

Microsoft developed a proprietary protocol called RDP that allows remote display and input features for windows-based applications on a server. RDP is embedded in the TCP layer and utilizes virtual channels to transmit data, licensing info, encryption, etc. Remote Desktop via RDP is supported by all windows versions post windows XP. However, only the 'professional' and 'ultimate' versions include the Remote Desktop Server program, allowing users to share their screen.

RFB is a simple protocol for accessing graphical user interfaces remotely. It is compatible with various windowing systems and applications, including Linux, Windows, and Macintosh. VNC (Virtual Network Computing) software and similar programs commonly employ this protocol. The client typically connects via TCP port 5900, while the server operates on port 5500 (10).

The Server Message Block (SMB) Protocol is a network file sharing protocol that enables a client application on a network to access files and request services from the server on the same network. The SMB protocol offers a more secure file sharing method as it requires a secure and encrypted authentication method. Microsoft offers an SMB client and server with its Windows operating system, while Linux-based systems can

use the protocol through a freely available utility called Samba (11).

The content below is an example of unifying and the given text while preserving the and their contents:

Chapter 3

When designing a remote access client, one must select a protocol that will enable screen-capturing of the remote machine on the client device, facilitating real-time desktop interaction. The RDP and SMB protocols have been effectively utilized in programs for Windows, Mac OS, and Linux. Initially, it was intended to utilize either of these protocols for the project; however, various challenges arose during development.

The 'Robot' class in Java can be used to imitate mouse actions, simulate keyboard interactions, and capture the screen of a remote host over the network when implementing RDP or RFB. However, this class is not available in Android, resulting in difficulties performing these functions in Android due to the absence of alternative classes.

On Android, the current implementations of RFB and RDP have utilized existing projects in the desktop environment by forking their source code [3]. However, these projects often employ external libraries that lack proper documentation and may be written in a non-java programming language. As a result, understanding the original code and then forking it would require significantly more time than the duration of the projects.

Both protocols (RFB and RDP) need a server-side program on the target machine. This program is included with server editions of most operating systems but must be purchased for other editions. Additionally, compatibility problems may arise if the server uses RDP and the client device uses the RFB protocol, leading to failed communication between the server and client.

Remote access will be implemented using the SMB protocol

due to the previously mentioned issues.

An upgraded version of SMB, called CIFS [4] (Common Internet File Sharing), has been utilized since Windows 2000, offering numerous features compared to similar protocols (13).

The SMB protocol, used by Microsoft since Windows 95 for resource sharing, is also utilized in Linux through a free utility called Samba. This utility, included in most distributions, allows for out-of-box functionality in providing remote access to clients, particularly in a domain environment.

CIFS offers the option for both anonymous transfers and secure, authenticated access to resources. Additionally, policies can be easily managed and updated as needed.

Even on slower connections such as 3G or EDGE, shared resources and resource transfer are supported. This indicates that there will be no issues when accessing remote files from a device with a 3G or EDGE connection.

Section 3.2.4 discusses the system's performance and scalability.

CIFS servers are not external applications, but rather closely integrated with the operating system and function as part of it. This integration guarantees consistent maximum performance of the system (13).

Authentication over SMB is primarily accomplished through NTLM. NTLM is utilized on Windows systems and also on Linux/Unix distributions via the Samba server (14). NTLM operates as a challenge-response authentication protocol in connection-oriented environments, utilizing three messages to authenticate a client. If integrity is desired, an extra fourth message is employed (15). The diagram below showcases the message exchange between the client and server during authentication.

Figure 5 displays the message sequence utilized for authenticating an SMB session.

The figure above illustrates the process of client negotiation for protocol-specific options using the SMB_COM_NEGOTIATE request. The server also responds with similar messages denoted as (1) and (2). Following this, the

client sends an SMB_COM_SESSION_SETUP_ANDX request which may include the NTLMNEGOTIATE_MESSAGE if NTLM authentication is negotiated.

The server replies to a request using the SMB_COM_SESSION_SETUP_ANDX message, which includes an NTLM CHALLENGE_MESSAGE containing a randomly generated 8-byte number called a "challenge". This challenge is included in the ServerChallenge field of the message.The client sends an NTLM AUTHENTICATE_MESSAGE to the server in an SMB_COM_SESSION_SETUP_ANDX request message, after retrieving the ServerChallenge field from the NTLM CHALLENGE_MESSAGE.

If the client's challenge and response indicate that they know the user's password, authentication is considered successful. Subsequently, the server will establish the client's security context and include a success message in an SMB_COM_SESSION_SETUP_ANDX response message.

The following text illustrates the communication between a client and server using the SMB protocol (16) for packet exchange.The client and server establish a connection using NetBIOS [5].

Both the client and server participate in a negotiation process to establish the dialect of the Microsoft SMB Protocol.

The client logs on to the server.

The client establishes a connection with a server share.

When the client opens the share, they access a file.

The file's contents are accessed and retrieved by the client.

The connection is full-duplex, allowing both ends to transfer files.

Chapter 4

In every application, the flow diagram plays a crucial role in allowing individuals to visualize the various interactions a user can have with the application and the potential outcomes of these interactions.

Figure 6: Flowchart

Use cases have the role of identifying and categorizing system functionality. They assist in dividing the system into actors and use cases. The actors represent various users of the system, such as human users, computers, hardware components, or software systems. It is crucial that these actors are external to the

specific part of the system being divided into use cases. The interactions between these actors and the system can lead to different outputs designed for users or other components within the system.

Figure 7: Use cases

The image above showcases how the user interacts with the application. If they are logged into the remote share, they can access remote resources. Additionally, if a file is present in the remote share, they have the option to exclusively download it to their local resources.

Chapter 5

Conducting the evaluation of results involved using an Android handset with Android platform version 2.2. The remote server, which was a laptop running Windows 7, utilized the SMB protocol for file and folder sharing. Access to all shared resources necessitated mandatory authentication. Both the mobile device and target machine were connected to the same wireless network.

Figure 8: On Start-up

The tabbed view above allows users to select the local file system, utilizing various icons to represent different datatypes.

Figure 9: Local Photo folder

Displayed above is the photo folder found on the memory card of the device. The top section of the folder features two green arrows, which function as both 'up' and 'back' buttons to aid in navigation.

Figure 10: Login screen

Login screen will appear when the "Remote" tab is clicked.

The pop-up shown in Figure 11 appears when a login attempt is not successful.The remote download feature is illustrated in Figure 12.

Upon the user's click, the remote file is downloaded and stored onto the memory card.

The operations that can be performed on a remote file are shown in Figure 13.

The webpage http://en.wikipedia.org/wiki/Remote_desktop_software is an online source on the topic of Remote Desktop Software, cited on June 25, 2010,

as covered in Wikipedia.

2. TopBits, a Tech Community, provides information on remote desktop obtained online with the source cited on June 25, 2010. The source can be found at http://www.topbits.com/remote-desktop.html.

According to TechieZone, they suggest five remote desktop and administration applications. You can find the reviewed applications at this link: http://techiezone.in/reviews/5-best-remote-desktop-and-administration-application/. The information was obtained online and cited on June 25, 2010.The Android Open Source Project declares that Android is an internet-based platform introduced on June 26, 2010. For more information, please visit http://source.android.com/about/index.html.The Philosophy and Goals of Android can be found on its official website at http://source.android.com/about/philosophy.html.

6. This is a list of Android devices from Wikipedia, an online encyclopedia, cited on July 26th, 2010. To view the complete list, click here.

According to a report published online on July 7, 2010 by NDP, Android is becoming more popular in the American smartphone market. The report can be accessed at http://www.npd.com/press/releases/press_100510.html.

The Remote Desktop Protocol can be found on MSDN. It was accessed online and cited on 4 July 2010. The link to the source is: http://msdn.microsoft.com/en-us/library/aa383015.aspx.

The content in this text is sourced from the Microsoft Support website, specifically from the page titled "Understanding the Remote Desktop Protocol (RDP)" available at the provided URL. This online source was accessed and last cited on July 5, 2010.

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

The Server Message Block Protocol, or SMB, is a networking protocol that serves various purposes such as file sharing, printer sharing, and computer communication. It is described as "a client/server communication protocol used to share access to files, printers, serial ports,

and other resources on a network." (Source: http://searchnetworking.techtarget.com/sDefinition/0,,sid7_gci214214,00.html)

The Code Project has an online resource for Java Remote Desktop Administration available at http://www.codeproject.com/KB/IP/RemoteAdminJava.aspx. This resource was referenced on July 21, 2010.

13. On the Protocol Base website, CIFS is a protocol that was cited on 20 July 2010.

The text mentions the integration of additional services and provides a citation from Samba.org. The citation includes a URL and a date of citation.

The MSDN article about Microsoft NTLM was last accessed on 5 August 2010.

According to MSDN, the Microsoft SMB protocol packet exchange scenario can be found at http://msdn.microsoft.com/en-us/library/aa365236(v=VS.85).aspx. The information was last accessed on 10 August 2010.