Certify and Increase Opportunity.
Be
Govt. Certified Android Apps Developer

Setting up AVD and mobile connection

An Android Virtual Device (AVD) is an emulator configuration that lets developer model an actual device by defining hardware and software options to be emulated by the Android Emulator.

The easiest way to create an AVD is to use the graphical AVD Manager, which developer launch from Eclipse by clicking Window > AVD Manager. Developer can also start the AVD Manager from the command line by calling the androidtool with the avdoptions, from the<sdk>/tools/ directory.

Developer can also create AVDs on the command line by passing the androidtool options. An AVD consists of:

• A hardware profile: Defines the hardware features of the virtual device. For example, developer can define whether the device has a camera, whether it uses a physical QWERTY keyboard or a dialing pad, how much memory it has, and so on.
• A mapping to a system image: Developer can define what version of the Android platform will run on the virtual device. Developer can choose a version of the standard Android platform or the system image packaged with an SDK add-on.
• Other options: Developer can specify the emulator skin developer want to use with the AVD, which lets developer control the screen dimensions, appearance, and so on. Developer can also specify the emulated SD card to use with the AVD.
• A dedicated storage area on development machine: the device’s user data (installed applications, settings, and so on) and emulated SD card are stored in this area.

Developer can create as many AVDs as developer need, based on the types of device developer want to model. To thoroughly test application, developer should create an AVD for each general device configuration (for example, different screen sizes and platform versions) with which application is compatible and test application on each one.

Keep these points in mind when developer are selecting a system image target for AVD:

• The API Level of the target is important, because application will not be able to run on a system image whose API Level is less than that required by application, as specified in the minSdkVersion attribute of the application’s manifest file.
• Developer should create at least one AVD that uses a target whose API Level is greater than that required by application, because it allows developer to test the forward-compatibility of application. Forward-compatibility testing ensures that, when users who have downloaded application receive a system update, application will continue to function normally.
• If application declares a uses-library element in its manifest file, the application can only run on a system image in which that external library is present. If developer want to run application on an emulator, create an AVD that includes the required library. Usually, developer must create such an AVD using an Add-on component for the AVD’s platform (for example, the Google APIs Add-on contains the Google Maps library).

Managing AVDs with AVD Manager

Creating an AVD

The AVD Manager is an easy to use user interface to manage AVD (Android Virtual Device) configurations. An AVD is a device configuration for the Android emulator that allows developer to model different configurations of Android-powered devices. When developer start the AVD Manager in Eclipse or run the androidtool on the command line.

From the main screen, developer can create, delete, repair and start AVDs as well as see the details of each AVD.

Creating an AVD

Developer can create as many AVDs as developer would like to test on. It is recommended that developer test applications on all API levels higher than the target API level for application.

To create an AVD:

1. Start the AVD Manager:
   • In Eclipse: select Window > AVD Manager, or click the AVD Manager icon in the Eclipse toolbar.
   • In other IDEs: Navigate to SDK’s tools/directory and execute the androidtool with no arguments.
2. In the Virtual Devices panel, you’ll see a list of existing AVDs. Click New to create a new AVD. The Create New AVD dialog appears.
3. Fill in the details for the AVD.Give it a name, a platform target, an SD card size, and a skin (HVGA is default). Developer can also add specific hardware features of the emulated device by clicking the New… button and selecting the feature. Be sure to define a target for AVD that satisfies application’s Build Target (the AVD platform target must have an API Level equal to or greater than the API Level that application compiles against).
4. Click Create AVD.

AVD is now ready and developer can either close the AVD Manager, create more AVDs, or launch an emulator with the AVD by selecting a device and clicking Start.

Hardware options

If developer are creating a new AVD, developer can specify the following hardware options for the AVD to emulate:

Characteristic	Description	Property
Device ram size	The amount of physical RAM on the device, in megabytes. Default value is “96”.	hw.ramSize
Touch-screen support	Whether there is a touch screen or not on the device. Default value is “yes”.	hw.touchScreen
Trackball support	Whether there is a trackball on the device. Default value is “yes”.	hw.trackBall
Keyboard support	Whether the device has a QWERTY keyboard. Default value is “yes”.	hw.keyboard
DPad support	Whether the device has DPad keys. Default value is “yes”.	hw.dPad
GSM modem support	Whether there is a GSM modem in the device. Default value is “yes”.	hw.gsmModem
Camera support	Whether the device has a camera. Default value is “no”.	hw.camera
Maximum horizontal camera pixels	Default value is “640”.	hw.camera.maxHorizontalPixels
Maximum vertical camera pixels	Default value is “480”.	hw.camera.maxVerticalPixels
GPS support	Whether there is a GPS in the device. Default value is “yes”.	hw.gps
Battery support	Whether the device can run on a battery. Default value is “yes”.	hw.battery
Accelerometer	Whether there is an accelerometer in the device. Default value is “yes”.	hw.accelerometer
Audio recording support	Whether the device can record audio. Default value is “yes”.	hw.audioInput
Audio playback support	Whether the device can play audio. Default value is “yes”.	hw.audioOutput
SD Card support	Whether the device supports insertion/removal of virtual SD Cards. Default value is “yes”.	hw.sdCard
Cache partition support	Whether we use a /cache partition on the device. Default value is “yes”.	disk.cachePartition
Cache partition size	Default value is “66MB”.	disk.cachePartition.size
Abstracted LCD density	Sets the generalized density characteristic used by the AVD’s screen. Default value is “160”.	hw.lcd.density

The androidtool lets developer manage AVDs on the command line.

Listing Targets

To generate a list of system image targets, use this command:

android list targets

The androidtool scans the <sdk>/platforms/and <sdk>/add-ons/directories looking for valid system images and then generates the list of targets. Here’s an example of the command output:

Available Android targets:

id: 1 or "android-3"

     Name: Android 1.5

     Type: Platform

     API level: 3

     Revision: 4

     Skins: QVGA-L, HVGA-L, HVGA (default), HVGA-P, QVGA-P

id: 2 or "android-4"

     Name: Android 1.6

     Type: Platform

     API level: 4

     Revision: 3

     Skins: QVGA, HVGA (default), WVGA800, WVGA854

id: 3 or "android-7"

     Name: Android 2.1-update1

     Type: Platform

     API level: 7

     Revision: 2

     Skins: QVGA, WQVGA400, HVGA (default), WVGA854, WQVGA432, WVGA800

id: 4 or "android-8"

     Name: Android 2.2

     Type: Platform

     API level: 8

     Revision: 2

     Skins: WQVGA400, QVGA, WVGA854, HVGA (default), WVGA800, WQVGA432

