Android Studio How to Package Single Aar from Multiple Library Projects

Compiling one .aar library file from multiple modules

the "standard" way of doing it is to just direct use the modules in the compilation process that will generate the 1 aar.

So let's say module1 is the main part of the library, you'll have the following on it's build.gradle

apply plugin: 'com.android.library' // it's a library, generates aar

dependencies {
    // the other modules are dependencies on this one
    compile project(':module2')
    compile project(':module3')
    compile project(':module4')
}

Android Studio how to package single AAR from multiple library projects?

There is no mechanism to combine library. It's a bit complicated as you probably want to control which dependencies get merged (for instance you probably don't want to include support-v4 in there). Also you'd need to merge the resources and Android manifest.

At this time there's no way to easily hack something, unless you are sure the resources have no conflicts between the two res folders (for instance you could have strings_a.xml in one lib and strings_b.xml in the other lib). This way you can just "merge" the two res folders by copying them both into the same location (as opposed to do a merge at the android res level).

For the Manifest it'd be more complicated, but doable with some custom code.

Providing a built-in mechanism for this is very low on our priority so don't expect it anytime soon.

Create an AAR that depends on multiple AARs

From my answer here:

As far as I know you cannot include aars inside an aar. They don't have configuration files that state what dependencies they need. You can either

1. Strip the source code from the libraries you are using and compile it with your aar. This will do the job if the UI/Protocal/Infra libraries are in-house and you are the only provider.

2. Consider uploading to bintray or Maven Central Repository

Number two is more preferable since this way all your client has to do is to include a link such as compile 'com.abc.efg:version' to grab all the dependencies you configured. It is also a much better option because there are ways of dealing with version conflicts (ex. with exclude group).

Imagine if your client was using another sdk which was pulling in a different version of UI/Protocal/Infra. If your aar was given to them via the first method, they won't even be able to build the project at all due to version conflicts. However with the second version, they can simply do

compile ('com.abc.efg:version') { exclude group: 'com.companyName.ui' }

and be free from all that headache. A real life example is Facebook's SDK. It pulls in google's play-services, but people often already include that as a dependency for their project and run into problems like this.

---

Related Topics