Implementation Vs Api in Android Gradle plugin 3.0
While using Android Gradle plugin 3.0 in your project, you might have noticed that
compile keyword has been now deprecated in favour of
api. Let’s understand both of them with an example.
Sample application(Kotlin) can be found here.
Let us assume a project with four library modules.
For which the dependency tree looks like this:
All Library modules contain a simple class file.
From above Class files, it is observed that LibraryA and LibraryB is dependent on LibraryC and LibraryD respectively. Therefore, these dependencies needs to be added to build.gradle files.
Compile (2.0) or Api (3.0):
api keyword is exactly the same as the old
compile keyword. Thus, if all
compile is replaced with
api, it works just fine. Now, let’s add dependency of LibraryD using api keyword in LibraryB.
. . . .
api project(path: ':libraryD')
Similarly, LibraryB is added to the app module.
. . . .
api project(path: ':libraryB')
Now, both LibraryB and LibraryD can be accessed from the app module. In sample App, both libraries are accessed like this:
It’s time to find out how
implementation is different than
api. Again back to the example, this time let’s import LibraryC to LibraryA using
. . . .
implementation project(path: ':libraryC')
Same for App module.
. . . .
implementation project(path: ':libraryA')
Now, if we try to access LibraryC from app module, Android studio will throw an error.
Which implies that LibraryC can’t be accessed directly from App module if we use
implementation instead of
api. So, what is the benefit of this?
Implementation vs api:
In the first scenario, LibraryD is compiled by using
api. If any change is implemented inside LibraryD, gradle needs to recompile LibraryD, LibraryB and all other modules which import LibraryB as any other module might use implementation of LibraryD.
But in second scenario, if any implementation in LibraryC is changed, Gradle just needs to recompile LibraryC and LibraryA as any other class which does not import LibraryC directly cannot use any implementation of it.
If you are working on a project with lots of modules,(we have heard some crazy build time story in this Fragmented Podcast episode) this strategy can speed up the build process significantly. I tried this on our sample project and there was a slight improvement of few seconds. Here are the build reports for all scenarios.
Change in LibraryD:
Change in LibraryC:
Just replace all
implementationand try to build the project. If it builds successfully, well and good. otherwise look for any leaking dependency you might be using and import those libraries using
If you liked this article please click the 💚 below to recommend. I would love to hear your thoughts in the comment section or at Twitter. Thanks a lot !
Check out all the top articles at mindorks.com