CODEWITHSUNDEEP
androidandroid-gradle-pluginandroid-library
azza50
azza50

Reputation: 82

Android - Creating Plugin Libraries that depends on a Core Library

I am looking into a way of creating a dependency library structure for my current project, where I create a core library dependency then use addition dependencies to add functionality automatically, however, I am aiming for a solution where my additional dependencies to not require in the inclusion of the Core library. Class objects within the additional dependencies with have access and use code that is located within the Core library (for example, an abstract class or interface).

I have seen an example of this with Ironsource, an advertising platform, if the developer wanted to, for example, add facebook adverts to their project, they would need to add the following dependencies in Gradle.

implementation 'com.ironsource.sdk:mediationsdk:6.9.1@jar' 
implementation 'com.ironsource.adapters:facebookadapter:4.3.4@jar'

However, if they remove the main mediation SDK, the facebookadapter SDK no longer works as it is missing a class it is using within the mediation SDK. but instead returns an Unresolved Superclass error, as the superclass is only found in the mediationsdk dependancy.

My question is how did they do this? How did they use code in the facebookadapter(additional) that is only available in the mediationsdk(Core) library? and how can I replicate this dependancy style?

I have tried having both my core and additional libraries have the same package information but to no avail.

Upvotes: 0

Views: 163

Answers (1)

getKonstantin
getKonstantin

Reputation: 1250

As far as I got your question correctly, you are interested in how Library B can use a class that shipped by Library A without including that explicitly. That is basically a difference between implementation and api in gradle dependencies specification, the first one does not include the dependencies transitively into your build. So when you develop Library B, and have Library A attached as implementation, it's not gonna be included into build artifacts, so consumer should provide it explicitly.

A common example of this approach is Retrofit or OkHttp, many 3rd party SDKs use them internally, but they don't want to ship them as built-in dependencies, so they do ask consumers to provide them.

So most likely, they just use implementation to locally resolve the ABI, but don't ship it inside of each com.ironsource.adapters:* module because it will be shipped many times then.

More information about different compile options: https://developer.android.com/studio/build/dependencies#dependency_configurations

Upvotes: 1

Related Questions