Introducing the Android Emulator for Visual Studio

Microsoft released a preview of Visual Studio 2015 this week, which includes Android development tools. When installing, if you choose Android development, Visual Studio will also install the Visual Studio emulator for debugging Android applications.

Before introducing this new emulator, let's talk about why we need a new Android emulator - of course, you can also jump directly to the part you are interested in :-)

The necessity of Android emulator

We know that simulators play an important role in the programming-compiling-debugging development cycle (even more important than physical devices). So we believe that the simulator released today is essential in development.

Having an excellent simulator does not mean that we do not need physical devices. On the contrary, they are actually complementary.

In the following cases, you can only use physical devices for testing, and the simulator is useless:

Test the performance of your code. Although the simulator can help you correct errors in your code, it cannot accurately give you an estimate of the performance of your code on a specific device. After all, we all hope that the test results are as close to the actual user experience as possible.

Test certain hardware issues. For example, if you want to test the touch sensitivity of the game, the sound effects of the external speaker, or debug the bug of the OEM device, these tests can only be performed on the physical device.

Evaluate the actual user experience. For example, is the human-computer interaction interface you designed suitable for users to operate with one thumb while walking?

Apart from the scenarios listed above, everyone should be happy to use the simulator. Because debugging code usually takes up 80% of the development time, and the simulator greatly improves our work efficiency. (Unless your simulator has other blocking problems or usage restrictions). Here are a few reasons to use the simulator:

Most of the testing work is used to verify the correctness of the program rather than its performance, and most of the code has nothing to do with the underlying hardware. So using a simulator is great.

It is a luxury to buy a lot of hardware devices for testing (especially if you keep buying new machines). Most of the hardware differences can be configured using simulator software, such as screen resolution, DPI of different screens, API level/platform version number, etc.

It is also difficult to use physical actions to test the application's response to sensor input, such as changes in movement, location, or network/battery. In this scenario, it is very convenient and efficient to choose an emulator to simulate sensor input. For example, the emulator can simulate the change of location during a journey and test the application's response to the change of location.

There is another additional convenience of using an emulator. Managing multiple physically connected USB devices (a lot of wires and interfaces) is very troublesome. At this time, using an emulator is much simpler. The emulator is just an ordinary application layer running on the computer, eliminating the trouble of physical connection and is very easy to manage.

Therefore, the simulator is a good companion for software development, and we hope to make the VS simulator the best. We collected the pain points of the existing simulators from developers and solved them one by one in our version:

Slow. This is the top complaint from Android developers. "The emulator is so slow that it seriously affects my productivity. I'd rather test on a real device." Slow is unacceptable. The emulator should run faster than the real device to improve testing efficiency. Remember, we are not testing the running performance of the code, for functional testing, we want to make the emulator run as fast as possible.

Conflict with Windows Hyper-V. Many simulators need to turn off Hyper-V when running, or the performance is worse when using Hyper-V. However, enabling Hyper-V is a common configuration for most developers, and frequently restarting the computer to turn Hyper-V on and off is unacceptable.

This is even more frustrating for developers who want to use the Windows Phone emulator (based on Hyper-V). You can't keep restarting and configuring your computer settings just to test cross-platform code.

Additional purchase and installation steps. If you are already using Visual Studio, then congratulations, you don't have to purchase and install another simulator software.

More expenses. Buying a good emulator also means higher expenses, which is also a major reason for not using emulators. Visual Studio's Android emulator is included and does not require additional fees.

In short, our Android emulator in Visual Studio solves the above pain points. Without further ado, let's start by introducing the debugging method of using the Android emulator in VS. We will start with how to choose an Android emulator.

Debugging Android programs with Visual Studio emulator

No matter which programming model you use: Cordova with JavaScript (or TypeScript), C++, or Xamarin with C#, you can write, compile, and debug Android code in Visual Studio 2015 Preview.

When you start debugging, you select a debug target. The debug target can be a physical device, or an emulator running on your computer. Let's see how to select a debug target for Cordova and C++ in Visual Studio 2015 Preview, and for Xamarin in Visual Studio 2013.

The debug target selection menu for C++ projects is shown below:

For Cordova projects, select the last two items in the menu, as shown in the screenshot below:

(Remember, don’t select “Android Emulator” because it runs too slowly)

The options for the Xamarin project are shown below:

***Uncheck "Use Fast Deployment" in the Android option of the project properties.

Note: If you want to use the VS emulator temporarily from another Android IDE. First, start the emulator as described above; then, close the project and keep the emulator running. Other IDEs can call the VS emulator via ADB.

