Package Details: android-sdk-build-tools r30.0.2-1

Git Clone URL: (read-only, click to copy)
Package Base: android-sdk-build-tools
Description: Build-Tools for Google Android SDK (aapt, aidl, dexdump, dx, llvm-rs-cc)
Upstream URL:
Keywords: android
Licenses: custom
Submitter: xgdgsc
Maintainer: mynacol
Last Packager: mynacol
Votes: 462
Popularity: 1.62
First Submitted: 2013-05-16 03:44
Last Updated: 2020-08-17 13:57

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 Next › Last »

egore911 commented on 2014-11-01 18:27

21.1 was released

felixonmars commented on 2014-10-24 15:45

Looks like a typo in PKGBUILD: _ver=21.02. => _ver=21.0.2

mvdan commented on 2014-07-17 07:06

No idea, sorry. But I suppose sed isn't that bad.

tsp commented on 2014-07-09 01:50

@mvdan: Yeah that should work. I tried that at some point but it didn't work. It's more likely that I botched it though. Is there any way to do that in the pkgbuild that doesn't require some epic sed-fu or something?

mvdan commented on 2014-06-30 15:43

@Teasp00n: What about placing them in the right order, so that the clang package binary takes precedence over the one in this package? I think that we should place the clang path before this one in order for that to work. I suppose we can play with the names of the scripts to make the other one come before this one. This would not normally happen since 'android-' comes before 'clang', I guess.

Also, the right package version is 20.0.0. If you want to use the number 20 that's fine, but the install path should still be 20.0.0 as in /opt/android-sdk/build-tools/20.0.0. Changing it is just asking for trouble :)

tsp commented on 2014-06-29 08:29

@mvdan: Sorry for the extremely late reply. I didn't see your comment. The problem is `which clang` returns the one in the android tools directory and not the version of clang explicitly installed on the system. I've had local builds fail because of this. Something about the symbols of libraries not being compatible/ valid. If I remove the android build tools from the path the problem is solved. That said, I also use the tools on the command line. I would prefer that they were still on the path, it's only the bundled clang I have an issue with.

Anonymous comment on 2014-06-26 20:30

Upgraded PKGBUILD for r20 and switch to https

klusark commented on 2014-06-26 18:00

Version 20 is out

mvdan commented on 2014-05-22 15:10

For what it's worth, I do use the build-tools from the command line, and not having PATH set up automatically is a tad sub-optimal. What problems does Clang have with this, exactly? Are there some binaries that conflict?

xgdgsc commented on 2014-04-18 06:15

Well, if it conflicts, I think removing the adding to PATH should be fine. Most people just use IDEs that can find these things. Is removing it OK for most of you?