Emulation Tool For Android Edge Devices

The number of mobile devices has surpassed the global population, making them the primary means of communication and data sharing. However, existing applications still heavily rely on centralized networks for communicating and sharing data due to the lack of tools for developers to create and test distributed applications in edge environments. To address this issue, we present EdgeEmu, an Android-based distributed emulation tool. EdgeEmu allows a considerable number of Android emulators to participate remotely in the emulation, making it an appropriate tool for testing large networks. Unlike the standard Android SDK, EdgeEmu is not re-stricted to local emulators. Thus, it eliminates scalability issues present in the current Android testing infrastructure. Evaluations show that EdgeEmu outperforms the standard Android SDK by approximately 59.1% in terms of emulation startup time when ten Android emulators are used. Additionally, it exhibits low latency and negligible overhead during message exchanges between different e mulators. A d emo v ideo o f E dgeEmu is a vailable at https://youtu.be/6jT9KXiUmQM.


INTRODUCTION
With mobile devices outnumbering the global population [16], their role as essential tools for communicating and data-sharing is undeniable.However, most applications, especially data-sharing and location-based games [1,10], heavily rely on remote services and internet connectivity, even though users are physically co-located.This results in increased latency and bandwidth usage.Edge networks offer a solution by enabling direct device-to-device communication using technologies like Bluetooth and Wi-Fi Direct.By employing these networks, it is possible to develop applications that take advantage of user proximity.
Developing applications leveraging edge networks presents challenges in terms of testing application functionalities.Traditional methods involve costly setups with physical Android devices, making them impractical.While Android provides its own development tool kit and emulation tools, it lacks support for multi-node emulation needed for testing edge network scenarios and supports only up to 16 emulated devices, limiting network size.Other available network simulation and emulation tools offer no support for developing and testing such applications on top of the network created.This limitation forces developers to publish untested applications or revert to centralized communication methods.
To bridge this gap, we present EdgeEmu, a tool enabling seamless testing of Android applications in both small and large emulated edge networks.One of the key design requirements for EdgeEmu includes support for a large number of Android emulators (limited only by the number of machines) while introducing low latency and bandwidth overhead.Thus, EdgeEmu is designed as a distributed system, allowing Android emulators hosted on remote physical nodes (e.g., a public cloud) to participate in the emulated networks.
EdgeEmu comprises two primary components: a Client and a Server.The Client runs on the developer's machine that is responsible for creating and modifying the emulated network.The Server can be hosted on a different machine than the developer's.It runs and manages Android emulators that participate in the emulated network and are hosted by the same machine as the server.The Client can establish connections with multiple Servers and utilize the emulators they manage within the emulated network.
Our evaluation shows that EdgeEmu can support up to 90 Android emulated devices using nine machines with 16 GB RAM for hosting EdgeEmu Servers.The number of emulators supported by EdgeEmu can increase with the use of more powerful physical machines or additional physical devices hosting EdgeEmu Servers.Additionally, EdgeEmu components introduce negligible latency and bandwidth overhead, making it an efficient solution for testing large networks of Android emulators.The EdgeEmu source code, along with the executable tool, and documentation can be found at https://github.com/LylaNV/EdgeEmu.

