Using the correct version of Android SDK Build-Tools with Xamarin Android
Senior Developer consultant, Wael Kdouh, walks us through what it takes to get Xamarin.Android working with the latest “24” SDK Build-tools package.
Google recently released a new final version “24” of the Android SDK Build-tools package. Of course, being a good citizen meant that I used the Android SDK Manager to update to the latest version. The short story (after debugging every stage of the tool chain with a colleague of mine) is that Xamarin.Android is not yet fully compatible with this version. The details can be found here. What is more important is not the resolution but rather the journey that I embarked on to resolve the issue.
It all started with updating to Android SDK Build-tools version 24 manually using the SDK manager shown above. After that I started facing the following errors:
Note: aapt stands for Android Asset Packaging Tool. This tool is part of the SDK (and build system) and allows you to view, create, and update Zip-compatible archives (zip, jar, apk). It can also compile resources into binary assets [Wikipedia].
At the beginning it didn’t make any sense so I tried switching between the directory that Xamarin points to for the Android SDK ( C:\Users\[user]\AppData\Local\Xamarin\MonoForAndroid\AndroidSDK) and the system wide system copy of Android SDK which could be found at C:\Program Files (x86)\Android\android-sdk. What that implies is that you have two copies of the same thing on your machine ( as a matter of fact Xamarin asks you which one you want to use when you first install it). You switch between directories using the following panel under visual studio:
When I switched to the system wide copy it suddenly started working. Luckily I hadn’t had the chance to update that yet. Now one thing to keep in mind here is that when you switch between the two versions the build will still fail due to its inability to contact the adb server. This is because you have to kill it manually from the task manager and restart Visual Studio before the adb server at the selected SDK directory gets utilized. I would like to point out here that using the Android Adb Command prompt came in handy to diagnose the adb server. For example it informed me that the device was detected and that the server was up. Very useful information when you are trying to debug.
Problem solved but how can you protect yourself in the future from falling into such a trap? Well the reality is that it hard to avoid it. As in addition to updating manually, sometimes it may be installed by the standalone Xamarin studio installer as shown below. The moral of the story is that even though you might not be able to avoid these headaches (hopefully they will be easier to detect with future versions of Xamarin) at least now you know where to look.