A fundamental part of creating Android applications is running and testing them. Testing your code and app implementation on real devices is important, but emulating other scenarios and having the convenience, protection, and cost savings of not owning every Android device ever created keeps development realistic. Learn how to create Android Virtual Devices (AVDs) in this tutorial.
Getting Started
This tutorial is for the Java developer just getting started learning Android, who is familiar with Eclipse, and has installed the Android SDK and Android Developer Plugin for Eclipse, and is ready to run the emulator. If you have not prepared as such, see the previous tutorials in this series.
Part 1: Creating a Simple AVD
We’ll get started by creating a simple, stock AVD that represents a fairly generic Android device. This AVD will be your “goto” configuration when you launch your app for testing and debugging.
Step 1: Launch the AVD Manager
The easiest way to launch the Android Virtual Device Manager is to click on the Android toolbar button that looks like a tiny phone from within Eclipse. This will launch the tool, as shown, and display any AVD configurations you have already created.
Step 2: Start the New AVD Wizard
Now click the New… button from within the Android Virtual Device Manager. You’ll be presented with a dialog to fill in some configuration details about your AVD:
Step 3: Describe Your AVD
Not much information is needed to create a basic AVD. Give the AVD a descriptive name (such as “AVD-API16″) and choose the target platform such as “Android 4.1 – API Level 16″. The CPU/ABI is automatically chosen, but you must have at least one System Image downloaded for any to appear. Choose an SD Card size. For basic testing AVDs, we usually use 64MB for the SD Card size, but keep in mind that this space will be blocked off on your development machine, so if you create a lot of AVDs, they will take up a lot of space. Leave the rest of the options as the defaults for now.
Step 4: Finishing Up
Press the Create AVD button. The AVD creation process can take a few moments. Once complete, you’ll be back at the list of AVDs, with your newly created one now available.
Part 2: Starting the Emulator With an AVD
AVDs are basically definitions that tell how to configure the Android emulator. Launching an AVD and starting the emulator are synonymous. There are several ways to launch an AVD. Within Eclipse, some options include automatically launching an emulator with a specific AVD when you start debugging, manually launching when you start debugging, and simply launching through the Android Virtual Device Manager. We recommend launching AVDs ahead of time through the Android Virtual Device Manager before you dive into compiling and debugging your actual code. This way, your emulator and AVD are up and running before debugging starts. This is the method we’ll use now.
Note: If you’re coming here with Android experience, this tutorial technically comes before debugging so we’ll not get into that just yet.Step 1: Open the AVD Manager
If you’re not already in the AVD Manager, launch it now. Typically, you’ll do this with the button that looks like a little phone icon ( as we did in Part 1, Step 1).
Step 2: Open the Launch Options Dialog
Now select the AVD you wish to launch and press the Start… button. You’ll get a dialog like this one.
Starting from the bottom (and least complex), you’ll see two snapshot options. Save to snapshot means when you exit the emulator, the state of the emulator will be saved. This takes some time to set up, depending on the amount of RAM given to the emulator. Launching from snapshot means the emulator will use a previously saved snapshot to restore. When one exists, launch times are very fast compared to a cold launch without the snapshot feature.
Next up is an option to wipe user data. This basically resets the AVD to a fresh state, much like a factory reset. There are many testing scenarios where you’ll want a nice clear slate, although once you are further along in developing and testing your application, you’re more likely to want user data to stick around while you perform deeper and broader test scenarios.
Next, there is the option to scale the emulator display to real physical screen size. This means, if the numbers are all chosen correctly, that the emulator screen on your monitor will appear at the same size as the screen on a device. The density of the two devices (your computer monitor and the device screen) are probably different, so a different number of pixels will be used on your computer monitor (usually less, unless you have a very high density monitor or are simulating a low density device). Pressing the little “?” button will display another dialog that gives some sample screen resolutions and monitor sizes and will fill in some details. It covers a wide variety of common cases, but certainly not all.
The following figure shows a sample configuration. We used settings to draw the WVGA800 screen on a common 24″ 1080p monitor at 4″ diagonal. Our desktops have multiple monitors (of different sizes), so we’ll have to keep this in mind when moving the emulator between screens.
The Scale value implies that it’s going to use 40% fewer pixels both vertically and horizontally. This isn’t the place to look for pixel level-detail, rather it’s the place to look for useful sizing, such as whether or not a button is big enough for a finger to tap it.
Leaving this option off draws the emulator screen pixel for pixel on your monitor. This is how we usually use it unless we are focusing in UI/UX design.
Step 3: Launch the Emulator
Now press the Launch button. The emulator will start. In it’s current form, the emulator will take a while to launch the first time. Subsequent launches will be faster. Some tools and extras can be used on some machines to dramatically speed up the emulator. Here’s an emulator screen scaled to 4″ on a 24″ 1920×1080 monitor.
Part 3: Creating AVDs That Mimic True Devices
The AVDs have many options to control screen size, memory size, input types, and several other characteristics found on Android hardware devices. We’ve covered how to configure AVDs for various types of devices in Common Android Virtual Device Configurations and Android Tablet Virtual Device Configurations. This section will not repeat that information. Instead, we’ll talk about another way to create AVDs that closely mimic popular Android devices: by using manufacturer-supplied add-ons.
Step 1: Pick a Device
You’ve learned how to download add-ons using the Android SDK Manager. Pick a device and download the add-on. We’ve picked the ICS_R2 one from Motorola for this demonstration, which is a bit of a hard to figure name that really just provides an add-on for the Atrix HD handset.
Step 2: Create a New AVD
Open the Android Virtual Device Manager. Begin to create a new AVD as usual. In the Target section, select”ICS_R2 (Motorola Mobility, LLC.) – API Level 15.” This will fill in a variety of AVD options for you, including many hardware flags and a skin. Click Create AVD.
One setting this “preset” doesn’t do is set the screen size. If you know the screen size you want to emulate, you can fill in the physical size of your device and set the DPI of your development machine’s monitor, as we did earlier.
Step 3: Launch Your New AVD
Launch the AVD using one of th
e several methods described earlier. You’ll immediately see some differences:
But don’t let all these differences let you think you’re running the real device. You aren’t. This is still the emulator and can’t replace testing on the real device. When it comes to stock apps and third party APIs, though, you’ll be able to test much more accurately than with the generic Android emulator configurations. Many of the add-ons come with new system images that contain many of the manufacturers updates that are not found in the base versions. There is a catch, though. Most manufacturer’s system images don’t come with the Google apps, whereas the real devices do.
Conclusion
You’ve learned how to create AVDs for a variety of Android device types. You’ve learned how to launch the emulator using these AVDs. If you’re like us, it won’t be long before you’ll be cleaning up your AVD list because you’ve created too many you don’t use; for organizational purposes, we highly recommend you use descriptive names for your AVDs so you can tell what led you to create them in the first place!.
You’re well on your way to Android development. What kinds of apps are you looking forward to creating? Let us know in the comments!
About the Authors
Mobile developers Lauren Darcey and Shane Conder have coauthored several books on Android development: an in-depth programming book entitled Android Wireless Application Development (now in it’s third edition as a two-volume set), Sams Teach Yourself Android Application Development in 24 Hours, and Learning Android Application Programming for the Kindle Fire: A Hands-On Guide to Building Your First Android Application. When not writing, they spend their time developing mobile software at their company and providing consulting services. They can be reached at via email to androidwirelessdev+mt@gmail.com, via their blog at androidbook.blogspot.com, and on Twitter @androidwireless.
Need More Help Writing Android Apps? Check out our Latest Books and Resources!
