Description
Hi! Thanks for trying out this action.
I'd like to share a few words on the recently added Linux support to give you a bit of context on why it's much slower than running on macos.
In general if you run this action on a Linux VM (e.g. ubuntu-latest), you'll get very few benefits over other CI solutions (perhaps other than easier configuration and less scripting) as there's no hardware acceleration on ubuntu VMs provided by GitHub Actions.
While you can sort of have some versions of the emulators running without hardware acceleration, in practice you really need hardware acceleration enabled to run the Android Emulator, period. In fact I almost believe that the emulator binary should just not start at all and throw an error if it can't be hardware-accelerated, otherwise it defeats the purpose of having these modern x86, x86_64 system images.
To give you a bit more context, I created this action solely to take advantage of the hardware acceleration support on the macos VM (enabled by HAXM which is installed on macos VMs), and never intended to add Linux support cause I know it won't be a good experience (at least not better than what you already have) without hardware acceleration.
I wrote this article about running Android emulator on CI which should give you more context on running instrumentation tests on CI in general and why the lack of hardware acceleration support from the host machine is still the biggest challenge for running fast and stable instrumented tests on CI.
I understand this might be a bit of a disappointment for some of you, but unfortunately this is a much bigger problem than what can be solved / improved by a GitHub Action.
If you looked at the code, there's no magic at all. It basically automates the following process and makes it a little easier to configure for the common use cases:
- Install / update the required Android SDK components including build-tools, platform-tools, platform (for the required API level), emulator and system-images (for the required API level).
- Create a new instance of AVD with the provided configurations.
- Launch a new Emulator with the provided configurations.
- Wait until the Emulator is booted and ready for use.
- Run a custom script provided by user once the Emulator is up and running - e.g. ./gradlew connectedCheck.
- Kill the Emulator and finish the action.
As soon as you see "Emulator booted." in the log, the job of this action is basically done as from this point on the environment is handed over to your script so anything that works / doesn't work would not have much to do with the action itself, which only makes sure a live Emulator instance is available in the background.
For those of you who are not fortunate enough to be able to use the macOS VM, as an alternative I'd encourage you to have a look at Cirrus CI which provides KVM-enabled Linux VMs and # seems pretty reasonable (100% free for opensource projects). I wrote a long article going over all the features relevant to Android and how you can optimize your pipeline etc. I also created some templates to help you get started.
Hope that gives you some context regarding the Linux support, why it's expected to be slow and the alternative you might want to look at.
Thanks!