RELATED WORK
In this section, we focus on fog and edge emulation tools and overlook simulators (e.g.CloudSim [3], EdgeCloudSim [12], and Ceowd-SenSim [7]) and testbeds (such as piFogBed [17]) since they are out of scope.However, a more detailed discussion of related work can be found in our technical paper [15].
WoTemu [8] is an application-centric emulation tool for Edge Computing infrastructures, that employs container orchestration.eXP-RAN [6] is an open-source emulator with a modular architecture that enables experimentation with Radio Access Network, Edge Computing, and Slicing.5G-Slicer [14] is an open emulator tailored for IoT applications on 5G network slices, allowing developers to assess the performance and functionality of their applications.Fogbed [4] is a flexible emulator designed for prototyping fog services in virtualized environments.It utilizes Docker containers as fog nodes and extends the Mininet emulator [5].Fogify [13] is an open-source emulator for modeling, deploying, and experimenting with Fog services under realistic assumptions, faults, and uncertainties.EmuEdge [18] extends Mininet alike systems to emulate full-stack edge computing platforms with heterogeneous nodes.
EdgeEmu offers several benefits in the development of Android mobile applications when compared to the tools mentioned above.First, it stands out by providing built-in support for testing Android emulated devices.None of the aforementioned tools allows developers to test their Android applications on emulated edge devices.Second, unlike other emulators, it allows the testing of applications that utilize P2P protocols, such as Wi-Fi Direct, for communication.Finally, EdgeEmu enables emulated mobile device displacement and includes a graphical user interface where users can specify the location and trajectory of a smartphone in the emulated network.

THE SYSTEM OVERVIEW
The primary objective of EdgeEmu is to enable developers to create and test applications demanding extensive edge networks.It achieves this by utilizing emulators on multiple machines, as shown in Fig. 1, comprising two key components: a Client and a Server.

EdgeEmu Client
The EdgeEmu Client runs on the developer machine through a console window.The emulated network is also created and modeled on the developer machine.The Client is responsible for managing user interactions with EdgeEmu.It offers two interface options to the user: a text-based console and a Graphical User Interface (GUI) in which system interactions are done using written commands and interactive menus and options, respectively.

EdgeEmu Server
An EdgeEmu Server must be running on each machine hosting participating Android emulators in the emulation.The user (i.e.developer) must register EdgeEmu Servers to enable the Client to access and manage them.This involves recording the local IP addresses of the machines hosting Servers in a plain text configuration file supplied to the Client (see Fig. 1).The Server automatically identifies IP addresses, but users also have the option to assign arbitrary IP addresses to the Servers through Server-side plain text configuration files.The interactions between the Servers and the Client are explained in detail in our previous work [15]; here, we focus on the details that have not already been discussed.

EdgeEmu Interactions
EdgeEmu, using its Server component, can support a significant number of emulators spread across multiple physical machines.Each emulator in EdgeEmu is recognized with the hosting machine's local IP address and two pairs of network address and port numbers.These addresses are set by the Servers and enable two types of interactions between EdgeEmu components: Control Messages and Data Messages.

Control
Messages.Control Messages (blue solid arrows in Fig. 1) are sent from the Client to the emulators in two situations: i) when nodes approach each other, or ii) when Peer-to-Peer (P2P) groups are established among nodes.Control Messages carry data that allows the EdgeEmu API to trigger the proper P2P events inside an application using the Android Wi-Fi Direct API [9].An example of such an event includes creating a P2P group with designated emulators.When this event happens, an application establishes a socket connection with other group members, enabling communication through Data Messages (green dotted arrows in Fig. 1).
As depicted in Figure 1, the Client establishes connections with every registered Server via the addresses 192.168.1.1:8085and 192.168.1.2:8085.The port value 8085 is predefined on the Server but can be replaced by any other port value selected by the user in the EdgeEmu Server-side plain text configuration file.The Client, using these connections, can discover and utilize the emulators running on the Server machines.The Client uses these connections and the Servers as intermediaries to send Control Messages.
We assumed that the Client and Servers are on the same local network.However, in practice, this may not always be the case.To address this, a tool called sshuttle [11] can be used to make remote networks appear as local networks.

