Can we build an AAR with a dependency of v3 without any risk of conflict with the client apps dependency of v2?

Question

We want to produce an Android Archive Library (AAR) and distribute to our clients. In this Android lib we are using some third party dependencies, and we want to protect them from any version conflicts. We also do not want auto-updating of a dependency to the latest version.

For example this scenario: We are using (and needing) version 3 of a dependency and the client version 2 of the same dependency - and for some reason these versions are not compliant and our client is unable to update to version 3. Or this: The client is also using an AAR from another provider that in turn uses the dependency with version 2 - and updating this to version 3 would break this other AAR. To demand every part of the software chain to be compatible with the same dependency version is not always possible at all times.

When using an ordinary JAR, this scenario can easily be avoided by using ShadowJar to include and do relocating of the dependencies at the build step. But for an AAR the best method I've found is to create a custom gradle ShadowJar task according: https://github.com/johnrengelman/shadow/issues/183 and do the relocating step before compiling the actual AAR. But this make your app source files need to import the relocated dependencies directly, i.e: import relocated.org.com.dependency.

However this is not an optimal solution to a, what we thought, common problem scenario with AAR:s as described above. We would like the relocating step to happen after the development stage, when building the AAR. I have not found a satisfiable way to do this. Is there really not a better solution to this?

Hap

Answer 1

This is close to what obfuscation does, re-locating (or re-naming but it's kinda same) and re-linking the packages so dependencies aren't broken. I'd probably would try to use obfuscation properly enabled for the version 3 library your using (excluding every other thing that doesn't want obfuscation). That way your development are using the version 3 as is without having to deal with the re-location and your client is getting the AAR with the re-location. It's hard for me to tell how to make this happen as I've only used obfuscation when building APKs (not AARs) but I think it's possible.

A bonus thing to do is to also separate this build logic from the development build logic, probably something like creating another gradle module and using module dependency to grab the built AAR created by development and then do the steps of re-locating the packages within the AAR and the version 3 library.

Calces

Thank you for your input. What I understand you’re describing exactly the way we would like it work, that the version 3 is obfuscated at the build stage of the AAR. But this seems not to be possible, with Proguard enabled only the app code is obfuscated while the library is kept and defined in the AAR .pom file. However if using ShadowJar as described in the question, the relocation can take place and Proguard is then properly obfuscating the library as well. – Hap

Regarding your bonus thing, I’m not sure how to accomplish the relocating of packages within a completed AAR as ShadowJar will only work on JARs. But I would be happy to see a working example. – Hap

@Hap Hi, could you solve the problem? If so, how? Thank you for the question – Jassy

@ErcanAkkök Hi, sorry not really. We have refactored the code needing the sensitive dependencies to a JAR, relocating it with ShadowJar as described above. If you don't really need it I can't recommend it though as it is a bit cumbersome. And if you find a better way, please let me know. – Hap