id: 5 or "android-9"

     Name: Android 2.3

     Type: Platform

     API level: 9

     Revision: 1

     Skins: HVGA (default), WVGA800, WQVGA432, QVGA, WVGA854, WQVGA400

Creating AVDs

In addition to creating AVDs with the AVD Manager user interface, developer can also create them by passing in command line arguments to the androidtool.

Open a terminal window and change to the <sdk>/tools/directory, if needed.

To create each AVD, developer issue the command android create avd, with options that specify a name for the new AVD and the system image developer want to run on the emulator when the AVD is invoked. Developer can specify other options on the command line also, such as the emulated SD card size, the emulator skin, or a custom location for the user data files.

Here’s the command-line usage for creating an AVD:

android create avd -n <name> -t <targetID> [-<option> <value>] ...

Developer can use any name developer want for the AVD, but since developer are likely to be creating multiple AVDs, developer should choose a name that lets developer recognize the general characteristics offered by the AVD. The target ID is an integer assigned by the androidtool. The target ID is not derived from the system image name, version, or API Level, or other attribute, so developer need to run the android list targetscommand to list the target ID of each system image. Developer should do this before developer run the android create avdcommand.

When you’ve selected the target developer want to use and made a note of its ID, use the android create avdcommand to create the AVD, supplying the target ID as the -targument. Here’s an example that creates an AVD with name “my_android1.5” and target ID “2” (the standard Android 1.5 system image in the list above):

android create avd -n my_android1.5 -t 2

If the target developer selected was a standard Android system image (“Type: platform”), the androidtool next asks developer whether developer want to create a custom hardware profile.

Android 1.5 is a basic Android platform.

Do developer wish to create a custom hardware profile [no]

If developer want to set custom hardware emulation options for the AVD, enter “yes” and set values as needed. If developer want to use the default hardware emulation options for the AVD, just press the return key (the default is “no”). The androidtool creates the AVD with name and system image mapping developer requested, with the options developer specified. If developer are creating an AVD whose target is an SDK add-on, the androidtool does not allow developer to set hardware emulation options. It assumes that the provider of the add-on has set emulation options appropriately for the device that the add-on is modeling, and so prevents developer from resetting the options.

Customize the device resolution or density

When testing application, we recommend that developer test application in several different AVDs, using different screen configurations (different combinations of size and density). In addition, developer should set up the AVDs to run at a physical size that closely matches an actual device.

To set up AVDs for a specific resolution or density, follow these steps:

1. Use the create avdcommand to create a new AVD, specifying the --skinoption with a value that references either a default skin name (such as “WVGA800”) or a custom skin resolution (such as 240×432). Here’s an example:

android create avd -n <name> -t <targetID> --skin WVGA800

2. To specify a custom density for the skin, answer “yes” when asked whether developer want to create a custom hardware profile for the new AVD.
3. Continue through the various profile settings until the tool asks developer to specify “Abstracted LCD density” (hw.lcd.density). Enter an appropriate value, such as “120” for a low-density screen, “160” for a medium density screen, or “240” for a high-density screen.
4. Set any other hardware options and complete the AVD creation.

In the example above (WVGA medium density), the new AVD will emulate a 5.8″ WVGA screen.

As an alternative to adjusting the emulator skin configuration, developer can use the emulator skin’s default density and add the -dpi-deviceoption to the emulator command line when starting the AVD. For example:

emulator -avd WVGA800 -scale 96dpi -dpi-device 160

Default location of AVD files

When developer create an AVD, the androidtool creates a dedicated directory for it on development computer. The directory contains the AVD configuration file, the user data image and SD card image (if available), and any other files associated with the device. Note that the directory does not contain a system image — instead, the AVD configuration file contains a mapping to the system image, which it loads when the AVD is launched.

The androidtool also creates an <AVD_name>.inifile for the AVD at the root of the .android/avd/directory on computer. The file specifies the location of the AVD directory and always remains at the root the .android directory.

By default, the androidtool creates the AVD directory inside ~/.android/avd/(on Linux/Mac), C:\Documents and Settings\<user>\.android\on Windows XP, and C:\Users\<user>\.android\on Windows 7 and Vista. If developer want to use a custom location for the AVD directory, developer can do so by using the -p <path>option when developer create the AVD:

android create avd -n my_android1.5 -t 2 -p path/to/my/avd

If the .android directory is hosted on a network drive, we recommend using the -poption to place the AVD directory in another location. The AVD’s .ini file remains in the .android directory on the network drive, regardless of the location of the AVD directory.

Moving an AVD

If developer want to move or rename an AVD, developer can do so using this command:

android move avd -n <name> [-<option> <value>] ...

Updating an AVD

If, for any reason, the platform/add-on root folder has its name changed (maybe because the user has installed an update of the platform/add-on) then the AVD will not be able to load the system image that it is mapped to. In this case, the android list targetscommand will produce this output:

The following Android Virtual Devices could not be loaded:

Name: foo

Path: <path>/.android/avd/foo.avd

Error: Invalid value in image.sysdir. Run 'android update avd -n foo'

To fix this error, use the android update avdcommand to recompute the path to the system images.

Deleting an AVD

Developer can use the androidtool to delete an AVD. Here is the command usage:

android delete avd -n <name>

When developer issue the command, the androidtool looks for an AVD matching the specified name deletes the AVD’s directory and files.

Using the Android Emulator

The Android SDK includes a virtual mobile device emulator that runs on computer. The emulator lets developer prototype, develop and test Android applications without using a physical device.

The Android emulator mimics all of the hardware and software features of a typical mobile device, except that it cannot place actual phone calls. It provides a variety of navigation and control keys, which developer can “press” using mouse or keyboard to generate events for application. It also provides a screen in which application is displayed, together with any other active Android applications.

To let developer model and test application more easily, the emulator utilizes Android Virtual Device (AVD) configurations. AVDs let developer define certain hardware aspects of emulated phone and allow developer to create many configurations to test many Android platforms and hardware permutations. Once application is running on the emulator, it can use the services of the Android platform to invoke other applications, access the network, play audio and video, store and retrieve data, notify the user, and render graphical transitions and themes.

The emulator also includes a variety of debug capabilities, such as a console from which developer can log kernel output, simulate application interrupts (such as arriving SMS messages or phone calls), and simulate latency effects and dropouts on the data network.

Overview

The Android emulator is an application that provides a virtual mobile device on which developer can run Android applications. It runs a full Android system stack, down to the kernel level, that includes a set of preinstalled applications (such as the dialer) that developer can access from applications. Developer can choose what version of the Android system developer want to run in the emulator by configuring AVDs, and developer can also customize the mobile device skin and key mappings. When launching the emulator and at runtime, developer can use a variety of commands and options to control its behavior.