Data Messages.
Emulators can communicate with each other by using Data Messages.For instance, as illustrated in Fig. 1, emulator A establishes a connection with the target emulator B. Subsequently, this connection is redirected to the application running within emulator B and received through a socket that has been initialized by the EdgeEmu API on port 10001.Emulators employ EdgeEmu to establish a socket connection with their group members.The socket connection is created using the addresses of each emulator, which are provided in the control message information.This connection is established by the Server(s) of each emulator acting as intermediaries.
For example, emulator A communicates with emulator B (on the local network 192.168.1.X) by first opening a socket connection to the local EdgeEmu Server on localhost:7000 (see Fig. 2).The Server on Local Machine 1 then opens a socket connection to the Server of emulator B on Local Machine 2. The Server of emulator B receives this connection and then opens a socket connection to emulator B. When all these socket connections are established, handler threads are created to handle any subsequent messages that might be exchanged between emulators A and B. This is done in order to guarantee that EdgeEmu Server can handle the redirection of multiple communications between emulators.

EdgeEmu API
The current implementation of the WiFi-Direct API on Android [9] does not support the use of emulators to develop and test edgebased applications.The reason is that with the available WiFi-Direct API on emulators, it is not possible to emulate the P2P scenarios.EdgeEmu API addresses this issue by generating the same WiFi-Direct P2P events on the emulators as those that would happen when using the WiFi-Direct API on real physical Android devices.Such events detect that other emulators are in the WiFi-Direct range or that a P2P group was created with other emulator(s).The EdgeEmu API runs a background socket server that continuously listens on port 9001 (inside the emulator network environment).Control Messages are received on this socket following instructions given by the user in the Client.EdgeEmu API uses the information inside the Control Messages to trigger relevant P2P events within an application.
EdgeEmu API offers support for five P2P events including state changes, peer changes, membership changes, group ownership changes, and device information changes.The application must handle all or part of these events using a broadcast receiver.The complete guide for using the EdgeEmu API is provided on the GitHub page of the tool.
Developers must package their application with the EdgeEmu API library and use its services to be able to test the data-sharing functionality of their application through EdgeEmu.However, after testing an application, the EdgeEmu API must be removed and the application code must be adjusted accordingly to follow the Android WiFi-Direct implementation [9].

EdgeEmu User Interfaces
EdgeEmu provides two types of user interfaces: a text-based console and a GUI.In the text-based console, interactions are done using written commands.The GUI offers interactive menus and options for interactions.It runs inside a web server on the developer's machine and can be accessed via a web browser.To exchange messages, the EdgeEmu GUI connects to the Client via a socket server running on the Client at localhost:8081 (see Fig. 1).

EVALUATION
To show that EdgeEmu respects its design goals in terms of support for emulation of large edge networks with low overhead, we designed different tests and compared EdgeEmu with Termite [2], a previous existing open-source system.Due to space constraints, we summarize the findings achieved in our technical paper [15].Additionally, we provide a detailed practical example on how EdgeEmu can be used to support the testing of an edge-enabled application.

Ping and File Sharing Tests
The Ping Test evaluates latency by measuring the time taken to send a ping message from the Client to the emulators and receive a response, while the File Sharing Test assesses bandwidth by measuring the time it takes to transmit a large message from one emulator to another and receive a response.We performed these tests in two scenarios: i) local deployment: deploying an increasing number of emulators locally, and ii) remote deployment: deploying an increasing number of emulators remotely.In the first case, we run both tests on Termite and EdgeEmu locally, meaning all system components and emulators operate on the same developer machine.Subsequently, we repeat the tests exclusively on EdgeEmu, but this time, all required emulator instances run remotely.
The results in local deployment indicate that EdgeEmu Server has a negligible effect on the time required to send/receive ping messages and on the time required for messages to transmit from one emulator to another.This leads us to the conclusion that EdgeEmu performs comparably to Termite in this type of communication within a local environment.In the case of remote deployment, the results reveal a performance impact when compared to the local EdgeEmu test results.This increase in latency is due to the exchange of messages over the Internet between EdgeEmu components.Such latency is expected, and we believe that the experienced delay does not significantly affect the usability of the system; in addition, many real-world systems on the Internet also face similar latencies.

