[Feature Request] Support for launching multiple emulators at once?

[sphanley]

I've got a use case where I want to launch three emulators at the same time, to execute my tests in parallel. Does this plugin support that? I'd appreciate any pointers - I'm happy to try to help contribute, either to documentation or functionality, if appropriate.

[quittle]

Hey, thanks for the query. The plugin doesn't support that right now but I don't see why it couldn't and don't have a problem with that functionality being added.

I do have some questions about your usecase.

• Do you have a need for the emulators to be the same or different?
• Why do you want multiple emulators? Is it just to speed up your tests?
• How many emulators do you want to launch at once?

[sphanley]

Thanks for the quick response! In our current implementation, we're launching three identical emulators, so that we can run tests in parallel - so yeah, as you inferred, it's just to be able to run a large test suite faster. We've settled on three emulators as a good balance of speed and performance - in the past we've used GoJuno's now defunct Swarmer tool for this, but we're looking for a convenient non-deprecated alternative aside from just scripting the emulator creation ourselves.

[quittle]

I see, if you would be willing to submit a PR, I'd be happy to review and land it. To me, the biggest question is how the configuration/extension would work.

Playing with the syntax, I think the cleanest would be a new field named instances in the emulator block that allows you to specify how many emulators to start and defaults to 1.

androidEmulator {
    emulator {
        instances 3
    }
}

In the long term, I can imagine supporting multiple emulator {} blocks so you can configure multiple configurations of emulators to be started.

We will need to make sure that the name of each emulator is unique, even if specified. I would be happy with suffixing the emulator names with _{n} if the instance value is greater than 1. I also suspect that there will be a small change required in the plugin when determining the port the use since now the first-N available ports need to be chosen.

I know I just dumped a lot here, but are you willing to take a stab at this change yourself?

[sphanley]

I’d love to take a stab at! I’m not super familiar with Gradle plugin development, so I’ll have to take a bit to get familiar with the existing codebase, but I’ll see what I can do - the approaches you suggested make total sense. Thanks for the discussion and the openness to a contribution!

[quittle]

Hey @sphanley, just checking in since it's been a while. How are your efforts going to try and do it yourself?

[sphanley]

Hey @quittle, thanks for checking in! So I didn't end up making it very far - ran into some design challenges, partially just due to my own unfamiliarity with building a Gradle plugin, and then just got super sidetracked with other priorities and and never really revisited it. Hoping to circle back to it someday, but it's not near the top of my list at this point, unfortunately.