The Android system images available through the Android SDK Manager contain code for the Android Linux kernel, the native libraries, the Dalvik VM, and the various Android packages (such as the Android framework and preinstalled applications). The emulator provides dynamic binary translation of device machine code to the OS and processor architecture of development machine.

The Android emulator supports many hardware features likely to be found on mobile devices, including:

• An ARMv5 CPU and the corresponding memory-management unit (MMU)
• A 16-bit LCD display
• One or more keyboards (a Qwerty-based keyboard and associated Dpad/Phone buttons)
• A sound chip with output and input capabilities
• Flash memory partitions (emulated through disk image files on the development machine)
• A GSM modem, including a simulated SIM Card
• A camera, using a webcam connected to development computer.
• Sensors like an accelerometer, using data from a USB-connected Android device.

The following sections describe the emulator and its use for development of Android applications in more detail.

Android Virtual Devices and the Emulator

To use the emulator, developer first must create one or more AVD configurations. In each configuration, developer specify an Android platform to run in the emulator and the set of hardware options and emulator skin developer want to use. Then, when developer launch the emulator, developer specify the AVD configuration that developer want to load.

Each AVD functions as an independent device, with its own private storage for user data, SD card, and so on. When developer launch the emulator with an AVD configuration, it automatically loads the user data and SD card data from the AVD directory. By default, the emulator stores the user data, SD card data, and cache in the AVD directory.

To create and manage AVDs developer use the AVD Manager UI or the androidtool that is included in the SDK.

Starting and Stopping the Emulator

During development and testing of application, developer install and run application in the Android emulator. Developer can launch the emulator as a standalone application from a command line, or developer can run it from within Eclipse development environment. In either case, developer specify the AVD configuration to load and any startup options developer want to use.

Developer can run application on a single instance of the emulator or, depending on needs, developer can start multiple emulator instances and run application in more than one emulated device. Developer can use the emulator’s built-in commands to simulate GSM phone calling or SMS between emulator instances, and developer can set up network redirection that allows emulators to send data to one another.

To start an instance of the emulator from the command line, navigate to the tools/folder of the SDK. Enter emulatorcommand like this:

emulator -avd <avd_name> [<options>]

This initializes the emulator, loads an AVD configuration and displays the emulator window. Developer can run multiple instances of the emulator concurrently, each with its own AVD configuration and storage area for user data, SD card, and so on.

If developer are working in Eclipse, the ADT plugin for Eclipse installs application and starts the emulator automatically, when developer run or debug the application. Developer can specify emulator startup options in the Run/Debug dialog, in the Target tab. When the emulator is running, developer can issue console commands.

To stop an emulator instance, just close the emulator’s window.

Installing Applications on the Emulator

If developer don’t have access to Eclipse or the ADT Plugin, developer can install application on the emulator using the adb utility. Before installing the application, developer need to build and package it into an .apk. Once the application is installed, developer can start the emulator from the command line as described previously, using any startup options necessary. When the emulator is running, developer can also connect to the emulator instance’s console to issue commands as needed.

As developer update code, developer periodically package and install it on the emulator. The emulator preserves the application and its state data across restarts, in a user-data disk partition. To ensure that the application runs properly as developer update it, developer may need to delete the emulator’s user-data partition. To do so, start the emulator with the -wipe-data option.

Using Hardware Acceleration

In order to make the Android emulator run faster and be more responsive, developer can configure it to take advantage of hardware acceleration, using a combination of configuration options, specific Android system images and hardware drivers.

Configuring Graphics Acceleration

Caution: As of SDK Tools Revision 17, the graphics acceleration feature for the emulator is experimental; be alert for incompatibilities and errors when using this feature.

Graphics acceleration for the emulator takes advantage of development computer’s graphics hardware, specifically its graphics processing unit (GPU), to make screen drawing faster. To use the graphics acceleration feature, developer must have the following versions of the Android development tools installed:

• Android SDK Tools, Revision 17 or higher
• Android SDK Platform API 15, Revision 3 or higher

Use the Android SDK Manager to install these components:Not all applications are compatible with graphics hardware acceleration. In particular, the Browser application and applications using the WebViewcomponent are not compatible with graphics acceleration.

To configure an AVD to use graphics acceleration:

1. Make sure developer have the required SDK components installed (listed above).
2. Start the AVD Manager and create a new AVD with the Target value of Android 4.0.3 (API Level 15), revision 3 or higher.
3. If developer want to have graphics acceleration enabled by default for this AVD, in the Hardware section, click New, select GPU emulation and set the value to Yes.Note: Developer can also enable graphics acceleration when developer start an emulator using command line options as describe in the next section.
4. Name the AVD instance and select any other configuration options.Caution: Do not select the Snapshot: Enabled option. Snapshots are not supported for emulators with graphics acceleration enabled.
5. Click Create AVD to save the emulator configuration.

If developer set GPU emulation to Yes for AVD, then graphics acceleration is automatically enabled when developer run it. If developer did not enable GPU emulation when developer created the AVD, developer can still enable it at runtime.

To enable graphics acceleration at runtime for an AVD:

• If developer are running the emulator from the command line, just include the -gpu onoption:

emulator -avd <avd_name> -gpu onDeveloper must specify an AVD configuration that uses Android 4.0.3 (API Level 15, revision 3) or higher system image target. Graphics acceleration is not available for earlier system images.

• If developer are running the emulator from Eclipse, run Android application using an AVD with the -gpu onoption enabled:
  1. In Eclipse, click Android project folder and then select Run > Run Configurations…
  2. In the left panel of the Run Configurations dialog, select Android project run configuration or create a new configuration.
  3. Click the Target tab.
  4. Select the AVD developer created in the previous procedure.
  5. In the Additional Emulator Command Line Options field, enter:
     -gpu on
  6. Run Android project using this run configuration.

Configuring Virtual Machine Acceleration

Caution: As of SDK Tools Revision 17, the virtual machine acceleration feature for the emulator is experimental; be alert for incompatibilities and errors when using this feature.

Many modern CPUs provide extensions for running virtual machines (VMs) more efficiently. Taking advantage of these extensions with the Android emulator requires some additional configuration of development system, but can significantly improve the execution speed. Before attempting to use this type of acceleration, developer should first determine if development system’s CPU supports one of the following virtualization extensions technologies:

• Intel Virtualization Technology (VT, VT-x, vmx) extensions
• AMD Virtualization (AMD-V, SVM) extensions (only supported for Linux)

The specifications from the manufacturer of CPU should indicate if it supports virtualization extensions. If CPU does not support one of these virtualization technologies, then developer cannot use virtual machine acceleration.Virtualization extensions are typically enabled through computer’s BIOS and are frequently turned off by default. Check the documentation for system’s motherboard to find out how to enable virtualization extensions.

