Gradle

查看项目的依赖关系树

gradlew androidDependencies

Android library dependency

Android支持将库打包成aar文件。当指定project依赖一个library时，可以指定@aar，如下：

    dependencies {
        compile 'com.android.support:appcompat-v7:25.0.1' //会递归解析所有的外部依赖
        //or
        compile 'com.android.support:appcompat-v7:25.0.1@aar' //不会解析v7的其他dependencies,仅包含本身的代码和资源
    }

如果指定为@aar方式引用v7包，那么project不会去解析v7本身自己的其他外部依赖。例如v7还依赖v4包，在使用@aar这种方式下，在打包的时候v4包不会被打到apk中，同理其他v7包依赖的库都不会被打包。所以可能会造成编译时错误，或者运行时的ClassNotFoundException。具体在这两种方式下的依赖关系树可以使用上面的gradle命令去查看。
为此，如果我们需要android gradle为我们解析所有的依赖的话，就不能使用@aar这种方式。在某些情况下，@aar方式比较有用：A和B都依赖C , project又依赖于A和B，C。这时我们对A和B的引用就可以指定为@aar方式，因为我们主工程自己已经依赖了C。

依赖某个库，但排除其中的某个部分

    compile('com.android.support:appcompat-v7:25.0.1'){ //依赖v7
            exclude group:'com.android.support', module:'support-v4'  //v7依赖v4，这里我们排除这个依赖
    }

强制依赖某个版本的库

    configurations.all {
            resolutionStrategy {
                force 'com.android.support:appcompat-v7:24.2.1'
          }
      }

Android Gradle Plugin Scope

3.0.0之前的依赖方式

• compile

Gradle adds the dependency to the compilation classpath and to the APK.

• apk

Gradle adds the dependency to the APK only (it is not added to the compilation classpath).Note: You can use apk only for JAR binary dependencies. It does not support library modules or AAR binary dependencies.

• provided

Gradle adds the dependency to the compilation classpath only (it is not added to the APK). This is useful when you're creating an Android library module and you need the dependency during compilation, but it's optional to have present at runtime. That is, if you use this configuration, then your library module must include a runtime condition to check whether the dependency is available, and then gracefully change its behavior so it can still function if it's not provided. This helps reduce the size of the final APK by not adding transient dependencies that aren't critical.You might also use this in an Android app module when your dependency is a JAR file that you need at compile-time and that you can safely assume is already available at runtime (and therefore you don't want to copy it into your APK). Or perhaps you want to compile against the JAR specified with the provided configuration, but use the apk configuration to package a different JAR into the APK, which includes the same APIs you need at runtime.

If you're creating an Android app module, you cannot use provided for AAR dependencies, only for JARs. In an Android library module, you can use it for both JARs and AARs.

新版本3.0.0的依赖类型

New configuration	Deprecated configuration	Behavior
implementation	compile	When your module configures an implementation dependency, it's letting Gradle know that the module does not want to leak the dependency to other modules at compile time. That is, the dependency is available to other modules only at runtime.Using this dependency configuration instead of api or compile can result in significant build time improvements because it reduces the amount of projects that the build system needs to recompile. For example, if an implementation dependency changes its API, Gradle recompiles only that dependency and the modules that directly depend on it. Most app and test modules should use this configuration.
api	compile	When a module includes an api dependency, it's letting Gradle know that the module wants to transitively export that dependency to other modules, so that it's available to them at both runtime and compile time. This configuration behaves just like compile (which is now deprecated), and you should typically use this only in library modules. That's because, if an api dependency changes its external API, Gradle recompiles all modules that have access to that dependency at compile time. So, having a large number of api dependencies can significantly increase build times. Unless you want to expose a dependency's API to a separate test module, app modules should instead use implementation dependencies.
compileOnly	provided	Gradle adds the dependency to the compilation classpath only (it is not added to the build output). This is useful when you're creating an Android library module and you need the dependency during compilation, but it's optional to have present at runtime. That is, if you use this configuration, then your library module must include a runtime condition to check whether the dependency is available, and then gracefully change its behavior so it can still function if it's not provided. This helps reduce the size of the final APK by not adding transient dependencies that aren't critical. This configuration behaves just like provided (which is now deprecated).
runtimeOnly	apk	Gradle adds the dependency to the build output only, for use during runtime. That is, it is not added to the compile classpath. This configuration behaves just like apk (which is now deprecated).