After selecting the debugging target, press F5 and your application will be published to the simulator. Just like debugging VS code, the program will stop at the breakpoint, and then you can view the stack, variables, etc. Now, everyone knows how to debug with the simulator, right? Then let's continue with other features.

Sensor simulation and other capabilities of the Visual Studio Android Emulator

In addition to using the simulator as a target board for deployment, you can also use the simulator's sensor simulation and other features. The following will explain some of them in no particular order.

Zoom

You can adjust the display size of the simulator on your development machine (host side). The DPI value of the simulator is determined by your host monitor and has nothing to do with the scaled size. So if you feel that the simulator takes up too much desktop space, reduce it.

You can adjust the size using the "Zoom" button in the toolbar on the right side of the simulator.

You can also use full screen mode by clicking the "Fit to Screen" button above the "Zoom" button.

If you want to take a screenshot of a program running in the simulator (for example, using the built-in screenshot tool of Windows), to achieve the best effect, you need to adjust the simulator's zoom ratio to maximum (that is, 100%). If you want a better effect, you need to use the screenshot tool that comes with the simulator, which I will mention later.

Screen orientation/rotation

Unless your app interface is fixed, you should test the various effects of the app interface when the phone is in different orientations, such as portrait, left landscape, and right landscape. There are two buttons on the vertical toolbar, "Rotate Left" and "Rotate Right", which can rotate the simulator left and right respectively. After rotation, the size of the simulator does not change.

Network Information

Since the simulator uses the network connection on the host machine, no network configuration is required.

You can view network configuration information by clicking the "Tools" button on the vertical toolbar, then clicking the "Network" tab in the expanded "Additional Tools" panel.

Positioning (GPS)

If your app is related to navigation, geofencing, walking/biking/driving, then the location and driving simulation features in the "Location" tab of the "Additional Tools" panel will become very useful.

The map can be dragged around, zoomed in and out, and even searched for specific locations. Map points are created by placing or removing pins on the map. The coordinates are displayed in the lower left corner. The Save button on the upper toolbar can save the map points as an XML file. When needed, you can reload it.

In addition to the "Live" mode, which directly changes the simulator's GPS position from the points on the map, there are other modes to choose from! For example, if you want to set a few points on the map and simulate the effect of moving between these points, then select the "Pin" mode. Then click the Play button on the far right of the toolbar to simulate the effect of moving from one point to another. You can even set the speed of movement (in seconds).

***, there is also a "Route" mode which is similar to the "Pin" mode. This mode also simulates the movement from one point to another. But it is a little more "twistful". The simulator will automatically calculate the actual path between the two points and create invisible points for this path at intervals of 1 second. The speed of movement between these points depends on another setting. The options of this setting are: "Walking" (5 km/h), "Biking" (25 km/h), "Speed ​​Limit" (on the map, different locations have different speeds), and "Fast".

Acceleration Sensor

If you want to test how your app responds to the movement of the phone, turn on the Accelerometer in the Additional Tools panel.

In the 3D panel, just press and hold the red dot inside and drag it in the direction you want to simulate. If your application has written code to handle movement events, it will be able to receive the event of the phone moving.

The X, Y, and Z values ​​in the lower left corner can be reset by clicking the "Reset" button. You can also set the initial orientation of the phone by: Portrait Standing, Landscape Standing, Portrait Flat, and Landscape Flat.

***, you can click the "Play" button in the lower right corner to simulate the vibration effect. The vibration effect we can see is actually the change of X, Y, Z values. If these values ​​no longer change sharply, it means that the vibration has stopped.

Power/battery simulation (and power on/off button)

If your application needs to respond to changes in battery power, you will like the features provided in the "Battery" tab in the "Additional Tools" panel.

There is a slider inside to set the remaining battery power. As you adjust the power level, the battery icon in the upper right corner will also change. Your applications will also react accordingly.

If you uncheck "Battery Charging", the simulator screen will turn blank after a period of time. This time can be set in System Settings - Display - Sleep. Click the power switch button (Power) in the vertical menu bar to wake up the simulator from sleep.

screenshot

To take a screenshot of the app, open "Other Tools" and switch to the "Screenshot" tab. Then click the "Capture" button, which will take a screenshot and let you preview the screenshot immediately. If you want to save the screenshot, click the "Save..." button. If you don't like the screenshot you just took, ignore it or click the "Capture" button again.

The Screenshot Tool always takes screenshots at 100% resolution (as shown in the lower left corner), regardless of the zoom setting, and always takes screenshots from the front, regardless of the image rotation you choose.

Install APKs by dragging and dropping

APK is the installation file for Android. To install an APK file on the Visual Studio emulator, simply drag the APK file into the emulator. During the installation, the emulator will prompt "Copying files...". After the installation is complete, there will be a message box prompting "The xxx file has been successfully installed into the Android system." Make sure your APK file is generated in x86 mode!