Once developer have determined that CPU supports virtualization extensions, make sure developer can work within these additional requirements of running an emulator inside an accelerated virtual machine:

• x86 AVD Only – Developer must use an AVD that is uses an x86 system image target. AVDs that use ARM-based system images cannot be accelerated using the emulator configurations described here.
• Not Inside a VM – Developer cannot run a VM-accelerated emulator inside another virtual machine, such as a VirtualBox or VMWare-hosted virtual machine. Developer must run the emulator directly on system hardware.
• Other VM Drivers – If developer are running another virtualization technology on system such as VirtualBox or VMWare, developer may need to unload the driver for that virtual machine hosting software before running an accelerated emulator.
• OpenGL® Graphics – Emulation of OpenGL ES graphics may not perform at the same level as an actual device.

To use virtual machine acceleration with the emulator, developer need the following version of Android development tools. Use the Android SDK Manager to install these components:

• Android SDK Tools, Revision 17 or higher
• Android x86-based system image

If development environment meets all of the requirements for running a VM-accelerated emulator, developer can use the AVD Manager to create an x86-based AVD configuration:

1. In the Android SDK Manager, make sure developer have an x86-based System Image installed for target Android version. If developer do not have an x86 System Image installed, select one in the Android SDK Manager and install it.Tip: System images are listed under each API Level in the SDK Manager. An x86 system image may not be available for all API levels.
2. Start the AVD Manager and create a new AVD with an x86 value for the CPU/ABI field. Developer may need to select a specificTarget value, or select a Target value and then select a specific CPU/ABI option.
3. Name the emulator instance and select any other configuration options.
4. Click Create AVD to save the emulator configuration.

Configuring VM Acceleration on Windows

Virtual machine acceleration for Windows requires the installation of the Intel Hardware Accelerated Execution Manager (Intel HAXM). The software requires an Intel CPU with Virtualization Technology (VT) support and one of the following operating systems:

• Windows 7 (32/64-bit)
• Windows Vista (32/64-bit)
• Windows XP (32-bit only)

To install the virtualization driver:

1. Start the Android SDK Manager, select Extras and then select Intel Hardware Accelerated Execution Manager.
2. After the download completes, execute <sdk>/extras/intel/Hardware_Accelerated_Execution_Manager/IntelHAXM.exe.
3. Follow the on-screen instructions to complete installation.
4. After installation completes, confirm that the virtualization driver is operating correctly by opening a command prompt window and running the following command:

sc query intelhaxm

Developer should see a status message including the following information:

SERVICE_NAME: intelhaxm

       ...

       STATE              : 4  RUNNING

       ...

To run an x86-based emulator with VM acceleration:

• If developer are running the emulator from the command line, just specify an x86-based AVD:

emulator -avd <avd_name>Developer must provide an x86-based AVD configuration name, otherwise VM acceleration will not be enabled.

• If developer are running the emulator from Eclipse, run Android application with an x86-based AVD:
  1. In Eclipse, click Android project folder and then select Run > Run Configurations…
  2. In the left panel of the Run Configurations dialog, select Android project run configuration or create a new configuration.
  3. Click the Target tab.
  4. Select the x86-based AVD developer created previously.
  5. Run Android project using this run configuration.

Developer can adjust the amount of memory available to the Intel HAXM kernel extension by re-running its installer.

Developer can stop using the virtualization driver by uninstalling it. Re-run the installer or use the Control Panel to remove the software.

Configuring VM Acceleration on Mac

Virtual machine acceleration on a Mac requires the installation of the Intel Hardware Accelerated Execution Manager (Intel HAXM) kernel extension to allow the Android emulator to make use of CPU virtualization extensions. The kernel extension is compatible with Mac OS X Snow Leopard (version 10.6.0) and higher.

To install the Intel HAXM kernel extension:

1. Start the Android SDK Manager, select Extras and then select Intel Hardware Accelerated Execution Manager.
2. After the download completes, execute <sdk>/extras/intel/Hardware_Accelerated_Execution_Manager/IntelHAXM.dmg.
3. Double click the IntelHAXM.mpkg icon to begin installation.
4. Follow the on-screen instructions to complete installation.
5. After installation completes, confirm that the new kernel extension is operating correctly by opening a terminal window and running the following command:

kextstat | grep intel

Developer should see a status message containing the following extension name, indicating that the kernel extension is loaded:

com.intel.kext.intelhaxm

To run an x86-based emulator with VM acceleration:

• If developer are running the emulator from the command line, just specify an x86-based AVD:

emulator -avd <avd_name>Developer must provide an x86-based AVD configuration name, otherwise VM acceleration will not be enabled.

• If developer are running the emulator from Eclipse, run Android application with an x86-based AVD:
  1. In Eclipse, click Android project folder and then select Run > Run Configurations…
  2. In the left panel of the Run Configurations dialog, select Android project run configuration or create a new configuration.
  3. Click the Target tab.
  4. Select the x86-based AVD developer created previously.
  5. Run Android project using this run configuration.

Developer can adjust the amount of memory available to the Intel HAXM kernel extension by re-running the installer.

Developer can stop using the virtualization kernel driver by uninstalling it. Before removing it, shut down any running x86 emulators. To unload the virtualization kernel driver, run the following command in a terminal window:

sudo /System/Library/Extensions/intelhaxm.kext/Contents/Resources/uninstall.sh

Configuring VM Acceleration on Linux

Linux-based systems support virtual machine acceleration through the KVM software package. Follow instructions for installing KVM on Linux system, and verify that KVM is enabled. In addition to following the installation instructions, be aware of these configuration requirements:

• Running KVM requires specific user permissions, make sure developer have sufficient permissions according to the KVM installation instructions.
• If developer use another virtualization technology in Linux platform, unload its kernel driver before running the x86 emulator. For example, the VirtualBox driver program is vboxdrv.

To run an x86-based emulator with VM acceleration:

• If developer are running the emulator from the command line, start the emulator with an x86-based AVD and include the KVM options:

emulator -avd <avd_name> -qemu -m 512 -enable-kvmDeveloper must provide an x86-based AVD configuration name, otherwise VM acceleration will not be enabled.

• If developer are running the emulator from Eclipse, run Android application with an x86-based AVD and include the KVM options:
  1. In Eclipse, click Android project folder and then select Run > Run Configurations…
  2. In the left panel of the Run Configurations dialog, select Android project run configuration or create a new configuration.
  3. Click the Target tab.
  4. Select the x86-based AVD developer created previously.
  5. In the Additional Emulator Command Line Options field, enter:

-qemu -m 512 -enable-kvm

• 6. Run Android project using this run configuration.

Important: When using the -qemucommand line option, make sure it is the last parameter in command. All subsequent options are interpreted as qemu-specific parameters.

