Add AAR support

[juandiana]

It would be nice to be able to have the methods count for library projects. This means supporting the examination of the AAR output.

In contrast to APK archives, AAR archives contain a classes.jar file inside, instead of a classes.dex file.

To compile JAR files into DEX files, one would use the dx command line tool available in the Android SDK:

dx --dex --output=classes.dex classes.jar

It would be nice to do this from Java instead of calling an external command line tool to do this conversion. Looking at the source code of the dx tool, the method processOne looks like it would be useful for this.

[benjamin-bader]

While I agree that it would be helpful to see the method and field counts for a library as it is being developed, I'm not sure about the suggested approach. Because AARs don't contain their transient dependencies, the counts we'd obtain from dexing them would be lower-bound approximations only, and dependency resolution is very much out of scope here.

Given that, we may as well just examine the .class files in the included JAR directly and count from those.

I'd welcome a pull request that does this. A good place to start would be DexFile.groovy#extractDexFromZip.

[hamen]

Hi guys. Support for library project would be much appreciated indeed.

[vanniktech]

+1

[jaredsburrows]

+1

[ultrah]

+1

[benjamin-bader]

Thanks for your interest. I'm sorry if I was unclear above, but this is not a priority for me and I won't be able to make time for it. If someone wants to tackle this and open a pull request, I'd be happy to accept it!

[kenkyee]

+1...hmm...it doesn't look that bad to change this except for figuring out how to test it.
Looks like you just modify that extractDexFromZip method so that if the filename has a postfix of ".aar", it extracts the classes.jar and then runs that dx command against it. The hard part is finding the dx command because it's buried inside the Android build tools and it won't be on your path :-(

[vanniktech]

Yeah but it'll be on $ANDROID_HOME environment variable which usually every developer has set or maybe you can also get the sdk.dir from the gradle.properties file

[kenkyee]

it's more like $ANDROID_HOME/build-tools/[someVersion]/dx
though I suppose you could just look up all the subdirectories under build-tools and grab the first one...hmmm...doesn't seem that bad...

[kenkyee]

I have a fix for this...will submit a PR

[jaredsburrows]

@kenkyee +1

[benjamin-bader]

AAR support is landed as of 0.4.5-SNAPSHOT; thanks for the good work @kenkyee!

[kenkyee]

grrrr...OSX.
http://stackoverflow.com/questions/27712600/why-are-environment-variables-always-null-to-gradle-only-when-run-from-intelli
You should make a note of this in the release notes. I need to know where the Android SDK is, so I look up the ANDROID_HOME variable. Works fine if you run gradle on the command line, but if you run it in IntelliJ, you have to do this weirdness w/ launchctl to set the system variable for UI apps.

[benjamin-bader]

Oh, interesting! I forgot all about that - personally I nearly never build in Android Studio.

I suppose we ought to fail gracefully if $ANDROID_HOME is empty.

[jaredsburrows]

@kenkyee @benjamin-bader Same. I do not even use Android Studio.

[kenkyee]

It currently throws an error if ANDROID_HOME is null which stops it, so it's not graceful.
I'm going to see if I can get it to read the sdk.dir out of local.properties. I always wondered what the point of that file is, but realized what it was for last night when I tried the plugin on a project :-)
Will put up a PR when I get that working...

[kenkyee]

added a PR for looking in local.properties. There should be no reason to need to fail gracefully if it can't find the SDK location...