I think a step like this would work quite well

step([
        $class: 'AndroidEmulator',
        osVersion: 'android-23',
        screenResolution: '1080x1920',
        screenDensity: 'xxhdpi',
        deviceLocale: 'en_US',
        targetAbi: 'x86',
        sdCardSize: '200M',
        showWindow: true,
        commandLineOptions: '-noaudio -gpu mesa -qemu -m 1024 -enable-kvm'
])

I'm interested in implementing this (no promises though)
(I have parts of it working already, based on the pipeline-dsl branch)
Could I discuss here / somewhere before creating a Pull Request?

garethnz Please do! I've not ever contributed to a Jenkins plugin before but I will definitely provide input and code review.

garethnz: Sure, feel free to discuss your ideas here. If you have code pushed, you could also link to any branches that you might have.

But note that the code in that experimental pipeline-dsl branch isn't amazing and, having discussed it with Kohsuke and Jesse (aka the pipeline gurus) at Jenkins World, it's maybe not going in the right direction. Using DSLs in this way apparently isn't really pipeline-y (and won't work with the Snippet Generator), and the way I implemented it means that we lose out on some of the important pipeline features, like durability (AbstractSynchronousNonBlockingStepExecution doesn't support it; but without this I think I ended up blocking the CPS thread).
i.e. it's generally preferable to provide a series of pipeline steps.

I really need to get back into the code, and look at my notes from the Jenkins World discussions, think again about the design, and also think about how to incorporate automated installation of system images etc.
Pipeline support is currently #1 on my list of things to implement, and I do have a lot of free time right now, but I'm about to go on holiday for two weeks…

Anyway, if you have any ideas, or anything to share, I'd be happy to take a look at it.

orrc Sorry, no code pushed yet.

Yes I wasn't sure about the DSL either, my first steps was to get it working by refactoring AndroidEmulator.java and supporting classes to separate out the logic of managing the emulator and the handling required for a BuildWrapper (Keeping AndroidEmulator.java as the BuildWrapper so as not to break plugin upgrades) - Calling the logic only class "AndroidEmulatorManager".

Pipeline specific things:

• I left your Dsl.groovy mostly as is (except I added a 'withAvd(String name)' to use a pre-existing AVD).
• For specifying all AVD details, I went with what ahorner suggested above. (Didn't quite have that working last I worked on this, but it was close)
• I made the WithAndroidEmulatorStepExecution similar to the build wrapper, using the AndroidEmulatorManager to manage the emulator instance for the step.

Regarding how the DSL should work, I think something like what Job Dsl does?

Allow users to instantiate an AndroidEmulatorManager, then provide methods (Steps) like .boot(), .bootAsync(), runWith({}), stop().
unsure how exactly how to do this at present.
(You'd also have to provide a way to ensure stop is called in the case of some other exception/error - if the user wants).

What were you thinking of doing for the DSL?

Hi guys, any news on this? Would be really nice to have it.

Any updates?  This would be such an awesome feature.

Sorry. 
I did manage to get a version working (that only supported loading existing AVDs, not creating new ones).

My company may instead move to:

https://github.com/AzimoLabs/fastlane-plugin-automated-test-emulator-run

As our builds use fastlane anyway.

So I assume still nothing new here?

In theory supporting Pipeline should be relatively easy for the BuildWrapper, it would just need to extend

SimpleBuildWrapper

instead of

BuildWrapper

I tried getting that to work, the problem is that there is a lot of custom stuff happening (e.g. manual expansion of environment variables) that were not trivial to transfer.

slow progress on feature branch https://github.com/jenkinsci/android-emulator-plugin/tree/feature/pipeline