SD Card Emulation

Developer can create a disk image and then load it to the emulator at startup, to simulate the presence of a user’s SD card in the device. To do this, developer can specify an SD card image when developer create an AVD, or developer can use the mksdcard utility included in the SDK.

The following sections describe how to create an SD card disk image, how to copy files to it, and how to load it in the emulator at startup.

Note that developer can only load a disk image at emulator startup. Similarly, developer can not remove a simulated SD card from a running emulator. However, developer can browse, send files to, and copy/remove files from a simulated SD card either with adb or the emulator.

The emulator supports emulated SDHC cards, so developer can create an SD card image of any size up to 128 gigabytes.

Creating an SD card image

There are several ways of creating an SD card image. The easiest way is to use the AVD Manager to create a new SD card by specifying a size when developer create an AVD. Developer can also use the androidcommand line tool when creating an AVD. Just add the -coption to command:

android create avd -n <avd_name> -t <targetID> -c <size>[K|M]

The -coption can also be used to to specify a path to an SD card image for the new AVD.

Developer can also use the mksdcard tool, included in the SDK, to create a FAT32 disk image that developer can load in the emulator at startup. Developer can access mksdcard in the tools/ directory of the SDK and create a disk image like this:

mksdcard <size> <file>

For example:

mksdcard 1024M sdcard1.iso

Copying files to an SD card image

Once developer have created the disk image, developer can copy files to it prior to loading it in the emulator. To copy files, developer can mount the image as a loop device and then copy the files to it, or developer can use a utility such as mtoolsto copy the files directly to the image. The mtoolspackage is available for Linux, Mac, and Windows.

Alternatively, developer can use the adb pushcommand to move files onto an SD card image while it is loaded in an emulator.

Loading an SD card image

By default, the emulator loads the SD card image that is stored with the active AVD (see the -avdstartup option).

Alternatively, developer can start the emulator with the -sdcardflag and specify the name and path of image (relative to the current working directory):

emulator -sdcard <filepath>

Working with Emulator Disk Images

The emulator uses mountable disk images stored on development machine to simulate flash (or similar) partitions on an actual device. For example, it uses a disk image containing an emulator-specific kernel, the Android system, a ramdisk image, and writeable images for user data and simulated SD card.

To run properly, the emulator requires access to a specific set of disk image files. By default, the Emulator always looks for the disk images in the private storage area of the AVD in use. If no images exist there when the Emulator is launched, it creates the images in the AVD directory based on default versions stored in the SDK.The default storage location for AVDs is in ~/.android/avdon OS X and Linux, C:\Documents and Settings\<user>\.android\on Windows XP, and C:\Users\<user>\.android\on Windows Vista.

To let developer use alternate or custom versions of the image files, the emulator provides startup options that override the default locations and filenames of the image files. When developer use one of these options, the emulator searches for the image file under the image name or location that developer specify; if it can not locate the image, it reverts to using the default names and location.

The emulator uses three types of image files: default image files, runtime image files, and temporary image files. The sections below describe how to override the location/name of each type of file.

Default image files

When the emulator launches, but does not find an existing user data image in the active AVD’s storage area, it creates a new one from a default version included in the SDK. The default user data image is read-only. The image files are read-only.

The emulator provides the -system <dir>startup option to let developer override the location where the emulator looks for the default user data image.

The emulator also provides a startup option that lets developer override the name of the default user data image, as described in the following table. When developer use the option, the emulator looks in the default directory, or in a custom location (if developer specified -system <dir>).

Name	Description	Comments
userdata.img	The initial user-data disk image	Override using -initdata <file>. Also see -data <file>, below.

Runtime images: user data and SD card

At runtime, the emulator reads and writes data to two disk images: a user-data image and (optionally) an SD card image. These images emulate the user-data partition and removable storage media on actual device.

The emulator provides a default user-data disk image. At startup, the emulator creates the default image as a copy of the system user-data image (user-data.img), described above. The emulator stores the new image with the files of the active AVD.

The emulator provides startup options to let developer override the actual names and storage locations of the runtime images to load, as described in the following table. When developer use one of these options, the emulator looks for the specified file(s) in the current working directory, in the AVD directory, or in a custom location (if developer specified a path with the filename).

Name	Description	Comments
userdata-qemu.img	An image to which the emulator writes runtime user-data for a unique user.	Override using -data <filepath>, where <filepath>is the path the image, relative to the current working directory. If developer supply a filename only, the emulator looks for the file in the current working directory. If the file at <filepath>does not exist, the emulator creates an image from the default userdata.img, stores it under the name developer specified, and persists user data to it at shutdown.
sdcard.img	An image representing an SD card inserted into the emulated device.	Override using -sdcard <filepath>, where <filepath>is the path the image, relative to the current working directory. If developer supply a filename only, the emulator looks for the file in the current working directory.

User-Data Image

Each emulator instance uses a writeable user-data image to store user- and session-specific data. For example, it uses the image to store a unique user’s installed application data, settings, databases, and files.

At startup, the emulator attempts to load a user-data image stored during a previous session. It looks for the file in the current working directory, in the AVD directory described in a previous section and at the custom location/name that developer specified at startup.

• If it finds a user-data image, it mounts the image and makes it available to the system for reading and writing of user data.

If it does not find one, it creates an image by copying the system user-data image (userdata.img), described above. At device power-off, the system persists the user data to the image, so that it will be available in the next session. Note that the emulator stores the new disk image at the location/name that developer specify in -datastartup option.Because of the AVD configurations used in the emulator, each emulator instance gets its own dedicated storage. There is no longer a need to use the -doption to specify an instance-specific storage area.

SD Card

Optionally, developer can create a writeable disk image that the emulator can use to simulate removeable storage in an actual device.

Developer can also use the android tool to automatically create an SD Card image for you, when creating an AVD.

Temporary Images

The emulator creates two writeable images at startup that it deletes at device power-off. The images are:

• A writable copy of the Android system image
• The /cachepartition image

The emulator does not permit renaming the temporary system image or persisting it at device power-off.

The /cachepartition image is initially empty, and is used by the browser to cache downloaded web pages and images. The emulator provides an -cache <file>, which specifies the name of the file in which to persist the /cacheimage at device power-off. If <file>does not exist, the emulator creates it as an empty file.

Developer can also disable the use of the cache partition by specifying the -nocacheoption at startup.

Emulator Networking

The emulator provides versatile networking capabilities that developer can use to set up complex modeling and testing environments for application. The sections below introduce the emulator’s network architecture and capabilities.

Network Address Space

Each instance of the emulator runs behind a virtual router/firewall service that isolates it from development machine’s network interfaces and settings and from the internet. An emulated device can not see development machine or other emulator instances on the network. Instead, it sees only that it is connected through Ethernet to a router/firewall.

