Android emulator is CPU Archives

You no longer need a dedicated Android phone or tablet to experience the 1.4 million apps available in Google Play. Android emulators make it easy to run Google's mobile OS side by side with Windows, so you can always access your favorite mobile messaging apps, games and more on the PCs you already own — and take advantage of your larger monitor, hardware keyboard and other peripherals. Here are the best ways to run Android on your computer.

How Android Emulators Work

Emulators are programs that basically mimic or act like the hardware and operating system of other machines. When you install an emulator, you get a virtual console in which you can install other apps and play around with the system. Whether you want to check out Android before you buy a device, develop and test your own Android apps, expand Windows' paltry app selection, or sync apps between your Android phone or tablet and your PC, you have a number of utilities to choose from.

AMIDuOS

Of all the Android emulators we tested, AMIDuOS performed the best. On AnTuTu benchmarks, AMIDuOS scored 45,611, compared to BlueStacks' score of 28,311 and Andy's showing of 31,299. AMIDuOS pulls off this impressive performance by running Android apps natively on your computer's x86 processor whenever possible, rather than emulating Android devices' less powerful ARM processors. AMIDuOS ran the performance-demanding Google Earth smoothly (and was able to find my location), detected and followed my "OK, Google" Google Now voice commands, and even allowed for copying and pasting text between Android and Windows.

The fast performance comes at a price — $10 for a lifetime license per computer (after a 30-day trial) and, like other emulators, high memory and CPU usage. The more memory and processing power your computer has, the better.

For the money, though, AMIDuOS offers excellent performance and features, such as the ability to emulate a rooted Android device (so you can try apps and settings that you might not attempt with your $500 phone or tablet). Soon, it will also run Android 5.0 Lollipop.

Best for: People who want to run graphics-intensive or otherwise demanding Android apps, have enough system resources to run the virtual machine and/or want to try Android in root mode.

Read AMIDuOS Review

Andy

Andy provides the full Android (4.2.2 KitKat) experience in either full-screen or windowed mode. You can basically do anything in Andy that you could on an Android tablet or phone, including adding widgets to your home screen, backing up your virtual device to Google and receiving app notifications. The latter comes in handy, because instead of leaving a browser tab open for Facebook or Gmail or needing your phone for messaging apps like Snapchat, you can just get the notifications in Andy.

