The Android emulator is a QEMU-based application that provides a virtual ARM mobile device on which you can run your 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 you can access from your applications. You can choose what version of the Android system you want to run in the emulator by configuring AVDs, and you can also customize the mobile device skin and key mappings. When launching the emulator and at runtime, you can use a variety of commands and options to control the its behaviors.
The Android system image distributed in the SDK contains ARM machine code for the Android Linux kernel, the native libraries, the Dalvik VM, and the various Android package files (such as for for the Android framework and preinstalled applications). The emulator's QEMU layers provide dynamic binary translation of the ARM machine code to the OS and processor architecture of your development machine.
Adding custom capabilities to the underlying QEMU services, 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
The sections below provide more information about the emulator and how to use it for developing Android applications.
Controlling the Emulator
You can use emulator startup options and console commands to control the behaviors and characteristics of the emulated environment itself.
When the emulator is running, you can interact with the emulated mobile device just as you would an actual mobile device, except that you use your mouse pointer to "touch" the touchscreen and your keyboard keys to "press" the simulated device keys.
The table below summarizes the mappings between the emulator keys and and the keys of your keyboard.
| Emulated Device Key | Keyboard Key |
| Home | HOME |
| Menu (left softkey) | F2 or Page-up button |
| Star (right softkey) | Shift-F2 or Page Down |
| Back | ESC |
| Call/dial button | F3 |
| Hangup/end call button | F4 |
| Search | F5 |
| Power button | F7 |
| Audio volume up button | KEYPAD_PLUS, Ctrl-5 |
| Audio volume down button | KEYPAD_MINUS, Ctrl-F6 |
| Camera button | Ctrl-KEYPAD_5, Ctrl-F3 |
| Switch to previous layout orientation (for example, portrait, landscape) | KEYPAD_7, Ctrl-F11 |
| Switch to next layout orientation (for example, portrait, landscape) | KEYPAD_9, Ctrl-F12 |
| Toggle cell networking on/off | F8 |
| Toggle code profiling | F9 (only with -trace startup option) |
| Toggle fullscreen mode | Alt-Enter |
| Toggle trackball mode | F6 |
| Enter trackball mode temporarily (while key is pressed) | Delete |
| DPad left/up/right/down | KEYPAD_4/8/6/2 |
| DPad center click | KEYPAD_5 |
| Onion alpha increase/decrease | KEYPAD_MULTIPLY(*) / KEYPAD_DIVIDE(/) |
Note that, to use keypad keys, you must first disable NumLock on your development computer.
Working with Emulator Disk Images
The emulator uses mountable disk images stored on your development machine to simulate flash (or similar) partitions on an actual device. For example, it uses 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.
Note: The default storage location for AVDs is in ~/.android/avd on OS X and Linux, C:\Documents and Settings\<user>\.android\ on Windows XP, and C:\Users\<user>\.android\ on Windows Vista.
To let you 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 you use the options, the emulator searches for the image file under the image name or location that you 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 Images
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 you override the location under which the emulator looks for the default user data image.
The emulator also provides a startup option that lets you override the name of the default user data image, as described in the table below. When you use the option, the emulator looks in the default directory, or in a custom location (if you 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 on two disk images: a user-data image and (optionally) an SD card image. This emulates 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 you override the actual names and storage locations of the runtime images to load, as described in the table below. When you 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 you 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 you 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 you 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 you 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 as described above, and at the custom location/name that you specified at startup.
- If it finds a user-data image, it mounts the image and makes it available to the system for reading/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 you specify in -data startup option.
Note: Because of the AVD configurations used in the emulator, each emulator instance now gets its own dedicated storage. There is no need to use the -d option to specify an instance-specific storage area.
SD Card
Optionally, you can create a writeable disk image that the emulator can use to simulate removeable storage in an actual device. For information about how to create an emulated SD card and load it in the emulator, see SD Card Emulation
You can also use the android tool to automatically create an SD Card image for you, when creating an AVD. For more information, see Managing Virtual Devices with AVD Manager.
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 /cache partition image
The emulator does not permit renaming the temporary system image or persisting it at device power-off.
The /cache partition 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 at which to persist the /cache image at device power-off. If <file> does not exist, the emulator creates it as an empty file.
You can also disable the use of the cache partition by specifying the -nocache option at startup.
Emulator Networking
The emulator provides versatile networking capabilities that you can use to set up complex modeling and testing environments for your 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 your development machine's network interfaces and settings and from the internet. An emulated device can not see your 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 your host loopback interface (i.e., 127.0.0.1 on your 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 you have two instances running concurrently on your 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. For information about how to let emulator instances communicate over TCP/UDP, see Connecting Emulator Instances.
Also note that the address 127.0.0.1 on your development machine corresponds to the emulator's own loopback interface. If you want to access services running on your development machine's loopback interface (a.k.a. 127.0.0.1 on your machine), you 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
Each emulator instance runs behind a virtual router, but unlike an actual device connected to a physical router, the emulated device doesn't have access to a physical network. Instead it runs as part of a normal application on your development machine. This means that it is subject to the same networking limitations as other applications on your machine:
- Communication with the emulated device may be blocked by a firewall program running on your machine.
- Communication with the emulated device may be blocked by another (physical) firewall/router to which your 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 your 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 your 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 Redirections
To communicate with an emulator instance behind its virtual router, you need to set up network redirections 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 redirections, you create a mapping of host and guest ports/addresses on the the emulator instance. There are two ways to set up network redirections: using emulator console commands and using the ADB tool, as described below.
Setting up Redirections through the Emulator Console
Each emulator instance provides a control console the you can connect to, to issue commands that are specific to that instance. You can use the redir console command to set up redirections 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 redir command to work with redirections. To add a redirection, use:
add <protocol>:<host-port>:<guest-port>
where <protocol> is either tcp or udp, and <host-port> and <guest-port> sets the mapping between your own machine and the emulated system, respectively.
For example, the following command sets up a redirection that will handle all incoming TCP connections to your 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, you can use the redir del command. To list all redirections for a specific instance, you can use redir list. For more information about these and other console commands, see Using the Emulator Console.
Note that port numbers are restricted by your local environment. this typically means that you cannot use host port numbers under 1024 without special administrator privileges. Also, you won't be able to set up a redirection for a host port that is already in use by another process on your machine. In that case, redir generates an error message to that effect.
Setting Up Redirections through ADB
The Android Debug Bridge (ADB) tool provides port forwarding, an alternate way for you to set up network redirections. For more information, see Forwarding Ports in the ADB documentation.
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 your 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 your "hosts" file (/etc/hosts on Linux/OS X, %WINDOWS%/system32/HOSTS on Windows).
When starting the emulator at the command line, you 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. You might find this option useful if you 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 your emulator must access the Internet through a proxy server, you can use the -http-proxy <proxy> option when starting the emulator, to set up the appropriate redirection. In this case, you specify proxy information in <proxy> in one of these formats:
http://<machineName>:<port>
or
http://<username>:<password>@<machineName>:<port>
The -http-proxy option forces the emulator to use the specified HTTP/HTTPS proxy for all outgoing TCP connections. Redirection for UDP is not currently supported.
Alternatively, you can define the environment variable http_proxy to the value you want to use for <proxy>. In this case, you do not need to specify a value for <proxy> in the -http-proxy command — the emulator checks the value of the http_proxy environment variable at startup and uses its value automatically, if defined.
You can use the -verbose-proxy option to diagnose proxy connection problems.
Interconnecting Emulator Instances
To allow one emulator instance to communicate with another, you must set up the necessary network redirections as illustrated below.
Assume that your environment is
- A is you development machine
- B is your first emulator instance, running on A
- C is your second emulator instance, running on A too
and you want to run a server on B, to which C will connect, here is how you could set it up:
- Set up the server on B, listening to 10.0.2.15:<serverPort>
- On B's console, set up a redirection from A:localhost:<localPort> to B:10.0.2.15:<serverPort>
- On C, have the client connect to 10.0.2.2:<localPort>
For example, if you wanted to run an HTTP server, you can select <serverPort> as 80 and <localPort> as 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, you use the dialer application and SMS application (if available) installed on one emulator
To initiate a simulated voice call to another emulator instance:
- Launch the dialer application on the originating emulator instance.
- As the number to dial, enter the console port number of the instance you'd like to call. You 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>).
- 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.
You can also connect to an emulator instance's console to simulate an incoming voice call or SMS. For more information, see Telephony Emulation and SMS Emulation.
0 件のコメント:
コメントを投稿