The virtual router for each instance manages the 10.0.2/24 network address space — all addresses managed by the router are in the form of 10.0.2.<xx>, where <xx> is a number. Addresses within this space are pre-allocated by the emulator/router as follows:

Network Address	Description
10.0.2.1	Router/gateway address
10.0.2.2	Special alias to host loopback interface (i.e., 127.0.0.1 on development machine)
10.0.2.3	First DNS server
10.0.2.4 / 10.0.2.5 / 10.0.2.6	Optional second, third and fourth DNS server (if any)
10.0.2.15	The emulated device’s own network/ethernet interface
127.0.0.1	The emulated device’s own loopback interface

Note that the same address assignments are used by all running emulator instances. That means that if developer have two instances running concurrently on machine, each will have its own router and, behind that, each will have an IP address of 10.0.2.15. The instances are isolated by a router and can not see each other on the same network.

Also note that the address 127.0.0.1 on development machine corresponds to the emulator’s own loopback interface. If developer want to access services running on development machine’s loopback interface (a.k.a. 127.0.0.1 on machine), developer should use the special address 10.0.2.2 instead.

Finally, note that each emulated device’s pre-allocated addresses are specific to the Android emulator and will probably be very different on real devices (which are also very likely to be NAT-ed, i.e., behind a router/firewall)

Local Networking Limitations

Android applications running in an emulator can connect to the network available on workstation. However, they connect through the emulator, not directly to hardware, and the emulator acts like a normal application on workstation. This means that the emulator, and thus Android applications, are subject to some limitations:

• Communication with the emulated device may be blocked by a firewall program running on machine.
• Communication with the emulated device may be blocked by another (physical) firewall/router to which machine is connected.

The emulator’s virtual router should be able to handle all outbound TCP and UDP connections/messages on behalf of the emulated device, provided development machine’s network environment allows it to do so. There are no built-in limitations on port numbers or ranges except the one imposed by host operating system and network.

Depending on the environment, the emulator may not be able to support other protocols (such as ICMP, used for “ping”) might not be supported. Currently, the emulator does not support IGMP or multicast.

Using Network Redirection

To communicate with an emulator instance behind its virtual router, developer need to set up network redirection on the virtual router. Clients can then connect to a specified guest port on the router, while the router directs traffic to/from that port to the emulated device’s host port.

To set up the network redirection, developer create a mapping of host and guest ports/addresses on the the emulator instance. There are two ways to set up network redirection: using emulator console commands and using the ADB tool, as described below.

Setting up Redirection through the Emulator Console

Each emulator instance provides a control console the developer can connect to, to issue commands that are specific to that instance. Developer can use the redirconsole command to set up redirection as needed for an emulator instance.

First, determine the console port number for the target emulator instance. For example, the console port number for the first emulator instance launched is 5554. Next, connect to the console of the target emulator instance, specifying its console port number, as follows:

telnet localhost 5554

Once connected, use the redircommand to work with redirection. To add a redirection, use:

add <protocol>:<host-port>:<guest-port>

where <protocol>is either tcpor udp, and <host-port>and <guest-port>sets the mapping between own machine and the emulated system, respectively.

For example, the following command sets up a redirection that handles all incoming TCP connections to host (development) machine on 127.0.0.1:5000 and will pass them through to the emulated system’s 10.0.2.15:6000.:

redir add tcp:5000:6000

To delete a redirection, developer can use the redir delcommand. To list all redirection for a specific instance, developer can use redir list.

Note that port numbers are restricted by local environment. this typically means that developer cannot use host port numbers under 1024 without special administrator privileges. Also, developer won’t be able to set up a redirection for a host port that is already in use by another process on machine. In that case, redirgenerates an error message to that effect.

Setting Up Redirection through ADB

The Android Debug Bridge (ADB) tool provides port forwarding, an alternate way for developer to set up network redirection.

Note that ADB does not currently offer any way to remove a redirection, except by killing the ADB server.

Configuring the Emulator’s DNS Settings

At startup, the emulator reads the list of DNS servers that system is currently using. It then stores the IP addresses of up to four servers on this list and sets up aliases to them on the emulated addresses 10.0.2.3, 10.0.2.4, 10.0.2.5 and 10.0.2.6 as needed.

On Linux and OS X, the emulator obtains the DNS server addresses by parsing the file /etc/resolv.conf. On Windows, the emulator obtains the addresses by calling the GetNetworkParams()API. Note that this usually means that the emulator ignores the content of “hosts” file (/etc/hostson Linux/OS X, %WINDOWS%/system32/HOSTSon Windows).

When starting the emulator at the command line, developer can also use the -dns-server <serverList>option to manually specify the addresses of DNS servers to use, where <serverList> is a comma-separated list of server names or IP addresses. Developer might find this option useful if developer encounter DNS resolution problems in the emulated network (for example, an “Unknown Host error” message that appears when using the web browser).

Using the Emulator with a Proxy

If emulator must access the Internet through a proxy server, developer can use the -http-proxy <proxy>option when starting the emulator, to set up the appropriate redirection. In this case, developer specify proxy information in <proxy>in one of these formats:

http://<machineName>:<port>

or

http://<username>:<password>@<machineName>:<port>

The -http-proxyoption forces the emulator to use the specified HTTP/HTTPS proxy for all outgoing TCP connections. Redirection for UDP is not currently supported.

Alternatively, developer can define the environment variable http_proxyto the value developer want to use for <proxy>. In this case, developer do not need to specify a value for <proxy>in the -http-proxycommand — the emulator checks the value of the http_proxyenvironment variable at startup and uses its value automatically, if defined.

Developer can use the -verbose-proxyoption to diagnose proxy connection problems.

Interconnecting Emulator Instances

To allow one emulator instance to communicate with another, developer must set up the necessary network redirection as illustrated below.

Assume that environment is

• A is developer development machine
• B is first emulator instance, running on A
• C is second emulator instance, also running on A

and developer want to run a server on B, to which C will connect, here is how developer could set it up:

1. Set up the server on B, listening to 10.0.2.15:<serverPort>
2. On B’s console, set up a redirection from A:localhost:<localPort>to B:10.0.2.15:<serverPort>
3. On C, have the client connect to 10.0.2.2:<localPort>

For example, if developer wanted to run an HTTP server, developer can select <serverPort>as 80 and <localPort>as 8080:

• B listens on 10.0.2.15:80
• On B’s console, issue redir add tcp:8080:80
• C connects to 10.0.2.2:8080

Sending a Voice Call or SMS to Another Emulator Instance

The emulator automatically forwards simulated voice calls and SMS messages from one instance to another. To send a voice call or SMS, use the dialer application or SMS application, respectively, from one of the emulators.