Size of the Emulated Network
The performance of EdgeEmu is directly influenced by the number of Android emulator instances we utilize within the emulated network for running and testing the desired application.
EdgeEmu demonstrates a notable improvement in the speed of launching emulators, installing applications, and starting the applications compared to Termite.This improvement is based on their different approaches: Termite starts emulator instances one after another, whereas EdgeEmu initiates all emulator instances simultaneously.This distinction is evident in the increased time savings achieved with EdgeEmu.
When emulators are instantiated across cluster nodes, the time it takes to start one emulator on a single machine and initiate nine emulators across nine different machines remains approximately the same.This occurs because the EdgeEmu Client concurrently processes and sends start commands to the EdgeEmu Servers on multiple machines.As a result, EdgeEmu benefits from the natural parallelism found in a distributed system.
The evidence of this parallel processing capability becomes clear in the results obtained when initiating 10 emulators on each of the 9 cluster machines.As expected, the time it takes to start 10 emulators on a single machine is nearly identical to starting 90 emulators across 9 different machines (10 emulators per machine).Moreover, starting 90 emulators in EdgeEmu proves to be faster than initiating just 10 emulators in Termite.It is worth mentioning that Termite can only support a maximum of 16 Android virtual devices, while EdgeEmu can support any number of Android virtual devices depending on the available resources.Based on these results, it can be concluded that EdgeEmu outperforms Termite in terms of performance.In addition to its performance benefits, EdgeEmuprovides a GUI that Termite lacks.

Use Case
In this section, we show in detail a practical example on how EdgeEmu can be used to support the test of an edge-enabled application.For this test case, we use one of our proof-of-concept applications called P2photo.This application allows users to create photo albums and share them among other P2photo users using WiFi-Direct.The application implements the EdgeEmu API.Thus, to test the P2P capabilities of P2photo we use EdgeEmu to create a test scenario where two P2photo users come into range of one another and, if the application behaves as expected, a photo is automatically shared between them.
We now explain how we deployed EdgeEmu and the emulators used, to create this test scenario.We started by establishing a Virtual Network Computing (VNC) connection to a remote machine (with local network IP of 193.136.154.72) on which we installed and started an EdgeEmu Server.We installed EdgeEmu Client on our local machine.To connect the EdgeEmu Client to the EdgeEmu Server running on the remote machine we registered the remote machine IP address on EdgeEmu Client.As both machines are not in the same local network, we use the sshuttle tool to bypass EdgeEmu's local network requirements.We then started the EdgeEmu Client; on startup, the EdgeEmu Client automatically connects to the registered EdgeEmu Server(s) and prompts the user to select the desired interface option (the console interface or the EdgeEmu GUI).For this use case, we chose the EdgeEmu GUI with the Google Map option accessed through a Chrome browser (we could have chosen another web browser).Using the EdgeEmu GUI we then started two emulators on the remote machine running the test application.
Fig. 3 shows the current state of our deployment after the emulators startup.From this point on, we emulate the P2P scenario where two users get close to each other and a file is automatically shared between them.To do this, we simply need to: i) create two virtual nodes on the emulated network view; ii) bind the nodes to the emulators; iii) move one of the nodes into the proximity of the other; iv) create a P2P group between the two nodes; and v) press the commit button.After the commit button is pressed, Control Messages are sent to the target emulators (the emulators bound to the nodes) which makes the application react accordingly to the emulated scenario, and a photo is exchanged between both devices.

CONCLUSION
We presented EdgeEmu, a distributed system architecture that allows the emulated network and emulated Android devices to operate on separate machines.EdgeEmu empowers users, particularly application developers, to establish the emulated network on one machine while distributing the computational workload of running a great number of emulators across multiple machines.This capability enables the creation of significantly larger emulated networks, allowing for the development and testing of more complicated applications.

Figure 1 :
Figure 1: Overview of EdgeEmu components and interactions

Figure 2 :Figure 3 :
Figure 2: Creating a socket connection between two emulators