"You can invest more into android emulator hosting hardware (i.e. get bare metal instances) and reap the benefits later" will be the tagline I would start with because that really is the gist of this entire post (minus some really cool demonstration scripts I've got for you)
Make your emulators Faster! 💥
Let's pick up from where we left off and talk about making your emulators faster. In the normal t2 instances, as we know, there is a hypervisor layer on top of the instance hardware, hence abstracting the hardware layer from the emulator we want to run on it, and thus, we can't use out good old hardware acceleration on top of it.
But what if, we take away the hypervisor layer? No, you can't do it with a piece of code but you can definitely get it by investing some odd $4 per hour and get a machine that can run 40 emulators at once (tried and tested statistic).
That's exactly how we pulled off a mass testing fleet with a variety of emulators all running simultaneously on a single machine. Since the hypervisor layer is stripped away, you get an emulator which is at least 10 times faster than the old armeabi 64bit models.
Isn't it too costly? 💸
It'll definitely take investment and on-demand instances are really costly by amazon (or really any cloud provider) as far as bare metal instances are concerned, but let's really do the math.
A high performing Genymotion PaaS setup would cost you: $0.7 per emulator
A bare metal instance at maximum load would cost you: $4.8/40 = $0.12 per emulator.
See? Simple maths. To get a profitable testing fleet, you really do need to splash the cash (hence the title, solutions for an organization)
Soo, which system image to pick? 🤔
I'll recommend android-28's google API version (that too x86 64-bit version) for further checking out the emulators. To get that system image, please run the following commands
$ sdkmanager "system-images;android-28;default;x86_64"
But why?
- This system image has a fairly functioning Google Apps support.
- Enabling root access isn't much of a pain, a simple command (adb root) would do the trick.
- You can play around with your emulator configurations and convert this AVD into whatever device you wish (I mean the identity, of course)
Enabling hardware acceleration in bare metal 🏃♂️
In any bare metal instance (let's say m5.metal), we need to follow the old instructions which we did so far in the first post. Now follow the following commands to set up the KVM hypervisor in ubuntu 18.
$ sudo apt-get install qemu-kvm libvirt-bin virtinst bridge-utils cpu-checker
$ sudo usermod --append --groups kvm 'echo $USER'
$ echo 'KERNEL=="kvm", GROUP="kvm", MODE="0666", OPTIONS+="static_node=kvm"' \
| sudo tee /etc/udev/rules.d/99-kvm4all.rules
$ sudo udevadm control --reload-rules
$ sudo udevadm trigger --name-match=kvm
and this should be it. Now you can start any emulator by a simple command :
$ emulator @emulatorName
and this will automatically utilize KVM hypervisor to boot your emulator (PS, if you are using the system image of android-28 and x86_64 architecture, you should see your emulator booting up within 20 seconds).
And this wraps us our parts on how to run fast emulators, how about, we try how to maybe install, run and uninstall apps in our emulator programmatically?
Setup the repository for demo 🏢
The aim of this repository is to empower anyone to set up the emulators and try them out in order to witness the beauty (and the pain, if you have < 8 GB of RAM in your system) these Android emulators carry with them.
Head over to Emulator CLI Autocompleter and follow the instructions in Readme to set it up!
uds5501
/
Emulator-CLI-Autocompleter
Python autocomplete CLI for android emulators (Creation and APK Run demonstration)
Thanks for Reading my Blog!
The .zip file contains the legacy command line tools given to setup your emulator environment To setup your emulator environment correctly, please follow the blog instructions given in either of the 2 posts
Using the emulator demo script (with autocompletion support)
Emulator CLI is generally boring and anyone in the automation team can say amen to the fact that staring at a non saucy and tedious CLI can be a tad bit unproductive. Here is my bit to make the terminal a colourful play ground, at least, in the terms of autocompletion behaviour which is more or less non existent in the traditional command line tools provided by our dear Android team.
The script uses the prompt-toolkit to implement interactive CLI experience for the user. You can check out the source code in the internal directory.
Requirements to run the script
…$ sdkmanager "build-tools;30.0.2"
$ export PATH=$PATH:~/path-to-built-tools/build-tools/30.0.2
The following CLI tool gives you an auto-completion feature in certain areas like system image picking, AVD boot, and APK choices. The repository has been created with python as the scripting tool and python-prompt as the auto-completion support.
Psst… the following demonstrations have been done on an 8 GB, i7 system, So the results are at least 30–40 seconds slower than in actual systems.
Creating an AVD programmatically ⚙️
Here we can create an AVD programmatically using a script, currently, 3 options are provided for system images which you have to pre-install using standard SDK manager installation commands.
The python prompt helps in selecting the SDK image you would like to pick, saving all the words you would've to type xD
Running an entire demo loop on created AVD 💎
In this particular loop, we are going to install our good old Twitter app in one of AVDs and see how smoothly it installs, runs, and finally gets uninstalled on 8 GB of host RAM.
In the demonstration, it's a Twitter application, you can run any apk you want but you would need to put the APK in the apk/ directory for the prompt to load the suggestion.
In the above image, you can see that the tool captured 7 AVDs on the local system and proceeds to suggest the ones which match the name you are typing.
In the above image, the auto-completion suggests the APK and the package name it carries, the size of the application, and release versioning.
… and that would be the end of the demonstration ✨
What to expect from the next post? 🎓
In simple bullet points
- A more robust demonstration script for easily playing around with your emulators
- Improvement in costing solutions and how to scale up the current solution so that it costs us 5 times cheaper but is easier to scale.
Resources 🔗
- Github CLI Autocompleter demonstration script
- Python prompt tool kit
- AWS instance pricing guide
Top comments (0)