Android library: Class file not found when "implementation project" is used for module dependency of a library

Question

I'm working in a project that has 3 modules as shown below:

Project
|
|-- Common 
|
|-- SDK
|
|-- App

Common is an Android library module that all the other modules depend on but I do not have to publish it anywhere because it contains only common code for the other modules. On the other hand SDK is another Android library project which has to be published on our internal artifactory.

App is a sample project of the SDK. I'm able to publish the SDK artifact with no problems but when I import it in a client application the compilation fails because none of the classes from the Common module are found.

For the third party dependencies that the SDK module depends on I use implementation (e.g. implementation 'com.squareup.okhttp3:okhttp:3.11.0' and all those dependencies are successfully added to the SDK POM file) and for the dependency on the Common module I use implementation project(path: ':Common').

In the client application that imports the SDK library the compiler shows the following error

Error: cannot access Foo
class file for com.acme.Foo not found

(Foo is a class in the Common module)

Why when I import the SDK none of the classes from the Common module are found? What I expect is the compiler to merge the two modules into a single one. Has anyone an idea about how I can solve this problem?

(I know a solution is to publish Common on the artifactory but I don't want to do that since this is only internal common code).

Answer 1

Repleace implementation project(path: ':Common') by api project(path: ':Common') About difference between api and implementation you can check this article.

Answer 2

This is expected behaviour for gradle modules; as you surmised, publishing each as a separate artefact (and listing the dependencies in the pom file) is the only supported usage.

There is a plugin that may do what you need at https://github.com/adwiv/android-fat-aar , but it's no longer maintained so your mileage may vary. Alternatively, you may achieve similar results by updating your SDK sourceSets to point directly at the common module sources, and remove the gradle dependency entirely. Can't find a good link for this, but it should be possible. This does remove all the built-in handling of modules, but may better match how you're using the module.