Android Advanced --Android Studio project structure well covered Gradle script syntax dependencies and dependency management node fully resolve (d)

Disclaimer: This article is a blogger original article, follow the CC 4.0 BY copyright agreement, reproduced, please attach the original source link and this statement.

This link: https://blog.csdn.net/CrazyMo_/article/details/87895750

introduction

Previous article Android Advanced --Android Studio project structure well covered Gradle script syntax android fully resolve the remaining sub-node configuration (c) summarizes the configuration-related knowledge at Android Studio in Gradle script is the most important android node, that is the main is summarized for configuring android plug-in itself , and this one is on its own for Gradle project management bundled with a number of operational dependency, Gradle series of articles linked below:

• Android Advanced --Android Studio project structure well covered Gradle script syntax is completely resolved (a)
• Android Advanced --Android Studio project structure well covered Gradle script syntax android child node buildTypes, productFlavors, variantFilt fully resolve (b)
• Android Advanced --Android Studio project structure well covered Gradle script syntax android fully resolve the remaining sub-node configuration (c)
• Android Advanced --Android Studio project structure well covered Gradle script syntax dependencies and dependency management node fully resolve (d)

A, dependencies node

1, the basic configuration

The above internal node is configured android Android plugin introduced, and it is entirely outside the android node configuration guide Gradle compile relevant information, in which dependencies is called the dependent library configuration, when the node is not configured productFlavors functional grammar and Project in the android similar in the root directory, but after the productFlavors arranged, can be configured differently for different individual dependencies or productFlavors Build Type, at the same time selecting a corresponding Build Variant source will automatically merged into the main set.

dependencies {
    //引入文件树，这里会把libs目录下所有的jar包自动引入
    implementation fileTree(dir: 'libs', include: ['*.jar'])
    implementation 'com.android.support:appcompat-v7:26.1.0'
    implementation 'com.android.support.constraint:constraint-layout:1.1.2'
    testImplementation 'junit:junit:4.12'
    androidTestImplementation 'com.android.support.test:runner:1.0.2'
    androidTestImplementation 'com.android.support.test.espresso:espresso-core:3.0.2'
    //引入指定jar包文件，这里传递是相对路径即相当于module下的build.gradle文件的路径，如以下写法则是引入与module下的build.gradle同路径下的jar包
    implementation files('crazymo.jar')
    //引入依赖库Module方式1
	 implementation project(':libcrazymo') 
	  implementation project(path:':libcrazymo') 
}

2, dependency management and the introduction of dependence

2.1, dependent on the introduction of command

gradle3.0 in compile dependencies have been abandoned, to be replaced implementation and API , Provided by compile only alternative, APK is runtime only alternative.

• only Runtime - only package is not involved in compiling that specifies Gradle not packaged with the apk application dependencies, without relying on this dependency if the runtime library, which will help optimize apk size.

• only the compile - not only compiled packages to apk

• API - compile with 2.x version of exactly the same

• implementation - can only be used inside the module, for example, I use the library implementation relied gson and my main project depends on the library in a library, then the project will not be able to access the main method gson library, so that the benefits compilation speed We will speed up implementation of the recommended way to rely on, if you need to provide external access, so you can rely on the use of api. In addition to using a static-dependent manner, may also be used in the form of a dynamic dependency (the actual project is not recommended), the following is to use another form of dependency, although three sentences are configured with the same module and a dependent group, However, the compiler can not go wrong, because Groovy automatically selects the latest version for you and eliminate duplicate.

Note: api transitive dependencies automatically, but implementation will not automatically transfer depend, for example when using implementation-dependent third-party libraries GSON, can not be used directly in the app main module in the lib module, you need to change api to rely on.

Amazingly even while using the above statement introduces a different dynamic version, it will not happen rely conflict because Groovy in dealing with dependent encountered will automatically use the highest version of the same group and the name of the library 's.

2.2, the use of gradlew :app:dependenciessee the relationship depends app library.

In fact, this so-called dependency is a graphical representation of the various correspondence .pom file.

3, rely on conflict resolution

Gradle will put dependencies in the SDK and NDK under local.properties introduced during the compilation process in addition to the configuration script library will automatically introduce, as a native code library, which is introduced by the android plugin default

next with a simple example:

dependencies {
    implementation fileTree(include: ['*.jar'], dir: 'libs')
    androidTestImplementation('com.android.support.test.espresso:espresso-core:2.2.2', {
        exclude group: 'com.android.support', module: 'support-annotations'
    })
    implementation 'com.android.support:appcompat-v7:28.0.0'
    implementation 'com.android.support:recyclerview-v7:28.0.0'
    implementation 'com.github.hotchemi:permissionsdispatcher:2.3.0',{
        //把group为com.android.support ，module为support-v4的包排除依赖，如果不添加这段就会报以下的错误
        //exclude(group:'com.android.support',module:'support-v4')
    }
    annotationProcessor 'com.github.hotchemi:permissionsdispatcher-processor:2.3.0' //java8不能使用apt
}

在compileSdkVersion为28编译运行时会报如下的错误（从关键词可以初步判断是jar包冲突了）：

接下来说明下解决依赖冲突的常见的步骤和流程：

3.1、首先通过 ./gradlew :app:dependencies 查看app 所依赖库的关系。

3.2、分析app 依赖库的关系

3.3、解决冲突

解决冲突的理论依据是因为Groovy给我们在DependencyHandler中重载了添加依赖的方法，其中有一个是允许传递闭包的（用于配置Dependency），在闭包里我们可以实现自己的逻辑去排除冲突。

• 使用ModuleDependency的 exclude传递group和module动态移除

 implementation 'com.github.hotchemi:permissionsdispatcher:2.3.0',{
        //把group为com.android.support ，module为support-v4的包排除依赖，如果不添加这段就会报以下的错误
        exclude(group:'com.android.support',module:'support-v4')
    }

则部分依赖关系为

• 除了排除依赖，还可以指定不处理传递依赖 直接在闭包内配置 transitivie false，默认为true，这种十分不推荐因为有可能导致不能正常工作

    implementation 'com.facebook.fresco:fresco:0.14.0',{
        // 简单暴力 只依赖group为com.facebook.fresco name为fresco 版本为0.14.0的库，而其内部的内来哭不传递过来
        transitive false
    }

则编译之后库依赖关系变为

二 、configurations节点

配置项目的其他信息，可以支持很多操作，比如说配置编译的版本，自定义依赖分组的具体操作等等，甚至dependencies 内部用到的编译名称就是Groovy 默认先添加到configurations下的，当然你也可以像下面这样的添加自定义的分组，不过你得自己去实现功能。

三、SigningConfigs节点

On the Android system is the system by applicationId and identify unique signatures to distinguish apk , to security apk must be signed before running on the system, by default, for example, will go under the debug variant of use XXX / .android / debug .keystore sign , you can go to configure different signatures to different ProductFlavor

to be continued ...