1

I am developing my own SDK, which in turn depends on some 3rd party SDKS. For example - OkHttp.

Should I add OkHttp to my build.gradle, or let the users of my SDK include that? In this scenario, they will probably "anyway" use it, so its safe to say they already have it.

Another point to add - not all paths of my SDK needs "OkHttp", so, in theory, some user of my SDK could use those parts only, and have not OkHttp on his APK.

Another thing I am contemplating: If I do embed OkHttp on by build.gradle - how can users of my SDK use that OkHttp library, instead of consuming another replica?

elcuco
  • 8,948
  • 9
  • 47
  • 69
  • I have built a library and I came across the same question. Personally I believe it's better to have the consuming project adding the libraries since you give better control over whats in the gradle to the consuming project. On the down side having the main project importing the libraries there might be a problem with Android SDK's since your library might hold references to an older version of X library(methods for example) and it might not be compatible with other library the consuming project already has – Ricardo Jul 23 '19 at 07:24
  • No, you'd better **not** package a common library into your shippable library, because the one packaged inside your library will cause unnecessary package duplication errors. And as you said in question, for some customers, they don't really need that library. They probably will complain on the library / apk size impact (although they can mitigate the size by applying code shrinking, but not all customers are aware of this). – shizhen Jul 23 '19 at 07:37
  • If you really want to package the common libraries into your library, then you'd better flat the packages/classes into different packages (using **ProGuard** tool can achieve this) to avoid package duplicate errors. E.g. ``` -flattenpackagehierarchy com.new.package.name ``` – shizhen Jul 23 '19 at 07:37
  • Another point is the library versioning problem, consider the case that you package a lower version of the common library, but customer need a higher version of that library. Then you will bring some unnecessary trouble to your customers. – shizhen Jul 23 '19 at 07:37

4 Answers4

5

Should I add OkHttp to my build.gradle, or let the users of my SDK include that?

Adding the dependencies in build.gradle doesn't mean packaging the dependencies inside the aar file. The aar file doesn't contain the transitive dependencies and doesn't have a pom file which describes the dependencies used by the library.

Uploading the artifact in a maven repository you will have your aar and a pom file which will contains the dependencies list.
In this way gradle will automatically download all the dependencies tree and you can configure gradle to exclude same libraries.

Gabriele Mariotti
  • 320,139
  • 94
  • 887
  • 841
2

Use implementation and package it - the consumer can still exclude it.

One cannot depend on something and then not package it; this won't build.

In the application package, it can/must only exists once ...so what's the point?

Martin Zeitler
  • 1
  • 19
  • 155
  • 216
0

I will answer your questions in a reverse order

Another thing I am contemplating: If I do embed OkHttp on by build.gradle - how can users of my SDK use that OkHttp library, instead of consuming another replica?

How Gradle build system works is suppose, In my project I use your library and I'm using v2 of OkHttp and your library is using V1 of OkHttp, then the gradle will automatically use the latest version. You can read about it here

Another point to add - not all paths of my SDK needs "OkHttp", so, in theory, some user of my SDK could use those parts only, and have not OkHttp on his APK.

In my project I use your library and it uses OkHttp, whereas I don't use it in my project also, I'm not using the part of your library where you are using OkHttp but still my APK will include OKHttp in it. This can be avoided either by splitting your library into two separate libraries or me using proguard in my Project.

Should I add OkHttp to my build.gradle, or let the users of my SDK include that? In this scenario, they will probably "anyway" use it, so its safe to say they already have it.

You should not bundle it in your library you just use implementation and let the user of your library decide if he wants to exclude it or not.

Saran Sankaran
  • 2,335
  • 2
  • 19
  • 34
-1

You need knows about api and implementation in the gradle The link will be helpful

Api: Role: Declaring ,API, dependencies

Consumable? no

Resolveable? no

Description: This is where you should declare dependencies which are transitively exported to consumers, for compile.

Implemetation: Role: Declaring, implementation, dependencies

Consumable? no

Resolveable? no

Description: This is where you should declare dependencies which are purely internal and not meant to be exposed to consumers.

Alireza Tizfahm Fard
  • 543
  • 3
  • 16
  • probably a short description would help, rather than just posting the link – Saran Sankaran Jul 23 '19 at 07:20
  • Actually not - he will just be repeating the text of that document (which I have read several times, and yet did not fully comprehend). However - a short TLDR for my use case would be great. – elcuco Jul 23 '19 at 07:23