The program offers many ways for Android to interact with your PC (with either x86 processors or ARM processors) and even your phone. You can use your Android phone as a controller for Andy on your desktop (helpful when playing games that require tilting or tapping, if your computer doesn't support these). Android apps can be launched from your Windows desktop, and you can copy files between Android and Windows through a shared folder.

Andy is also attractively 100 percent free, although its parent company is an alleged adware distributor (a fact that might give some people pause). The program also ran disturbingly slow on my two-year-old laptop, so a newer computer with at least 4GB of RAM, if not more, is recommended if you want to run Android apps with Andy.

Best for: Those who don't have a touch-screen PC and who want to use their Android device as a game controller, have enough system resources to run the virtual machine, have a laptop with an ARM processor, want to run Andy on both Windows and Mac, and/or want to run Android in a flexible, resizable window (the other programs reviewed here only offer a fixed-size window).

Read Andy Review

BlueStacks

BlueStacks App Player was one of the first Android emulators. Rather than virtualize the full Android OS, the program lets you install and run individual Android apps on your PC, either in full-screen or windowed mode. According to the company, the system is compatible with 96 percent of the apps available in Google Play and 86 percent of Android games.

While you can search for any Android app to install on your PC using BlueStacks, it is particularly focused on games, as its home page filled with suggested games by category reveals. If you have a touch-screen computer, you can interact with Android apps just like you would on an Android phone or tablet: by tapping, swiping and tilting away.

Unfortunately, although BlueStacks runs many games quite well, I found the program to be buggy and the user interface inflexible. However, it is a free program that doesn't take up a lot of resources (it requires just 2GB of RAM) — as long as you're willing to occasionally install BlueStacks' recommended apps. Otherwise, the program costs $2 a month to keep playing.

Best for: people who don't need the entire Android OS, want a free solution (and are OK with installing random apps) and just want to play Android games, particularly on a resource-limited computer.

Read BlueStacks Review

Other Ways to Run Android in Windows

BlueStacks, Andy and AMIDuOS aren't the only Android emulators in town.

YouWave is another option, but it costs a comparably hefty $19.99 and runs only the older Android 4.0.4 Ice Cream Sandwich.

Genymotion, on the other hand, is free, and, like AMIDuOS, takes advantage of your computer's x86 architecture for better performance. It runs on Windows, Mac and Linux. You can choose a specific device to emulate — a Google Nexus 9 running the latest version of Android (5.10), for example, or another Android tablet or phone — and create multiple virtual machines. While Genymotion perfectly emulates the full Android environment, however, it's a tool meant more for Android developers. It doesn't include Google Play, so you can't install apps from there without work-arounds. And in my tests, I found bugs such as not being able to pinch to zoom in Google Maps. If you're willing to go through the steps to install Google Play, however, Genymotion runs most apps smoothly, including those using 3D graphics, but performance isn't as strong as with AMIDuOS.

The official Android SDK includes a mobile device emulator. Like Genymotion, it's meant primarily for developers to test their own Android apps on their computers. While it's possible to use the Android emulator in the Android SDK to try out apps you want to run, the emulator is notoriously slow — perhaps impossibly slow, even.

You can create your own Android emulator in Windows using VirtualBox and Android x86, but that's essentially like installing Andy or AMIDuOS, with more work involved and fewer user-interface controls.

In short, for a completely free option, you'll probably want to try either Andy or Genymotion. AMIDuOS, however, is a worthwhile $10 investment if you see yourself regularly using Android apps on your computer (and you can try it free for 30 days to see if it works for you).

Earlier this year, we switched our complete CI infrastructure from using Genymotion to using the Android Emulator. This had been a long time coming, and there were many reasons for us to switch, which we will discuss in detail in this blog post. Let’s start out by looking into why we chose to use Genymotion to start with.

Initially, It Worked for Us

Having a solid and well-tested framework is one of our main priorities, and as such, having the CI infrastructure to ensure that every merge gets tested is very important. Sadly, the Android emulator used to be quite slow, because it was actually emulating an ARM CPU. It was also notoriously unstable, which made it unsuitable for CI use.

Luckily for us, Genymotion solved our problem with these issues by providing an x86-based virtual device that was fast and stable. Since Genymotion runs the Android OS inside a VirtualBox VM and is capable of running Android at high speeds, even on less performant developer machines, it was the go-to choice for most Android developers when it arrived on the scene. Naturally, we also adopted Genymotion here at PSPDFKit, using it both for fast local development and for running our CI.

However, there were also downsides to using Genymotion (high license costs, maintenance effort, complicated setup, etc.), which, over the years, caused us to look into alternative solutions.

Why the Emulator

In recent years, Google took notice of the lack of performance and stability of its developer tools and the Android Emulator. With Project Marble, Google also invested time and effort in improving the speed and stability of its virtual devices, bringing them up to speed with (or even beyond) Genymotion when used for local development and CI purposes. This made us reconsider using it.

Moreover, there were additional reasons that ultimately motivated us to move away from Genymotion:

• Since the emulator ships as part of the Android SDK, it is much simpler to acquire and set up than Genymotion is (the latter also requires developers to sign up and purchase a license before being able to download and use the virtual device). This ease of setup is especially useful for other teams (like our QA team or other platform teams) that are less fond of Android development processes.
• The simplicity of setting up the Android Emulator also ousted Genymotion from being used by our Android developers locally during development. Having the Android Emulator locally but Genymotion on CI made it more difficult for us to reproduce test issues that only happened on CI machines. This cost time and got on our nerves.
• Cost-effective scaling was another concern. With only a hand full of Genymotion instances running in our CI, we felt the need for additional CI power but didn’t want our yearly costs to explode. Also, since the licensing system of Genymotion turned out to be cumbersome, the necessary work to keep the Genymotion machines up and running turned out to be substantial.
• Something that prevented us from scaling our Genymotion instances was that Genymotion requires a full desktop environment to be running, since there is no way to run it in headless mode. This meant that we required expensive macOS machines to run our CI infrastructure.
• This year’s advances in platform-independent emulator deployment using Docker images added extra fuel to the simmering idea of migrating to the Android Emulator (more on Docker-based emulation a bit further down in this post).

After repeatedly evaluating the stability and performance of the Android Emulator between 2017 and now, our team finally decided this year that the current state of the emulator and the benefits of switching to it would outweigh the necessary migration work — so we made the switch.

Migrating from Genymotion to AVDs

Migrating our CI infrastructure and tests to Android Virtual Devices (AVDs) wasn’t without its own challenges. Since setting up Docker to run our tests properly posed an additional hurdle (turns out fixing tests in a headless machine inside Docker is kind of complicated), we settled on the following strategy to get the emulator running on our CI machines:

• Set up the emulator to run directly on “bare metal” Linux machines by deploying the Android SDK to those machines.
• Ensure all of our instrumented tests run inside the new emulator.
• Do the “dockerization” of our emulators as a follow-up step.

Starting the Emulator on CI

The outline for how we run the emulator on our CI machines works as detailed below.

1. We are managing our CI using Buildkite (which replaced our Jenkins CI). This allows us to run multiple CI jobs and emulator instances in parallel on a single physical machine. The first step is to define a unique name and port for the emulator instance of our current job, which enables us to run multiple emulators on one host:

1. Then we make sure that adb is running on our CI machine:

1. Next, we remove any leftovers from previous builds. This is to ensure that we start clean in case a previous build failed for whatever reason:

1. We always create a fresh AVD for each test run so that there is no leftover state from previous runs:

1. Finally, we start the emulator:

Once the emulator is launched, we need to wait for it to fully finish booting before we can actually install and run our tests. To achieve this, we continually check the property until the emulator is booted or until we detect a startup issue:

And with that, we were ready to run our tests on CI. Of course, as we’ll see in the upcoming section, using Docker will save us the hassle of doing most of this emulator management manually in the future, but before getting to that, there is one more thing we needed to do.

Making Our Tests Run in The Emulator

For us, the work wasn’t done here. That’s because we also used this moment as an opportunity to update the Android version we run our tests on, and since we’ve had years of tests written to run on a 5.0.1 Genymotion device, we had to update all of our tests to work on our new test platform. During the migration, there were two kinds of tests that needed updating:

1. UI tests that rely on the specific size of a device. For example, we had tests that asserted views, and, after applying some touch gestures to them, these tests contained specific hardcoded bounds. While our new test devices emulated the same hardware (our tests use the Nexus 5X template), system UI changes between Android 5 and Android 9 made our tests fail because coordinates were still off from the expected output and they needed updating.
2. Tests that relied on being run on a specific API version for the behavior they were checking. Updating those tests wasn’t as easy as changing a few coordinates around as, for the most part, they required us to come up with entirely new test cases.

With this done and our tests running on our new CI infrastructure, it was time to look into what we could do to improve CI even further. Here’s what we already did:

• Our first improvement was to triple the number of available emulators on CI compared to what we ran using Genymotion, resulting in reduced CI waiting time.
• We implemented test sharding, a useful feature of the Android instrumentation runner, which allowed us to reduce turnaround times of our CI tests by about 60 percent, or about 30 minutes.

But there’s more to come.

Future Outlook

In migrating from Genymotion to the emulator, we have already improved our development workflows and CI testing environment a lot. But here are some more things we have planned to help make Android development at PSPDFKit faster and more stable.

Emulator in Docker

One of the benefits of the Android Emulator is its ability to be run inside a Docker container. Docker-based emulators provide better portability, and ultimately, much easier scalability at a low cost. During this year’s Google I/O, Google published a set of scripts for creating Docker images that can run the emulator. These scripts are now available on GitHub too, and are as simple to use as the following:

While running the emulator on “bare metal” Linux servers works for us right now, migrating to the Android Emulator paved the way to move our tests into Docker, which will remove additional dependencies on the Android SDK and NDK. Furthermore, using Docker would also enable us to run tests inside our own cloud-based infrastructure (like on Google Cloud, AWS, or Azure) for easier scaling.

Android Test Orchestrator

Another improvement we want to look into in the future is enabling the Android Test Orchestrator. The Orchestrator runs each test case in a separate process, ensuring that all cases run completely isolated from the rest of the test suite, thereby preventing tests from failing due to state leaking between them. Furthermore, using the Orchestrator also stabilizes test suite execution by keeping a single faulty test case from killing the entire test process, which would prevent the rest of the test suite from being executed properly. At the time of writing this post, we have already started looking into enabling this and run into two different issues.

The first issue is that previously written parameterized tests started to fail when we ran them using the Orchestrator. We found out that the Orchestrator doesn’t support path separators (”/”) inside test names because it creates a separate file for each test case it executes based on the test’s name. While it was easy to fix incompatible test names by avoiding path separators in them, it took some time to track this limitation down due to obscure test error messages and missing information in the Orchestrator documentation.

The other issue we are encountering is the test execution randomly stopping without any exception or other log pointing toward why. This is probably related to our own custom test runner, and it shouldn’t deter you from using the Orchestrator. In fact, we are already successfully using the Orchestrator to run instrumentation tests for our PDF Viewer project, which has a much smaller test base than our framework does.

Summary

In this blog post, we presented our journey of Android Virtual Device-testing at PSPDFKit. We showed that while Genymotion was a great fit for us in the past, the combination of Google’s investment in the Android Emulator and our ever-changing requirements made the emulator the better choice for us. While switching to the official Android Emulator took time and effort, the investment has already paid off, with faster CI speeds, better stability, and improved ease of use. We’re looking forward to the improvements we have planned, and we’re also excited about the future of the Android Emulator itself.

What is MS-DOS Emulation on the Internet Archive?
The Internet Archive's software collections have a number of in-browser emulators to allow limited access to software, by making the software play within (most) browsers. The majority of this is done with the JSMESS (Javascript MESS) system, which is utilized in multiple collections, such as the Console Living Room or the Internet Arcade. For one collection, the MS-DOS Software Library, we have implemented the EM-DOSBOX emulator, which is based off of the DOSBOX project and which is designed specifically for DOS-compatible programs.

The Program is running WAY TOO FAST!
Some of the programs running in EM-DOSBOX relied on timing loops and CPU types that the emulator is not showing. We're working on a solution where we can pre-repair the speed before running, but until then, there is a fix: While the program is running, press CTRL-F11 to slow the program down. Pressing CTRL-F11 repeatedly will slow it down further, until the speed is more reasonable. (Pressing CTRL-F12 repeatedly will attempt to speed things up.)

I want to save my game! How do I do that?
Currently, there is no way to save your game, although we are trying to work out if this is technologically possible.

I can see my mouse and the program's mouse.
In the programs where a mouse cursor is provided, your mouse will generally work. However, to prevent both mouse cursors (the DOS cursor and your computer's cursor) from being on the screen at the same time, select the full screen option.

I have questions or want to walk through a non-working program.
The MS-DOS emulation is part of the Software Library of the Internet Archive, which is overseen by curator Jason Scott Please mail him at jscott@archive.org with any questions, suggestions or discussions.

The program runs very slow.
The EM-DOSBOX emulator is a javascript program running in a browser - it requires a lot of CPU to run, and definitely requires the most up-to-date browsers to take advantages of speed enhancements. We highly suggest you update to the latest Chrome or Firefox to ensure the program runs at top speed. The difference between versions even a few months or a year apart can be multiple times. In a few rare cases, the game or program being run does certain video or programming tricks that confuse the emulator, and the whole program runs notably slow, slower than even a taxed system should run. This is due to incompatibility with the emulator, and unfortunately will require the DOSBOX project to improve emulation going forward.

It's not working for me. (Common Issues)
As it is experimental and very new technology, there are a number of places that the MS-DOS Em-DOSBOX emulator can fail to work.

The most common is browser incompatibility - the EM-DOSBOX emulator works best in the Firefox and Chrome browsers, but also works in Internet Explorer and Safari. Bear in mind that only the most recent versions of these browsers will work best with EM-DOSBOX.
If you do not see the DOSBOX Logo in the player, be sure you do not have javascript blockers or ad blockers working on the page - the player is created in Javascript.

If the browser has slowdown issues or crashes, please let us know - there might be a MS-DOS program that is not compatible with EM-DOSBOX in a way our testing has not yet revealed.
If the "spinning disk" after pressing SPACE to load the program never stops spinning, there is an error with the program image. Please let us know about the non-functioning program and we'll track down the issue.

These are the most common problems; be sure to contact the software curator if there are additional problems you are seeing.

My Favorite Game isn't in there! What's wrong?
There are multiple reasons the MS-DOS section might not have a game or application in its library. They include:

The game requires a CD-ROM's amount of information to run. Since this is an in-browser emulation, larger datasets (greater than 10 or 20mb) run into all sorts of issues when being loaded. The size, not the use of a CD-ROM, is the core issue, so even disk-based games that used a lot of space are not being loaded up.

The game, in some way, is not compatible with the EM-DOSBOX emulator. If we find the current incarnation of the emulator plus the version of the game is causing crashes, freezing or strange errors, we will likely remove the item just to limit frustration for users - there's nothing more bothersome than trying to track down a problem that could be anything from your browser to a strange programming choice made 25 years ago.

The game is still for sale. Happily, a number of vintage DOS programs have been updated, fixed for compatibility, and continue to be sold at a deep discount to a modern audience. Sites that provide sales to these updated DOS versions include Good Old Games and Steam.
Finally, we may simply not be aware of the application or game and not have an example of it. We're always adding more programs as we can.