Gradle Implementation vs API configuration

注:

能夠把 Implementation理解爲java類的private, 使用Implementation則外部依賴本庫的代碼引用不到本庫Implementation的代碼, 也就是下降依賴樹的層級, 這樣就能夠避免外部代碼編譯時候, 致使本庫依賴的庫的代碼發生編譯. 從而下降編譯時間

 

I think this topic needs a bit more coverage because maybe is not so immediate for every developer.

Gradle compile keyword has been deprecated in favor of the new api and implementationkeywords.

I will not explain api, because it's the same thing as using the old compile, so if you replace all your compile with api everything will works as always.

To understand the implementation keyword we need an example.

EXAMPLE

We have this library called MyLibrary where internally we are using another library called InternalLibrary. Something like this:

//internal library module
public class InternalLibrary {
    public static String giveMeAString(){
        return "hello";
    }
}

//my library module
public class MyLibrary {
    public String myString(){
        return InternalLibrary.giveMeAString();
    }
}

The build.gradle dependencies of MyLibrary its like this:

dependencies {
    api project(':InternalLibrary')
}

Now in your code you want to use MyLibrary so you should have a build.gradle with this dependency

dependencies {
    api project(':MyLibrary')
}

In your application code, with the api keyword (or using the old compile) you can access both MyLibrary and InternalLibrary.

//so you can access the library (as it should)
MyLibrary myLib = new MyLibrary();
System.out.println(myLib.myString());

//but you can access the internal library too (and you shouldn't)
System.out.println(InternalLibrary.giveMeAString());

In this way you are potentially "leaking" the internal implementation of something that you shouldn't use because it's not directly imported by you.

To prevent this, Gradle has created the new implementation keyword, so now if you switch api to implementation in your MyLibrary

dependencies {
    implementation project(':InternalLibrary')
}

And in your app build.gradle

dependencies {
    implementation project(':MyLibrary')
}

you won't be able to call InternalLibrary.giveMeAString() in your app code anymore. While if MyLibrary uses the api keyword to import InternalLibrary, in your app you will be able to call InternalLibrary.giveMeAString() without problems, independently if you use api or implementation to add MyLibrary to your app.

Using this sort of boxing strategy the Android Gradle plugin knows that if you edit something in InternalLibrary it will trigger the recompilation of MyLibrary only. It will not trigger the recompilation of your entire app because you don't have access to InternalLibrary. This mechanism when you have a lot of nested dependencies can speed-up the build a lot.(Watch the video linked at the end for a full understanding of this)

CONCLUSIONS

• When you switch to the new Android Gradle plugin 3.X.X, you should replace all your compilewith the implementation keyword (1*). Then try to compile and test your app. If everything it's ok leave the code as is, if you have problems you probably have something wrong with your dependencies or you used something that now is private and not more accessible. Suggestion by Android Gradle plugin engineer Jerome Dochez (1)*)

• If you are a library mantainer you should use api for every dependency which is needed for the public API of your library, while use implementation for test dependencies or dependencies which must not be used by the final users.

Useful article Showcasing the difference between implementation and api

REFERENCES (This is the same video splitted up for time saving)

Google I/O 2017 - How speed up Gradle builds (FULL VIDEO)

Google I/O 2017 - How speed up Gradle builds (NEW GRADLE PLUGIN 3.0.0 PART ONLY)

Google I/O 2017 - How speed up Gradle builds (reference to 1*)

Android documentation