Bug 12414 - Aapt.exe location not correct anymore
Summary: Aapt.exe location not correct anymore
Alias: None
Product: Android
Classification: Xamarin
Component: General ()
Version: 4.6.x
Hardware: PC Windows
: --- normal
Target Milestone: ---
Assignee: Jonathan Pryor
Depends on:
Reported: 2013-05-27 15:04 UTC by info
Modified: 2013-05-30 06:27 UTC (History)
1 user (show)

Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and 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 Links.

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.

Related Links:

Description info 2013-05-27 15:04:31 UTC
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\
Comment 2 info 2013-05-28 19:52:27 UTC
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.
Comment 3 Jonathan Pryor 2013-05-29 16:47:03 UTC
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).
Comment 4 info 2013-05-29 20:05:02 UTC
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.
Comment 5 Jonathan Pryor 2013-05-30 00:26:19 UTC
> 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? ;-)
Comment 6 info 2013-05-30 06:27:34 UTC
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.

Thanks Jon!