Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
Mono organizations on
GitHub to continue tracking issues. Bugzilla will remain
available for reference in read-only mode. We will continue to work
on open Bugzilla bugs, copy them to the new locations
as needed for follow-up, and add the new items under Related
Our sincere thanks to everyone who has contributed on this bug
tracker over the years. Thanks also for your understanding as we
make these adjustments and improvements for the future.
Please create a new report on
Developer Community or GitHub with
your current version information, steps to reproduce, and relevant error
messages or log files if you are hitting an issue that looks similar to
this resolved bug and you do not yet see a matching new report.
Users are reporting that builds from Xamarin Studio and Visual Studio are no longer working, because of issues with aapt.exe.
Please see this thread for more details:
It appears this is due to a new location for the build tools in ADT 22:
The temporary workaround is to copy all files from android-sdk\build-tools\17.0.0\ to android-sdk\platform-tools\
This was fixed in 4.6.6:
I did read that thread (after commenting on the other thread, D'oh!), but this issue actually started happening for me with 4.6.6, and is still occurring with 4.6.7.
It seems like the exact opposite of the bug reported in the other thread: XS is looking for aapt.exe in the build-tools/17.0.0 directory, while in fact it's located in platform-tools. When I copy the files over to build-tools/17.0.0, all is fine again.
The 4.6.x logic is:
var buildToolsBase = Path.Combine (androidSdkDirectory, "build-tools");
if (Directory.Exists (buildToolsBase))
return Path.Combine (Directory.EnumerateDirectories (buildToolsBase).First ());
return Path.Combine (androidSdkDirectory, "platform-tools");
i.e. if build-tools exists, we grab the first subdirectory; otherwise we use platform-tools.
"17.0.0" isn't even a factor there.
This is also why 4.6.6+ breaks with a "updated yet inconsistent" SDK upgrade: the build-tools directory exists but is empty, resulting in .First() throwing an exception.
Given the above, I don't see why XS would be looking for build-tools/17.0.0/aapt.exe if the build-tools directory doesn't exist at all, and thus I am confused by Comment #2.
4.7.6 completely overhauls this, and does specifically check for build-tools/17.0.0 (though it will also sanely check other directories looking for aapt.exe, including platform-tools, and error out with XA5205 if aapt.exe can't be found).
Could you provide a file listing of your Android SDK directory tree, e.g. `find $ANDROID_SDK_PATH` or `tree` (which does exist on Windows).
In my case, the build-tools/17.0.0 directory existed and was non-empty, but did not contain aapt.exe and the related files. As soon as I copied them over from platform-tools, things started working again.
I cannot reproduce now what was in the 17.0.0 dir exactly, unfortunately. I can recall downloading SDK 22 through the Android SDK Manager. And I think I also installed the Intel HAXM tools around the same time. But the issues only started occuring after the 4.6.6 update.
I will post the dirtree tomorrow.
> the build-tools/17.0.0 directory existed and was non-empty, but did
> not contain aapt.exe and the related files.
That is not something I've ever seen or seen reported elsewhere. :-(
On the bright side, the 4.7.6 logic should actually handle that. (I hope.)
Care to try the 4.7.6 alpha? ;-)
Yeah, personally I would be ok to chalk this up to an Android SDK Manager glitch then.
Let's not worry about it anymore if the 4.7.6 handles this obscure case as well. Especially since my workaround is fine for now.