Why should I include a gradle dependency as `@aar`

Question

Why should (or shouldnt) I include a gradle dependency as @aar,

What are the benefits/drawbacks if any?

As you can see I added @aar to the libraries below that supported it. But everything seemed to work before doing that as well...

dependencies {
    compile fileTree(dir: 'libs', include: ['*.jar'])
    compile 'com.android.support:appcompat-v7:22.1.1'
    compile 'com.google.android.gms:play-services-maps:7.3.+'
    compile 'com.google.guava:guava:18.0'
    compile 'com.octo.android.robospice:robospice-spring-android:1.4.14'
    compile 'org.codehaus.jackson:jackson-mapper-asl:1.9.13'
    compile 'com.mcxiaoke.volley:library-aar:1.0.0@aar'
    compile 'de.psdev.licensesdialog:licensesdialog:1.7.0@aar'
}

Answer 1

Libraries can be uploaded in multiple formats, most of the time you'll be using .jar or .aar.

When you don't specify the @ suffix, you'll be downloading the library in it's default format (defined by its author, if not then .jar) along with all its dependencies.

compile 'com.android.support:appcompat-v7:22.1.1'

When you specify the @ suffix you enforce downloading the library in the format you specify (which may or may not exist). This is useful e.g. when author forgot to specify that the library is an .aar and maven (or gradle, not sure) treats it as .jar by default. When the @ suffix is specified the dependencies of this library are no longer downloaded so you have to ensure that manually.

compile 'com.android.support:appcompat-v7:22.1.1@aar'
compile 'com.android.support:support-v4:22.1.1@jar'

To ensure the full dependency tree of the library is downloaded while the @ suffix is specified you have to write it in the following way:

compile ('com.android.support:appcompat-v7:22.1.1@aar') {
    transitive = true
}

Answer 2

TL;DR: Ignore the @ suffix and you'll be just fine most of the time, if not all the time.

With that as prologue, here's my understanding of what's going on...

The @ syntax indicates that you want an artifact of this type, for cases where there may be multiple artifacts for that group ID/artifact ID that would be relevant for the situation.

For example, an Android library project naturally compiles down to an AAR, and so that would be the typical artifact that would be distributed. However, if the library project is not actually using resources, it could also be compiled down to a JAR, and therefore be usable in cases where an AAR would not. The library author could distribute both the AAR and JAR as separate artifact types for the same group ID/artifact ID, so tools can grab whichever one is appropriate. Tools where you don't supply the @ suffix will choose one, but if you do supply the suffix, the tool should abide by your request.

In the case of Android Studio, my understanding is that it will look for an AAR artifact first, then a JAR, if you do not specify otherwise. My understanding is that Maven for Android will do the reverse, looking for a JAR first, then an AAR.

So, if there's a library where the default artifact resolution is not to your liking, you can add the @ suffix and force the resolution to what you want. But, usually, the tool will do the right thing even without it.

Where having the @ suffix would be a problem is if you ask for something that does not exist. For example, compile 'com.android.support:appcompat-v7:22.1.1@jar' would not work, as that artifact is only available as an AAR -- this should fail when it tries to download the dependency.