You are a Mac owner. You’re used to the fact that “things just work”. But you are also a programmer, eager to write software for Android platforms using Xamarin? You even managed to set up your development environment using your Mac, Parallels Desktop, Windows 8 and Xamarin. And now you are trying deploy your first Xamarin Android application to your physical device or an emulator? Alright, please try that now. Fail. Then come back to this article and read on.
What’s required to write great Android applications with Xamarin.Android using Visual Studio on your Mac?
Here’s our shopping list:
- A Mac. You got that far already.
- Parallels Desktop 9
- Windows 8.1 installed inside Parallels Desktop
- Visual Studio 2012 or 2013
- Xamarin business license including the Visual Studio Plugin
- Android SDK
- Some Android Emulator
- Hopefully at least 30% of the real devices out there for testing (don’t worry, that’s probably less than 500 physical devices! ;-))
All is installed. I want to deploy to my physical Android device!
So you created your Android “Hello World!” in Visual Studio and now you want to test it on your physical Android device. Easy enough: open the drop down and pick the connected device:
What do you mean, the device is not listed? I suppose you plugged it in, turned it on and configured Parallels Desktop to connect the USB device to Windows and not to the Mac? Windows played a nice “Bading!” sound and you can browse the device from the Windows Explorer – still: no device in the Visual Studio dropdown. How is this possible?
If Google claims “installed”, they really mean “almost installed but not really”
The reason for the missing device under Windows is a missing driver. You have probably seen the Android SDK Manager. You can open it from Visual Studio by clicking the button with the three small boxes, right next to the devices dropdown.
Using the SDK manager, various things can be installed. One of them is the “Google USB Driver”. This missing driver is the reason for the Android device showing up in Windows Explorer but not in Visual Studio. So tick the checkbox now and install the missing driver. When done, the SDK manager will show you “Installed”, just like in the image above.
However be warned: “installed” does not mean the driver was installed. In fact, it means the driver was downloaded. Nothing more. This was driving me crazy. I searched the web and found the hint about installing the driver from the SDK and still the device selection wouldn’t work.
In order to really-install (TM) it you will have to dig into the dark areas of Windows 8: the Device Manager! Right click “Computer” and select “Manage”. Then pick the “Device Manager” snap-in.
Expanding “Other Devices” will show you the connected physical Android device. In my case, it’s a Nexus 7. And clearly, a driver seems to be missing.
Right click and search for drivers.
Navigate to the folder where the Android SDK Manager “installed” the driver. On my machine this is C:/Users/rene/AppData/Local/Android/android-sdk/extras/google/usb_driver.
Be brave, ignore all warnings (why wouldn’t you trust Google!?) and install the driver:
When done, Device Manager should look something like this:
Now go back to Visual Studio. You might have to restart it, set the Android project as the startup project and open the dropdown. The physical device will show up. If it doesn’t, there is a chance that the device does not trust the machine it is connected to. Turn the device on and confirm that the PC is always trusted.
Let’s move on to the Android Emulator!
Not so fast, young Skywalker! And I mean that literally. The Android Emulators are slooooooooooow.
But there’s help around the corner: Genymotion! Go download it here, it’s free and fast!
Genymotion is using Oracle’s Virtual Box to emulate Android devices. And the best is, it comes with a large collection of preconfigured devices with various operating system versions. You can just go and download the required image, press the start button and you’re done. The performance is just amazing.
Once you got your virtual device downloaded, start it and watch Parallels Desktop crash. It will complain about an “incompatible virtualization solution running”. Who said it would be easy?
Make Genymotion and Parallels Desktop live in harmony
The reason for this is that on the Mac, hardware acceleration cannot be shared among virtual guest systems. Since Parallels Desktop is already using the hardware, Genymotion/Virtual Box cannot use it. But you probably don’t want to turn off hardware support for your fancy Windows 8, so the only option is to disable it for the virtual Android device.
Will it still be as fast? No. But fast enough. On my iMac Core i7 (24GB RAM, 3.4Ghz) it is still magnitudes faster than the original Android emulators.
In order to disable hardware acceleration, run Virtual Box and select the virtual Android device. Click “Change”, then “System”, then “Acceleration” and uncheck the setting “VT-x/AMD-V“.
Important Note: if you’re virtual device has more than one CPU, Virtual Box will silently reactivate the VT-x option! This is yet another drawback but you will have to set the number of CPUs to on in the “Processor” tab.
So configure the CPU first, then switch back, deactivate the option and save.
Quit Genymotion, quit Virtual Box and restart it.
Connect to the virtual Genymotion device from Visual Studio
History is repeating itself and just like the real physical devices, Genymotion devices refuse to show up in the devices dropdown in Visual Studio.
We need to introduce the virtual Android device which is running inside Virtual Box on the Mac to Windows, running inside Parallels Desktop. You have two options:
- Set up an SSH tunnel
- Adjust your Parallels Desktop network settings
In both cases you will need to know the IP Address of the Android device. To obtain the address, start up the Android image you would like to use. When it is running, have a look at the emulator’s top status bar. It will show the IP address of the device. If you don’t see it, make the emulator window wider.
In my case, the IP is 192.168.56.101. Please note that the Wifi settings on the emulated device will give you a different IP and also using
in the Mac Terminal won’t give you the correct address.
To fix this problem you can either set up an SSH tunnel or change your Parallels Desktop network settings to “Shared”.
Configure the SSH tunnel
Open Terminal on your Mac. Create the tunnel using
ssh -f -L 5555:192.168.56.101:5555 -N 127.0.0.1
This will forward all incoming request for 127.0.0.1 on port 5555 to 192.168.56.101 on port 5555, or saying it differently: from the Mac to the Genymotion device.
On the Windows machine you will have to tell the Android debugger “ADB” where to talk to. ADB can be found in the Android SDK installation folder, in my case this is C:\Users\rene\AppData\Local\Android\android-sdk\platform-tools.
Open a command window and restart ADB and let it know where to talk to:
adb kill-server adb connect localhost
You should get a success message. If this does not work for you (it didn’t for me with my network configuration!), I suggest you try the second option.
Adjust Parallels Desktop network settings
Now it is time to change the mode to “shared network” in the settings of your Windows VM.
The shared network frees you from the requirement of using an SSH tunnel. This means that in the Windows command prompt you can connect directly to the Genymotion device using the Android device’s IP:
adb kill-server adb connect 192.168.56.101
You should get an output like
connected to 192.168.56.101:5555
Back in Visual Studio
Switch back to Visual Studio, close and restart it and open your Android project. The dropdown will now show the connected physical device if it is still attached, the Genymotion device and all the “crap” emulators:
All you have to do now is to press F5 and deployment starts:
And now: go build the next number one app!
EDIT: I have just found out something important. If you start the Android Device in Genymotion while Parallels Desktop is already running, PD will show you an error that a “non compatible virtualization program was exectuted”. Next thing, PD will shut down your VM. However if you start the device before your VM, everything will be fine! Also if you shut down the emulator and restart it, PD won’t complain. This smells a lot like Parallels wants to make other virtualization solutions look bad.