Of course, you can also drag other types of files (non-APK files) into the emulator, and these files will be saved to the SD card. This is what we will talk about next.

SD card

If you need to read and write to the target device's SD card, the emulator can simulate the SD card using a folder on the hard disk.

Note that the Android image uses a separate VHD file to support SD card emulation. So if you want to transfer files to and from the SD card on your development machine, you can mount this VHD on your Windows machine: close the emulator (to stop the VM), then find the location of the VHD in Windows Explorer and double-click it to mount it. By default, the VHD is located here:

C:\Users\%username%\AppData \Local\Microsoft\XDE\Android\vsemu.sdcard.vhd

The VHD is now mounted as another drive on your Windows computer and you can use it like any other drive. Before restarting the simulator, you must unmount the VHD, which you can do by right clicking on the drive and selecting "Eject".

Support for SD cards can be implemented in the image to allow other built-in Android apps and features to be used, such as browser downloads and camera apps - which brings me to the next capability.

camera

Typically you'll want to use the camera from within your app (using an appropriate API), and we support this. You can also use the built-in camera app directly. When you launch the camera in the simulator, you'll see a fixed image, and you can take snapshots of this image to simulate taking a photo.

Audio playback, keyboard text input...

Of course the simulator provides other features, although they require "effort" from the product team :-). I won't list all of them here, but there are two worth noting:

You can use your machine's keyboard to enter text in the emulator

Any audio played from the simulator can be heard through your machine's speakers

Configuration

In the preview version, two sets of default configurations are provided:

Typical Android phone configuration: 5-inch screen, 295 DDI, 720x1280, 1024MB

Typical Android tablet configuration: 7-inch screen, 315DPI, 1080x1920, 2048MB

You can modify memory allocation in the preview version, and the Hyper-V Manager configuration window provides an option to configure "Startup RAM". Note that you can also change the number of CPU cores used in each configuration (the default is 2). However, we have not tested all possible configurations.

Our work has just begun, and we will provide more features in later versions. We also hope that everyone will give us feedback in the following questionnaire so that we can sort out the needs.

Take a look at the internal implementation principle

If you are interested in how the Visual Studio Android Emulator is implemented, I can simply answer this question by reusing the work of other products. Conceptually, an emulator software can be divided into the following 4 parts:

The virtual machine (represented as a vhd) is used to simulate the target board you use. Here, the target machine is Android. We first get the code from the Android Open Source Project (AOSP), improve it, and configure it as an x86 virtual image, so that Visual Studio can be used for quick debugging.

Shell/Chrome provides a user interface that can be used to load virtual images and render them. You can compare this process to remote desktop: you are actually connecting to a local image remotely. Our work started from here, directly borrowing the shell/chrome of Windows Phone Emulator (which we call XDE internally). Then we made some necessary modifications based on the special needs of Android.

Virtualization technology, XDE uses virtualization technology to load images, so that remote connection and control can be performed. Windows has a deep foundation in virtualization technology, and we use the virtualization technology Hyper-V to complete this work.

Connection pipeline, VS and XDE need to communicate through the connection pipeline, the same debugging engine and virtual image also need. Here we reuse the existing connection mechanism between XDE and Visual Studio, and also use Android Debug Bridge (ADB).

Now, let’s take a look at the current usage restrictions of this application. I once again hope that everyone can give us feedback on improvements, and we will give priority to solving the problems you report.

Current usage restrictions

What we are sharing with you today is an early preview version. There are still many problems and bugs in this version. I hope you can report more of them to us. At the same time, this version has many known usage limitations - please quickly report the features you want most to us, and we will give priority to them:

The emulator currently cannot render applications that use OpenGL 2 and above directly or indirectly. This feature will be supported soon, we have already implemented it in internal builds, and it will feel very smooth!

There are so many different Android versions on the market. We currently only support KitKat API 19 (android-4.4.4_r1). More versions will be supported in the future...

If your app uses the Google Play Services layer, then these apps cannot be run directly on the emulator. This is because the Android image we build does not include the GMS package (we have not yet obtained the relevant license).

You need to recompile your code under x86. If your code can only run under ARM, or uses third-party libraries that cannot run under x86, then your code cannot run on our simulator at present.

You can only install our simulator on operating systems that support Hyper-V. Operating systems that do not support Hyper-V include Windows 7 and other non-Windows systems, or running on other virtual machines.

If the above limitations are what you need most, the current solution is to use a real device for testing (or find a better simulator). We will shorten the list of limitations above in later versions, so please fill in the survey to help us prioritize.