Stable naming and query for Ubuntu Emulator device ID

[Benjamin Zeller]

Currently the device ID for the ubuntu emulator is changed on every boot,
its incremented for every emulator running in paralell.
This is a problem if multiple emulators are used together with the SDK and QtC.

In QtC devices need to have a unique ID, because all device settings need to
be stored and referenced somehow. If the device ID changes this can create problems
(for example a armhf Toolchain could be linked to a x86 emulator).

In addition a method to query the created ID for all emulators is required, in order
to map the output from ubuntu-emulator list to registered devices inside QtC when
the emulator is not running.

[Ricardo Salveti (rsalveti)]

Looking internally how the naming happens, it's basically a fixed socket and adb host command that only allows the port itself to change from one instance to another.

Without specifying any port when calling the emulator, it'll start at 5554 and increase +2 for every other instance, until it reaches 5584. There's no easy way to use an id or name it differently than locking it into a specific port. This is a limitation in the adb protocol, as the emulator is a special case (it uses tcp instead of usb).

One possible way to map the emulator image with the runtime instance would be to force a different port per emulator, and export that data with the 'ubuntu-emulator' tool (list). With this you could at least know how to connect to the right instance, as long you don't have any android emulator running at the same time (as both will end up using adb).

Limitations:
- The console port number must be an even integer between 5554 and 5584, inclusive. <port>+1 must also be free and will be reserved for ADB.
- The mapping would not necessarily be correct if you also start the Android emulator. One way to workaround that would be to start with 5584 and decrease -2 at every new emulator image that gets created.

As there's not much we can do in the android side, moving this bug to goget-ubuntu-touch.

[Sergio Schvezov (sergiusens)]

Does returning a json solve you problem?

something like

ubuntu-emulator list --verbose

[
{
    "arch": "armhf",
    "adbPort": 8000,
    "name": "myinstance",
    "version": "302",
    "extendedVersion": "ubuntu=.*,"
},
{
...
}
]

am I missing anything?

[Ricardo Salveti (rsalveti)]

As we discussed today at the IRC, it'd probably be better for us to just export the --port argument in ubuntu-emulator, and let the SDK tool to decide which port to use when starting the emulator. That way the SDK itself can keep map the image with the running instance.

As we can't start 2 different instances at the same port, the SDK could just try to start until it finds an open port (between the valid port range).

zbenjamin, would that work for you?

[Benjamin Zeller (zeller-benjamin)]

Thats a good question, my problem is not only to map the running emulators to the QtC settings, but also to map the not running emulators, like emu1 will be emulator1234 when its running.

Of course i could use the --port and store the used port inside QtC settings. But that will fail as soon as someone starts a emulator outside of QtC, but QtC still will pick it up :/

[Sergio Schvezov (sergiusens)]

On Tue, May 6, 2014 at 8:23 AM, zbenjamin <email address hidden>wrote:

> Thats a good question, my problem is not only to map the running
> emulators to the QtC settings, but also to map the not running
> emulators, like emu1 will be emulator1234 when its running.
>
> Of course i could use the --port and store the used port inside QtC
> settings. But that will fail as soon as someone starts a emulator
> outside of QtC, but QtC still will pick it up :/
>

I think we can do what we originally mentioned with a twist:

ubuntu-emulator create emulator # creates an instance with no preassigned
port
ubuntu-emulator run emulator # assigns a port to an emulator by checking
the available ports
ubuntu-emulator list --verbose # dumps a json; if the emulator is running
it will list a port, if not it won't

Of course I'll have to deal with the burden of stale files due to
killing/stopping the emulator in many different ways.