Determine if we could benefit from api dependencies in gradle

[fuzzyweapon]

this is a decent article for accompanying official documentation - https://jeroenmols.com/blog/2017/06/14/androidstudio3/

here is official documentation - https://docs.gradle.org/current/userguide/java_library_plugin.html#sec:java_library_separation

What essentially is happening when a module (A) declares an api dependency on another module (B) is that module A is exposing B as a part of its api in terms of compilation requirements (when there's a change in one, the other will need to be compiled). When a different module C depends on A, B will be transitively exposed to C. B will end up automatically on C's classpath as it's a part of A's. B version will be baked into A, and therefore, transitively baked into B's. For libraries or frameworks, say that module B is a specific version of some other library. Consumers who are writing module C decide to start using parts of module B directly, not realizing it. It's all through more modules too that they've written. Then, when module A updates, it updates module B too. Consumers could be unlikely to update module A+B bc they became dependent on features of B that A never used and now all of that has changed.

Making the dependency between A and B an implementation dependency would force the consumer to take on the responsibility of deviating and more of B. There are a lot more benefits than what's demonstrated by shallowly walking through how this affects classpaths.