To initiate a simulated voice call to another emulator instance:

1. Launch the dialer application on the originating emulator instance.
2. As the number to dial, enter the console port number of the instance you’d like to call. Developer can determine the console port number of the target instance by checking its window title, where the console port number is reported as “Android Emulator (<port>).
3. Press “Dial”. A new inbound call appears in the target emulator instance.

To send an SMS message to another emulator instance, launch the SMS application (if available). Specify the console port number of the target emulator instance as as the SMS address, enter the message text, and send the message. The message is delivered to the target emulator instance.

Developer can also connect to an emulator instance’s console to simulate an incoming voice call or SMS.

Using the Emulator Console

Each running emulator instance provides a console that lets developer query and control the emulated device environment. For example, developer can use the console to manage port redirection, network characteristics, and telephony events while application is running on the emulator. To access the console and enter commands, use telnet to connect to the console’s port number.

To connect to the console of any running emulator instance at any time, use this command:

telnet localhost <console-port>

An emulator instance occupies a pair of adjacent ports: a console port and an adbport. The port numbers differ by 1, with theadbport having the higher port number. The console of the first emulator instance running on a given machine uses console port 5554 and adbport 5555. Subsequent instances use port numbers increasing by two — for example, 5556/5557, 5558/5559, and so on. Up to 16 concurrent emulator instances can run a console facility.

To connect to the emulator console, developer must specify a valid console port. If multiple emulator instances are running, developer need to determine the console port of the emulator instance developer want to connect to. Developer can find the instance’s console port listed in the title of the instance window. For example, here’s the window title for an instance whose console port is 5554:

Android Emulator (5554)

Alternatively, developer can use the adb devicescommand, which prints a list of running emulator instances and their console port numbers. The emulator listens for connections on ports 5554-5587 and accepts connections only from localhost.

Once developer are connected to the console, developer can then enter help [command]to see a list of console commands and learn about specific commands.

To exit the console session, use quitor exit.

The following sections below describe the major functional areas of the console.

Port Redirection

Developer can use the console to add and remove port redirection while the emulator is running. After developer connect to the console, manage port redirection by entering the following command:

redir <list|add|del>

The redircommand supports the subcommands listed in the table below.

Subcommand	Description	Comments
list	List the current port redirection.
add <protocol>:<host-port>:<guest-port>	Add a new port redirection.	<protocol> must be either “tcp” or “udp” <host-port> is the port number to open on the host <guest-port> is the port number to route data to on the emulator/device
del <protocol>:<host-port>	Delete a port redirection.	The meanings of <protocol> and <host-port> are listed in the previous row.

Geo Location Provider Emulation

Developer can use the console to set the geographic location reported to the applications running inside an emulator. Use thegeocommand to send a simple GPS fix to the emulator, with or without NMEA 1083 formatting:

geo <fix|nmea>

The geocommand supports the subcommands listed in the table below.

Subcommand	Description	Comments
fix <longitude> <latitude> [<altitude>]	Send a simple GPS fix to the emulator instance.	Specify longitude and latitude in decimal degrees. Specify altitude in meters.
nmea <sentence>	Send an NMEA 0183 sentence to the emulated device, as if it were sent from an emulated GPS modem.	<sentence> must begin with ‘$GP’. Only ‘$GPGGA’ and ‘$GPRCM’ sentences are currently supported.

Developer can issue the geocommand as soon as an emulator instance is running. The emulator sets the location developer enter by creating a mock location provider. This provider responds to location listeners set by applications, and also supplies the location to the LocationManager. Any application can query the location manager to obtain the current GPS fix for the emulated device by calling:

LocationManager.getLastKnownLocation("gps")

Hardware Events Emulation

The eventconsole commands sends hardware events to the emulator. The syntax for this command is as follows:

event <send|types|codes|text>

The eventcommand supports the subcommands listed in the table below.

Subcommand	Description	Comments
send <type>:<code>:<value> [...]	Send one or more events to the Android kernel.	Developer can use text names or integers for <type>and<value>.
types	List all <type>string aliases supported by the eventsubcommands.
codes <type>	List all <codes>string aliases supported by the eventsubcommands for the specified<type>.
event text <message>	Simulate keypresses to send the specified string of characters as a message,	The message must be a UTF-8 string. Unicode posts will be reverse-mapped according to the current device keyboard. Unsupported characters will be discarded silently.

Device Power Characteristics

The powercommand controls the power state reported by the emulator to applications. The syntax for this command is as follows:

power <display|ac|status|present|health|capacity>

The eventcommand supports the subcommands listed in the table below.

Subcommand	Description	Comments
display	Display battery and charger state.
ac <on|off>	Set AC charging state to on or off.
status <unknown|charging|discharging|not-charging|full>	Change battery status as specified.
present <true|false>	Set battery presence state.
health <unknown|good|overheat|dead|overvoltage|failure>	Set battery health state.
power health <percent>	Set remaining battery capacity state (0-100).

Network Status

Developer can use the console to check the network status and current delay and speed characteristics. To do so, connect to the console and use the netstatuscommand. Here’s an example of the command and its output.

network status

Network Delay Emulation

The emulator lets developer simulate various network latency levels, so that developer can test application in an environment more typical of the actual conditions in which it will run. Developer can set a latency level or range at emulator startup or developer can use the console to change the latency, while the application is running in the emulator.

To set latency at emulator startup, use the -netdelayemulator option with a supported <delay>value, as listed in the table below. Here are some examples:

emulator -netdelay gprs

emulator -netdelay 40 100

To make changes to network delay while the emulator is running, connect to the console and use the netdelaycommand with a supported <delay>value from the table below.

network delay gprs

The format of network <delay> is one of the following (numbers are milliseconds):

Value	Description	Comments
gprs	GPRS	(min 150, max 550)
edge	EDGE/EGPRS	(min 80, max 400)
umts	UMTS/3G	(min 35, max 200)
none	No latency	(min 0, max 0)
<num>	Emulate an exact latency (milliseconds).
<min>:<max>	Emulate an specified latency range (min, max milliseconds).

Network Speed Emulation

The emulator also lets developer simulate various network transfer rates. Developer can set a transfer rate or range at emulator startup or developer can use the console to change the rate, while the application is running in the emulator.

To set the network speed at emulator startup, use the -netspeedemulator option with a supported <speed>value, as listed in the table below. Here are some examples:

emulator -netspeed gsm

emulator -netspeed 14.4 80

To make changes to network speed while the emulator is running, connect to the console and use the netspeedcommand with a supported <speed>value from the table below.

network speed 14.4 80

The format of network <speed>is one of the following (numbers are kilobits/sec):

