Fixing aapt, idl and dx paths from new build-tools

[alanvdam]

The 'Android SDK Build-tools are not installed in the platform-tools anymore but in build-tools/[version]. I added a new key buildToolsPath and the user defined key buildToolsVersion. Using these the aapt, idl and dx binaries can be found again.

[tomjadams]

I have merged in these changes locally & confirm they work on three machines in our team.

[relrod]

+1, any chance of getting a release out with this fix, @jberkel?

[jberkel]

this will break builds for users of older sdks. it would be nicer to auto detect the right path so that it works with old&new

[alanvdam]

@jberkel you're right. I changed the request. It now checks if the build-tools directory exists. If it does it takes that directory (buildToolsVersion appended) otherwise it returns the 'old' platformToolsPath. I did not verify that this works for old sdks.

[fxthomas]

This doesn't work right away for me, as I have an app running on API v16, but the installed build tools are revision 17. I think the build-tools version is actually not the same as the API version. Can anyone confirm that?

[fxthomas]

I took @alanvdam's code and added version autodetection on my branch (take the second commit, the first was committed by mistake and I can't find a way to remove it) :

• If there is no build-tools folder, the buildToolsVersion key is set to None by default
• If there is a build-tools folder, buildToolsVersion is set to Some(version), where version is the highest build-tools version available

If the version is None, buildToolsPath is set to platformToolsPath, otherwise to build-tools/version. If something doesn't work you can always set the version or the path manually. Thoughts?

[tomjadams]

That sounds OK to me. However I'll note that three different installs done here on the same day in the same way of the same SDK version yielded three different paths to the build tools directory :) I think there may be feedback where things don't work in the wild, but they could be addressed as they come up.

On Mon, Jun 3, 2013 at 11:13 PM, François-Xavier Thomas < notifications@github.com> wrote:

I took @alanvdam https://github.com/alanvdam's code and added version autodetection on my branch (take the second commit, the first was committed by mistake and I can't find a way to remove it) :

• If there is no build-tools folder, the buildToolsVersion key is set to None by default
• If there is a build-tools folder, buildToolsVersion is set to Some(version), where version is the highest build-tools version available

If the version is None, buildToolsPath is set to platformToolsPath, otherwise to build-tools/version. If something doesn't work you can always set the version or the path manually. Thoughts?

— Reply to this email directly or view it on GitHubhttps://github.com/jberkel/android-plugin/pull/176#issuecomment-18839903 .

tom adams e:tomjadamsgmail.com

[appamatto]

Is there ever a reason to use old build tools? It seems that the plugin should use the newest build tools but allow the user to manually set buildToolsVersion in case they are simply broken.

[appamatto]

I just realized this is exactly what @fxthomas is suggesting.

[aginiewicz]

If someone is on old SDK he can always symlink tools to new directory (or copy?). That's how I solved this on my machine, created symlinks like "aapt -> ../build-tools/17.0.0/aapt" and it works perfectly fine with android-plugin, no troubles packaging apps when using those from symlink, so someone can link other way around too I guess?

[appamatto]

Merged into the 0.6.4 branch. Thanks @fxthomas and @alanvdam!