Logo Icon Logo
A Crowd-sourced Cookbook on Writing Great Android® Apps
GitHub logo Twitter logo OReilly Book Cover Art

Setting Up an Android Virtual Device (AVD) for App Testing

Published? true
FormatLanguage: WikiFormat

Problem:

Successful Apps must run on a wide range of Android devices and versions.

Solution:

Use the Android SDK's device emulation toolkit to configure combinations of devices and operating systems. Testing on various combinations reduces issues related to hardware differences in devices.

Discussion:

Android devices are manufactured to cover a wide market, from low cost to high specification and high value. Android is well established in the marketplace, there are a wide range of devices with a wide range of hardware options, running a variety of Android versions. A successful App will be one that can run on such a range of devices. An App developer will only be able to test on a very small range of physical devices. Fortunately a developer's confidence in their App can be boosted by using an Android Virtual Device (AVD).

A complied App can be tested on a physical device or a virtual device. An AVD is an emulation of an Android platform on a host machine, usually the development machine. AVDs simplify testing for these reasons:

  • Multiple AVD configurations can be created to test an App on different versions of Android.
  • Different (emulated) hardware configurations can be used, for example GPS or no GPS.
  • An AVD is automatically launched and your compiled App is installed on to it when the Run button is pressed.
  • You can test your App on many more combinations of Android version and hardware versions than physical devices you possess.
  • Testing on AVDs greatly reduces the amount of testing required on physical devices.
  • AVDs can be used alongside a physical device.
  • You don't need to handicap you physical device to induce error conditions, e.g. testing on a device with no SD card, just set up an AVD with no SD card.
  • An AVD can simulate network events without the costs involved in using a physical device, e.g. simulate phone calls or send an SMS between two AVDs.
  • Simulate GPS data from an AVD from different physical locations without moving from your desk.
  • When App users report bugs you can try and mimic their hardware configurations using AVDs.

An AVD can be configured using the Android Virtual Device Manager program, AVD Manager.exe, opened directly from the file system or from within Studio. Use the Tools then Android menu to select AVD Manager. Alternatively click the AVD Manager icon on the toolbar.

The Virtual Device Configuration wizard loads. Choose an existing profile or create a new one.

Configure the AVD properties:

Property Values Description
Device Name String Name of the device profile
Device Type Phone/Tablet, Wear or TV Device category
Screen Size Inches Length of screen diagonal
Resolution X and Y Pixels Number of width and height pixels
Memory Set RAM in bytes, KB, MB, GB or TB Amount of physical RAM emulated
Hardware Input Physical Back/Home/Menu buttons and Keyboard Emulate buttons and keyboard
Orientation Portrait and/or Landscape Supported orientation states
Cameras Front and/or Back Supported cameras (emulated or PC cam)
Sensors Accelerometer, Gyroscope, GPS, Proximity Supported sensors
Skin and frame Select appearance Skin the emulated device
System Select Android OS version Android API to emulate
Scale Auto or select dp units to pixels Customise screen density
Performance Auto, GPU for graphics, software emulation GPU Emulation
Multi-Core 1 to 4 Select number of cores
Network Speed Full, HSDPA, UMTS, EDGE, GPRS, HSCSD, GSM Emulate the network speed
Network Latency UMTS, EDGE, GPRS Emulate the network latency
VM Heap Java heap in bytes, KB, MB, GB or TB Java Virtual Machine heap
Internal Storage Non-removal space in bytes, KB, MB, GB or TB Emulated internal memory
SD card Size in bytes, KB, MB, GB or TB or existing file Emulated removable SD card
Keyboard Enable/Disable Allow keyboard input

Notes

When naming a new AVD make it descriptive. For example if emulating a device with a version 2.3 operating system and medium resolution screen (HVGA) a name such as Android-v2.3-HVGA is better than AndroidDevice.

CPU/ABI sets the target CPU type (ARM/x86/x86_64) and the Application Binary Interface (ABI) used by the CPU. x86 targets normally perform better on Intel based development machines, especially with Intel Hardware Accelerated Execution Manager (HAXM) installed on recent i5/i7/Xeon based PCs. When the Android SDK is updated AVDs may need to be deleted and recreated due to changes in the emulator core.

For the SD Card the bigger the number the bigger the file created on the host computer system to mimic the SD card. SD images can use existing files allowing the ability to share SD card data amongst different AVD emulations. (On a Windows machine the sdcard.img files will be found in the sub-folders of the avd directory under the .android directory in the logged on user's profile).

AVDs combined with physical devices are a useful combination for testing Apps in a variety of scenarios.

See Also:

http://d.android.com/guide/developing/devices/emulator.html