Value	Description	Comments
gsm	GSM/CSD	(Up: 14.4, down: 14.4)
hscsd	HSCSD	(Up: 14.4, down: 43.2)
gprs	GPRS	(Up: 40.0, down: 80.0)
edge	EDGE/EGPRS	(Up: 118.4, down: 236.8)
umts	UMTS/3G	(Up: 128.0, down: 1920.0)
hsdpa	HSDPA	(Up: 348.0, down: 14400.0)
full	no limit	(Up: 0.0, down: 0.0)
<num>	Set an exact rate used for both upload and download.
<up>:<down>	Set exact rates for upload and download separately.

Telephony Emulation

The Android emulator includes its own GSM emulated modem that lets developer simulate telephony functions in the emulator. For example, developer can simulate inbound phone calls, establish data connections and terminate them. The Android system handles simulated calls exactly as it would actual calls. The emulator does not support call audio.

Developer can use the gsmcommand to access the emulator’s telephony functions after connecting to the console. The syntax for this command is as follows:

gsm <call|accept|busy|cancel|data|hold|list|voice|status>

The gsmcommand supports the subcommands listed in the table below.

Subcommand	Description	Comments
call <phonenumber>	Simulate an inbound phone call from <phonenumber>.
accept <phonenumber>	Accept an inbound call from <phonenumber> and change the call’s state “active”.	Developer can change a call’s state to “active” only if its current state is “waiting” or “held”.
busy <phonenumber>	Close an outbound call to <phonenumber> and change the call’s state to “busy”.	Developer can change a call’s state to “busy” only if its current state is “waiting”.
cancel <phonenumber>	Terminate an inbound or outbound phone call to/from <phonenumber>.
data <state>	Change the state of the GPRS data connection to <state>.	Supported <state> values are: unregistered — No network available home — On local network, non-roaming roaming — On roaming network searching — Searching networks denied — Emergency calls only off — Same as ‘unregistered’ on — same as ‘home’
hold	Change the state of a call to “held”.	Developer can change a call’s state to “held” only if its current state is “active” or “waiting”.
list	List all inbound and outbound calls and their states.
voice <state>	Change the state of the GPRS voice connection to <state>.	Supported <state> values are: unregistered — No network available home — On local network, non-roaming roaming — On roaming network searching — Searching networks denied — Emergency calls only off — Same as ‘unregistered’ on — Same as ‘home’
status	Report the current GSM voice/data state.	Values are those described for the voiceand datacommands.

SMS Emulation

The Android emulator console lets developer generate an SMS message and direct it to an emulator instance. Once developer connect to an emulator instance, developer can generate an emulated incoming SMS using the following command:

sms send <senderPhoneNumber> <textmessage>

where <senderPhoneNumber>contains an arbitrary numeric string.

The console forwards the SMS message to the Android framework, which passes it through to an application that handles that message type.

VM State

Developer can use the vmcommand to control the VM on an emulator instance. The syntax for this command is as follows:

vm <start|stop|status>

The vmcommand supports the subcommands listed in the table below.

Subcommand	Description	Comments
start	Start the VM on the instance.
stop	Stop the VM on the instance.
start	Display the current status of the VM (running or stopped).

Emulator Window

Developer can use the windowcommand to manage the emulator window. The syntax for this command is as follows:

window <scale>

The vmcommand supports the subcommands listed in the table below.

Subcommand	Description	Comments
scale <scale>	Scale the emulator window.	A number between 0.1 and 3 that sets the scaling factor. Developer can also specify scale as a DPI value if developer add the suffix “dpi” to the scale value. A value of “auto” tells the emulator to select the best window size.

Terminating an Emulator Instance

Developer can terminate an emulator instance through the console, using the killcommand.

Emulator Limitations

The functional limitations of the emulator include:

• No support for placing or receiving actual phone calls. Developer can simulate phone calls (placed and received) through the emulator console, however.
• No support for USB connections
• No support for device-attached headphones
• No support for determining network connected state
• No support for determining battery charge level and AC charging state
• No support for determining SD card insert/eject
• No support for Bluetooth

Troubleshooting Emulator Problems

The adbutility sees the emulator as an actual physical device. For this reason, developer might have to use the -dflag with some commonadbcommands, such as install. The -dflag lets developer specify which of several connected devices to use as the target of a command. If developer don’t specify -d, the emulator targets the first device in its list.

For emulators running on Mac OS X, if developer see an error Warning: No DNS servers foundwhen starting the emulator, check to see whether developer have an /etc/resolv.conffile. If not, please run the following line in a command window:

ln -s /private/var/run/resolv.conf /etc/resolv.conf

Setting up a Device for Development

With an Android-powered device, developer can develop and debug Android applications just as developer would on the emulator. Before developer can start, there are just a few things to do:

1. Declare application as “debuggable” in Android Manifest.When using Eclipse, developer can skip this step, because running app directly from the Eclipse IDE automatically enables debugging.In the AndroidManifest.xmlfile, add android:debuggable="true"to the <application>element.Note: If developer manually enable debugging in the manifest file, be sure to disable it before developer build for release (published application should usually not be debuggable).
2. Turn on “USB Debugging” on device.On the device, go to Settings > Applications > Development and enable USB debugging (on an Android 4.0 device, the setting is located in Settings > Developer options).
3. Set up system to detect device.
   • If you’re developing on Windows, developer need to install a USB driver for adb.
   • If you’re developing on Mac OS X, it just works. Skip this step.
   • If you’re developing on Ubuntu Linux, developer need to add a udevrules file that contains a USB configuration for each type of device developer want to use for development. In the rules file, each device manufacturer is identified by a unique vendor ID, as specified by the ATTR{idVendor}property. To set up device detection on Ubuntu Linux:
     1. Log in as root and create this file: /etc/udev/rules.d/51-android.rules.Use this format to add each vendor to the file:
        SUBSYSTEM=="usb", ATTR{idVendor}=="0bb4", MODE="0666", GROUP="plugdev"In this example, the vendor ID is for HTC. The MODEassignment specifies read/write permissions, and GROUPdefines which Unix group owns the device node.Note: The rule syntax may vary slightly depending on environment. Consult the udevdocumentation for system as needed.
     2. Now execute:
        chmod a+r /etc/udev/rules.d/51-android.rules

When plugged in over USB, can verify that device is connected by executing adb devicesfrom SDK platform-tools/directory. If connected, you’ll see the device name listed as a “device.”

If using Eclipse, run or debug application as usual. Developer will be presented with a Device Chooser dialog that lists the available emulator(s) and connected device(s). Select the device upon which developer want to install and run the application.

If using the Android Debug Bridge (adb), developer can issue commands with the -dflag to target connected device.

–Google

Suggested video