Understanding Android Emulators

Context: you are trying to develop software for the Android platform, and want to test your software on an emulator.

About: this post is high-level.  This post mostly ties concepts together by linking to Wikipedia.

Disclaimer: this post is a work in progress and may contain errors.  I aim to organize concepts, such as in an outline, but the details are sketchy.

Developing for Android is cross-platform

Android is an OS running on an embedded computer.  Android devices are so weak (little memory, disk, or speed) that usually you develop on a different, host device.

(But there is now a IDE that is native, i.e. runs on an Android device: AIDE.  Probably it is most useful for small apps, or simple, command line tasks.)

Compiling a program is then cross-compiling.  An Android device is the target, the development computer is the host.

The universe of Android devices

There exists a large variety of Android devices.  The Android platform changes quickly, and there are many slightly different versions of the OS and hardware.  Android is open source, so any vendor is free to sell a device running any version of Android, or even Android OS that they have modified.

Also, a vendor may sell a product in different configurations, e.g. with more or less memory, larger screen, etc.

Testing an Android program

Comprehensive  testing of an Android app requires testing on many versions and products.

When developing cross-platform for Android (or in general) there are two options:

  • test on a real device
  • test on a device emulator

The main advantage of an emulator is: it’s free. You don’t have to buy the many, physical products to test on.

Uploading an Android app

To test on a real device, you must upload to the real device, across a connection (a cable or wireless.)

Uploading to on an emulator is fast, at the speed of memory transfers.  But execution on the emulator might be slow (depends on the technology of the host machine and the emulator.)

Android Emulators

Android emulators are called Android Virtual Devices (AVD.)  They are virtual machines.   They do virtualization.  They virtualize both the hardware and the software of the target device.

The virtualized hardware may include:

  • processor which may be a different architecture than the host, say ARM
  • keyboards, screens, and buttons
  • sensors (cameras, accelerometers, etc.)

AVD’s are similar to guest operating systems used with virtualization software such as VirtualBox.   The software that runs them is called virtualization software or a virtual machine monitor.  The Android Virtual Device Manager ( AVDM?) helps you manage AVD’s .  In the Eclipse IDE, the AVDM is in the menu Window>View Android Device Manager .

AVD’s are persistent

You create an AVD and it is still there the next development session.  You can install your software to an AVD  and it will still be installed the next time you run the AVD.

The data for an AVD is kept in hidden files ~/.avd/…  If the AVDM fails to manage an AVD (such as delete it) you can resort to fiddling with hidden files.

AVD’s are cheap.  It is usual to delete them and start over to make sure you have a clean starting state.

Android Debug Bridge

The ADB lets you issue commands to a running AVD.  It is a remote shell.  (It is a shell to the remote, virtual AVD.)  It has a command-line interface.

On Linux, you can get ADB:

>sudo apt-get install android-tools-adb

For example of its use, you can list files on the AVD:

adb shell “ls /data”

AVD’s are running or stopped

When you create an AVD, you create a specification for it.  When you run your app from an IDE, the IDE first runs the AVD.

Until an AVD is running, ADB doesn’t know about it:  “adb devices” may show no devices.  ADB doesn’t know the AVD specifications that the AVDM knows.

Speeding up an Android AVD

They are notoriously slow.  It may take many minutes for an AVD to power up.

There are some tricks you can use.


The universe of AVD’s

Each Android device has a corresponding AVD.

AVD’s  are provided:

  • bundled in the Android SDK by Google
  • or by a hardware vendor, i.e. Amazon Kindle Emulator
  • by third parties i.e. Genymotion

Alternative VMM’s for Android

A hypervisor or VMM is an application that helps a system administrator create and run virtual machines.  In this case, you as a software developer are acting in the role of system administrator.


Genymotion and Hardware-Assisted Virtualization

(Note: I have not tried Genymotion.  This section is not fact checked.)

Genymotion is faster because it uses hardware-assisted virtualization.

Genymotion has compiled the Android OS for the x86 instruction set.  Genymotion uses VirtualBox.  The Android OS runs as a guest OS.  When the host OS is running on x86 hardware (as many PC’s do), and the CPU includes support for hardware-assisted virtualization (as most recent CPU’s do), then instead of emulating the instruction set of the Android device, instructions are executed directly in the CPU.  For example, one virtual instruction may be executed by one real (CPU) instruction, instead of one virtual instruction executed by say ten real(CPU) instructions.

More specifically, Genymotion has compiled the Dalvik VM for the x86?  The Dalvik VM is the interpreter for the Android OS written in Java.


One thought on “Understanding Android Emulators

  1. Pingback: Using pydroid | plashless

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s