[Android] Add support for local AAR in libraries

Describe the Feature

I faced multiple times a situation when inside the library I had to use local AAR. It’s not a super common case but I was struggling with it twice lately and wasn’t able to figure out an easy solution.

Problem description

The issue can be established when we want to use some AAR files in our library as a developer. For instance, I would like to link the local glide file that I wanna use in my library.

I’ve added the following code to my library build.gradle

dependencies {
  implementation files('libs/glide-4.14.2.aar')
}

and now while I’m trying to build an app in release mode I’m getting this error:

Direct local .aar file dependencies are not supported when building an AAR. 
The resulting AAR would be broken because the classes and Android resources from any local .aar file dependencies would not be packaged in the resulting AAR. 
Previous versions of the Android Gradle Plugin produce broken AARs in this case too (despite not throwing this error). 
The following direct local .aar file dependencies of the :react-native-test-aars project caused this error: ~/test-aars/android/libs/glide-4.14.2.aar

Solution 1

To pass that I can simply change implementation to compileOnly in build.gradle of library

dependencies {
  compileOnly files('libs/glide-4.14.2.aar')
}

and then in the final app build.gradle add .aar from the library

dependencies {
  implementation files('path/to/library/android/libs/glide-4.14.2.aar')
}

Solution 2

Use a library dedicated to this purpose like Fat AAR Cli added support for this tool by merging this change: https://github.com/react-native-community/cli/pull/1430

Drawbacks

Both of those solutions have some pitfalls, the most significant are:

• From a library developer’s perspective, you cannot control the linking of AAR.
• From a library user’s perspective, you have to do additional steps to use the library which most likely will increase the amount of opened issues.

Possible Implementations

I would love to have a dedicated field inside react-native-config inside a library that will allow developers to define a path to AAR. This path can be used inside native_modules.gradle to link AARs in the user app.

module.exports = {
  dependency: {
    platforms: {
      // Android specific properties go here
      android: {
          localAars: ["./libs/glide-4.14.2.aar"]
      },
    },
  },
};

Playground

I’ve prepared a simple playground where you can reproduce the problem and see Solution 1

https://github.com/MateWW/react-native-aar-repro/commits/master

Known issues

• How to handle duplicated libraries?
• How to handle multiple similar packages in different versions

[cortinico]

Those sound like a better solution however it seems like each of those solutions needs work on the application side. Is there any solution that can be fully handled on the library side?

As a library decides to don’t publish on conventional repositories (NPM, Maven Central, etc.) you’re effectively adding a cost to users. What you’re effectively proposing is to move this costs inside the CLI, which would make sense if this would be a broad use case. Sadly, I believe it’s an edge case, and we should not support it out of the box as it’s not worth the maintenance cost.

Besides that, I’m not a Gradle expert could you share some insight into why this is generally a bad solution?

Because you’re missing a lot of other artifacts that are necessary for the build to work well, beside the .aar file:

1. You’re not shipping the .module file which means that the build won’t be able to know if this is a debug/release library.
2. You’re not shipping the -sources.jar file which means that users won’t be able to navigate the code.
3. You’re not shipping the -javadoc.jar file which means that users won’t have intellisense in their IDE when developing with your library.
4. You’re not shipping hashes and signatures, making it impossible for the build to auto-detect discrepancies in the artifacts that are pulled in.

So it’s not just the .aar file, and IMHO the library publisher should do the effort to properly publish it somewhere so it can easily be consumed.

[MateWW]

Thanks for such an exhaustive explanation. I wasn’t aware of those details now it makes a lot more sense to me. I think we are good to close this thread