Gradle dependencies difference between compile, ap

Question

Gradle dependencies difference between.

 compile
 apk project 
 compile project
 provided project
 implementation

My questions are

What's the difference between compile ,apk project, compile project,provided project here?

Answer 1

There's two separate things to discuss here: Dependency Configurations and Dependency Sources.

Dependency Configurations

Configurations help define the transitivity of a dependency, which in turn removes the pain of having to discover and specify the libraries your own project/library requires, including them automatically. This notion of configurations in gradle is very similar to that of Maven's scopes:

1. compile: Compile dependencies are available in all classpaths of a project. Furthermore, those dependencies are propagated to dependent projects. A compile-time dependency is generally required at runtime.
2. apk: Defines a runtime dependency. A dependency with this scope will not be required at compile time, but it will be for execution. This means that you can save time while compiling and still have the dependency available when your project actually runs. This is a good example of when to use an apk dependency.
3. provided: It means that this dependency is available on the runtime environment. As a consequence, this scope is only available on the compilation and test classpath, and is not transitive. It is not supported on Android projects, though you can workaround it by defining your own configuration as discussed here.

There are more configurations that you can encounter on Android, such as testCompile, which allows you to specify a compile-time dependency that will only be used for testing, say you want to use junit in your tests, then you would do as follows:

testCompile 'junit:junit:4.12'

Dependency Source

Once you understand the configurations available for you, you need to specify an actual dependency. Dependencies might be internal or external, you may rely on another library you are working on, as well as on publicly available libraries. Here's where the project keyword comes in, allowing you to specify a dependency to an internal module or library. By defining a dependency as compile project, you are adding that module or library as a transitive dependency to your project.

Assume you have a project messages with three modules (producer, consumer and shared), the project structure would look as follows:

messages/
    build.gradle
    settings.gradle
    consumer/
        build.gradle
    producer/
        build.gradle
    shared/
        build.gradle

Now assume that both consumer and producer store messages in json format and that you want to use google-gson for that purpose. Assume that both projects have some common source code that they depend on, your shared module. consumer's build.gradle could then define the following dependencies:

dependencies {
   // Internal dependency to project shared
   compile project (':shared')

   // External dependency to publicly available library, 
   // through public repositories such as jcenter() or mavencentral()
   compile 'com.google.code.gson:gson:1.7.2'
}

To sum up, it is the combination of both configurations and sources that enables you to declare dependencies as compile, compile project, apk project and more!