Android Emulators
Android emulators let developers set up virtual Android devices on their workstation. They can be useful for quick testing early in the development cycle.
Android Emulators
Android emulators replicate device features on your workstation. But they aren’t nearly enough to release software in the real world. Instead, run manual & automated app tests on thousands of real Android devices. Start Free.
Trusted by more than 50,000 customers globally
72% of all mobile devices currently run on Android or modified versions of it; from your Motorolas and LGs to Pixels, Samsungs and so many others. The variety is great, ever-growing… and problematic for developers in a hurry to ship.
Bug-free releases need rapid testing from Day One. In Continuous Delivery, developers don’t have the time -and often, resources -to test every function on a diverse selection of real Android devices.
As a workaround, they use Android emulators. Here’s all you need to know about the tool, how it works, where it’s used, and to what extent you can rely on it when you are testing your native Android or web apps.
What are Android Emulators?
An Android emulator is a tool that creates virtual Android devices (with software and hardware) on your computer. Note that:
- It is a program (a process that runs on your computer’s operating system).
- It works by mimicking the guest device’s architecture (more on that in a bit).
In order to better understand what Android emulators are capable of, you should know how they work.
How do Android Emulators Work?
Complete platform-virtualization (hardware and software emulation) is possible with Quick Emulator (QEMU).
Quick Emulator (QEMU)
QEMU–shorthand for Quick EMUlator. It’s an open-source and incredibly versatile tool. It can run on a large variety of host (workstation) CPUs/OSs and emulate an even larger range of guest CPUs/OSs.
QEMU powers most Android emulators (including the one by Android Developer Studio).
How it Works: It mimics guest device hardware. Then it translates the Application Binary Interface (ABI) of the guest device to match that of the host device. You equip this with with an OS and run it like a program on your computer.
The translation of CPU architectures is a complex, time-consuming process which makes emulation almost painfully slow. Thankfully, it can be skipped if the guest and the host CPU architectures are the same, with the help of a hypervisor.
Hypervisors
Before 2017, Android Developer Studio’s emulator had to translate Android’s ARM architecture to match the Intel/AMD architectures commonly used in PCs.
With the release of version 25.3.0, Developer Studio upgraded their emulator to support hardware-assisted virtualization.
How it works: When the guest and the host devices have same instruction architecture (say, x86 Android system images and x86 Intel processor), QEMU skips the ‘binary translation’ part and runs the guest device directly on the host CPU. This is called hardware-assisted virtualization.
You need a hypervisor to enable this. Intel’s HAXM (Hardware Acceleration Execution Manager) is a hypervisor component for Windows and macOS. There’s KVM (Kernel-based Virtual Machine) for Linux.
x86 Android ABIs (Application Binary Interface, or system images) are now available to support hardware-acceleration on most computers. If your CPU supports it, the Android emulator prompts you to enable or install the hypervisor in order to speed up virtual device performance.
With hardware-acceleration, the Android emulator can run virtual devices at speeds similar to that of your workstation CPU.
Now that you know how it works, here’s a brief introduction to the most popular Android emulator out there.
Android Emulator (by Android Developer Studio)
Post the release of version 25.3.0, the Android Emulator is distributed separately from Android SDK tools.
To install it from your Android Developer Studio console, go to Configure -> SDK Manager -> Android SDK. Within this screen, under the ‘SDK Tools’ tab, you’ll find the Android Emulator. Check the box and click OK to install it.
The Android emulator can be tricky to set up. Here’s a brief walkthrough:
Hardware Prerequisites
In order to work with Android emulator, you’ll need SDK version 26.1.1 or above and a PC/laptop with 64 or 86-bit processor. If you want to work with Android 8.1 or above, you’ll need a webcam that can capture 720p frames.
The emulator may prompt you to enable hardware-acceleration (to speed up virtual device performance). For this, you’ll need HAXM version 7.2.0-the Intel hypervisor we mentioned above.
Windows and Linux users will need more components, depending on their processor family:
- Intel: Intel VT-x and Intel EM64T (Intel 64) support; Execute Disable (XD) Bit capability.
- AMD (Linux): AMD Virtualization (AMD-V) support; SIMD Extensions set 3.
- AMD (Windows): Android Studio v3.2 or above; Windows Hypervisor Platform API.
Once you’re done with the installation, you’ll arrive at the Android Virtual Device (AVD) Manager:
Android Virtual Device Manager – Things to Note
AVD Manager lets you set up and configure your virtual Android devices. Some key points:
- Device Type: Contains pre-configured, manufacturer-specific device profiles for TV, Phone, Tablet, and Wear OS. You can customize screen size and certain external capabilities–or import a profile of your own. Interestingly, the Google Play Store and the Compatibility Test Suite are only available for a very limited number of devices–ones that meet the Android Compatibility Program criteria. You cannot add this capability to a cloned or custom device profile.
- System Image: Lets you equip the virtual device with a system image/ABI and an Android OS version. ABIs come in ARM, x86, x86-64 variants for different Android OS versions/APIs. Each ABI has a file size of about 900 MB. The emulator will recommend ABIs that are similar in architecture to your workstation processor, but you can pick others (with a trade-off in emulator performance). Only certain system images have Google APIs (which give you access to Google apps like Maps, Gmail, etc.).
- Verify Configuration: Allows you to change previously defined hardware/software profiles and configure some startup settings for the virtual device (name, orientation etc.)
Once you click ‘Finish’, the emulator launches the virtual device instance with your specifications–complete with extended controls to adjust device rotation, geolocation, camera, fingerprint sensor, network latency, battery state, and more.
You can test your web app, a project from Android Studio or upload a native app APK from your own device.
By default, these virtual device instances get saved in the state they were in when you closed them. You can also save snapshots of the device state (includes OS, your app/project, and user data) and pick up where you left off later.
Third-Party Alternatives to Developer Studio’s Android Emulator
Before version 25.3.0, most developers learned to stay away from the slow Android emulator that came with Developer Studio. So for early-stage testing, they used third-party online Android emulators. Genymotion was a popular choice.
Today, there are third-party Android emulators like Bluestacks, Nox, MeMu, etc. geared towards gamers who want uninterrupted gameplay and better controls of PC/laptop for immersive Android games (think PubG, Battle Royale Mode, Iron Throne, et al).
Some developers still prefer these alternatives. Since they have fewer extended controls than the Developer Studio emulator, they create and launch virtual device instances a lot faster. But for all the purported benefits, there are trade-offs with third-party/online Android emulators:
- Cryptocurrency Miners: In July 2018, a redditor’s investigation revealed that AndY Android emulator dropped a cryptocurrency miner on users’ devices.
- Fake app-rating farms: Some third-party emulators periodically force users to download and rate random apps from the Play store.
- Bloating: Some vendors monetize their emulators via in-app ads. Multiple ad calls and heavy ad creatives cause bloating and lag.
Android Emulator: Capabilities and Limitations
The latest Android emulator by Developer Studio can closely imitate a real Android device. But it still has its limitations.
Capabilities
Data transfer is faster on a virtual device (than a physical device connected via USB). The drag-and-drop file upload lets you place .apk files from your computer to the virtual mobile device. It’s particularly great when developers need to quickly test apps under context.
The emulator is also pretty useful when you’re working with physical sensors like the accelerometer. If you were testing a specific app feature that relies on the sensors, it’ll be easier to configure the settings through the visual, extended controls of the emulator.
Limitations
The most popular chipset for Android smartphones out there is ARM v7a. Most PCs/laptops run on Intel (x86). Recall that guest and host CPU architectures need to match for faster emulation. Basically, without a computer equipped with an ARM processor, you’re stuck with poor emulation of most of the commercially-available Android devices.
The AVD Manager creates separate directories to store each virtual device’s user data, SD card data, and cache. A single virtual device can take as much as 3.5GB of your disk space. Over time, a library of virtual devices will clam up your workstation.
Virtual devices’ performance is affected by that of your workstation. The emulator will crash and burn if you don’t have enough free disk space at launch.
Enabling hardware-acceleration takes care of performance issues. But setting up hardware-acceleration is a complex process that even experienced developers struggle with. The results often lead to complete system failure.
Android emulator isn’t reliable when it comes to understanding app interactions with the native device environment. For instance, you’d never know:
- Which background processes your app runs
- How front-end appears in different brightness levels
- How the app responds to a complete range of touch-gestures
Testing with Android Emulators and Real Android Devices
In CI/CD pipelines, developers execute tests on code before committing changes to a branch. After some quick unit testing within the IDE, functional and instrumentation testing take precedence.
You can execute some instrumented tests on Android emulator. An example would be verifying that the code correctly handles app-specific or core platform resource files (like font, animations, UI, etc.), or testing to see if external dependencies on ‘sign-up via connected apps’ (Facebook, Google etc.) functionality works.
App Performance testing is done to verify that interactions are smooth, that there’s no jank (dropped frames), and that the app uses device resources (battery and memory) within reasonable constraints. To get accurate results, you first need an accurate measure of the CPU and graphics capabilities of the target device.
At best, the Android emulator can give you virtual devices running on near-native speed. There’s no way you can expect native results with them. On virtual devices, you can’t test your Android app’s performance against any benchmarks.
Plus-and this goes without saying-there’s no easy or reliable workaround that’d let you test native or web apps at scale with Android emulators.
For serious, pre-release cross browser testing (on UI and all functionalities), you will need a diverse collection of real Android devices. QA engineers use testing automation frameworks like Appium or Espresso, write test scripts, and execute them on as many different Android devices as necessary to meet the benchmarked compatibility standards for a given target market.
Comparison: Real Device Cloud and Android Emulators
Listed below is a detailed comparison of Android emulator and Real Device Cloud.
| Real Device Cloud | Android Emulator |
| Real Device Cloud consists of real android devices hosted on a server. Therefore, when you are testing, you are using a real device and not a mimic of the device. | An Android Emulator is not an actual device. It mimics the software and hardware of the device and allows you to test it. |
| Real Device Cloud allows you to test performance issues and hardware capabilities. | With Android Emulators, you cannot simulate performance issues or hardware capabilities. |
| It offers real-time performance and functional testing. | Android Emulators are used only to test functional test case executions. |
| Testing on Real Device Cloud is cost-effective and cuts down the setup and operational costs by at least 50 times. | You can either download software or purchase licences. That said, testing on files downloaded from the internet is not quite reliable. Also, testing on emulators is not efficient. |
| Testing on Real Device Cloud is 100% accurate as you are using the actual device to test on. | Testing on Android Emulator is not accurate as these are simulated or replicas of the original device. |
| With Real Device Cloud, you can identify performance testing issues like notifications, network, location, battery, etc. | Android Emulators cannot identify performance issues related to the hardware like battery, location, network etc. |
| Supports cross browser testing on real devices | Cross browser testing is done on emulated browsers |
