views:

85

answers:

3

Hi to all, I wanted to know if it is possible the comunication between two Android Emulators started on two different machines networked.

For example - Emulator A run on machine M1 - Emulator B run on machine M2

Can A and B exchange messages?

If yes, what ip address do I use?

Thank you very much Deborah

A: 

You might know this already. As of android-sdk-tools_r7 it should at least be possible to connect two emulators to each other. Whether is works between physical machines is not something I know. It might be possible to set up masquerading between the two hosts for this specific broadcast.

From the android commit

Enable interconnection of emulators

This patch adds a -shared-net-id option to the emulator which joins the emulator in a shared network. If the option is given the emulator is started with an additional network interface bound to a multicast socket. This multicast socket emulates a network hub, interconnecting emulators. If the -shared-net-id option is not given, nothing changes.

To connect two emulators, use the -shared-net-id <number> command line option when starting the emulator. They will then directly share everything sent to or read from ip 10.1.2.<number> on the emulator.

Another approach would be to enable port forwarding between the emulators using adb, and then set up masquerading for those ports on the networked machines.

I'm not really sure that either of these solutions match the use case that you're asking after. If not, adding more details to the original question might help. :)

Disclaimer: I have not tried the first approach, and the second I've only used to make sure that an emulator could bypass a nasty corporate firewall and HTTP proxy so that we could test the android browser. The principle should be sound though.

Update: Nope, I played around with it a whole lot and found no nice solutions. I am not good enough at iptables to set up a valid tunnel that way that works for the server end.

Regards,
Mikael

Mikael Ohlson
Also, I just found that using wireshark to debug your firewall settings helps. A lot. :-)
Mikael Ohlson
A: 

Hi Mikael, thanks for your reply! The problem is the following.

Given two computers:

-PC1 (address:160.98.55.202)

-PC2 (address:160.98.55.203)

start, respectively:

-avd_1 on PC1 as ServerSocket (SERVER)

-avd_2 on PC2 as Socket (CLIENT)

The Client application on avd_2 have to send data to Server application on avd_1.

I used the second approach to allow comunication on the same computers, but this approach does not allow communication between two emulators on different machine!

Thanks for the first approach suggested!

If you have any other suggestions I would be grateful!

Regards,

Deborah

Deborah
You are welcome! The combination of port forwarding between the PC and the emulator and masquerading ought to be able to get you sending data between the two emulators. Chris Stratton's answer describes the same idea. I am updating my answer a bit.
Mikael Ohlson
Mikael soon I'll try to connect two emulators using the -shared-net-id <number> command line option when starting the emulator. Thanks
Deborah
+1  A: 

An emulator normally has outbound access to the development machine's LAN or internet connection, so the problem is on the inbound side.

You can use an emulator or ADB port forward to send traffic into the emulator, but possibly only locally originating traffic on the development machine's loopback interface, and not external traffic. If that is indeed the case, the simplest thing would probably be to write or configure a port forwarder that listens on the development machine's external interface and forwards to the port that is forwarded into the emulator.

Chris Stratton
Hi Chris! Thanks for your reply! I already use this approach, I'm looking for another approach, if it exist :)
Deborah
A standalone forwarding daemon is likely to be a lot simpler than the alternatives of recompiling adb or the emulator itself to listen on an external interface... I suppose another option would be to run the x86 build of android in virtualbox, or wait and see if the hints of the official emulator moving in that direction prove true. Or use a hardware device (beagle board?) instead of an emulator.
Chris Stratton