The article | Ashesh Bharadwaj

Translation | ChengXiang ink film

Authorized Chengxiang Ink to translate, edit and publish

In Android Studio, the Gradle build process is largely abstract to developers. As a new Android developer, we usually first encounter Gradle by adding a remote dependency to the build. Gradle file.

Let’s look at how to read Gradle dependency trees and solve problems related to dependencies.

This is a project I manage at work and I want to upgrade targetVersion to 27. I also updated the new version of appCompat-v7 support library to the latest dependency version 27.0.2 in Gradle. After the changes are made and the project is synchronized, the following error appears in build.gradle:

This error means THAT I must use the exact same version of the support library. However, I only use this support library in my build.gradle.

What exactly does this Android Studio hint mean?

The error prompt, mention to com. The android. Support: animated – vector – drawable: 27.0.2 or com. Android. Support – v4: where is 21.0.3 referenced again?

If you only have a direct dependency library for your application, just specify the dependency in build.gradle. This is very clear. However, this is not the case, and these dependencies may go on to have their own dependencies, which is called dependency passing. Gradle needs to include all direct and indirect dependencies in your application.

The previous error message from Android Studio is the result of transitive dependencies that we are discussing now.

Gradle must resolve all of these dependencies. Which libraries are used for inclusion? What happens if two different libraries have different versions of a dependency on the same library?

To see the Gradle dependency tree (how Gradle resolves dependencies), go to the Terminal TAB at the bottom of Android Studio and type the following command:

gradlew app:dependencies
Copy the code

This displays the dependency resolution tree for all build variants. We can add an identifier to the command above to see the configuration of a particular build variant. For example — Configuration releaseCompileClasspath will show us the dependency tree for the Release variant.

For building variants, I recommend reading the official documentation:

https://developer.android.com/studio/build/build-variants.html

This is the output of the above command:

releaseCompileClasspath - Resolved configuration for compilation for variant: Release + - com. Android. Databinding: library: 1.3.1 | + -- -- -- com. Android. Support: support - v4:21.0.3 | | \ -- -- -- Com. Android. Support: support - annotations: 21.0.3 - > 27.0.2 | \ - com android. Databinding: baseLibrary: 2.3.0 dev - > 3.0.1 + - com. Android. Databinding: baseLibrary: 3.0.1 + - com. Android. The databinding: adapters: 1.3.1 | + -- -- -- Com. Android. Databinding: library: 1.3 - > 1.3.1 (*) | \ - com android. Databinding: baseLibrary: 2.3.0 dev - > 3.0.1 + - Com. Android. Support. The constraint, the constraint - layout: 1.0.2 | \ -- -- -- Com. Android. Support. The constraint, the constraint - layout - solver: 1.0.2 \ - com android. Support: appcompat - v7:27.0.2 + - Com. Android. Support: support - annotations: 27.0.2 + - com. Android. Support: support - core - utils: 27.0.2 | + -- -- -- Com. Android. Support: support - annotations: 27.0.2 | \ - com android. Support: support - compat: 27.0.2 | + -- -- -- Com. Android. Support: support - annotations: 27.0.2 | \ - android arch. Lifecycle: the runtime: 1.0.3 | + -- -- -- Android. Arch. Lifecycle: common: 1.0.3 | \ - android arch. Core: common: 1.0.0 + - Com. Android. Support: support - fragments: 27.0.2 | + -- -- -- com. Android. Support: support - compat: 27.0.2 | + -- -- -- (*) Com. Android. Support: support - core - UI: 27.0.2 | | + -- -- -- com. Android. Support: support - annotations: 27.0.2 | | \ -- -- -- Com. Android. Support: support - compat: 27.0.2 (*) | + -- -- -- com. Android. Support: support - core - utils: 27.0.2 | \ - (*) Com. Android. Support: support - annotations: 27.0.2 + - com. Android. Support: support vector - drawable: 27.0.2 | + -- -- -- Com. Android. Support: support - annotations: 27.0.2 | \ - com android. Support: support - compat: 27.0.2 \ - (*) Com. Android. Support: animated - vector - drawable: 27.0.2 + - com. Android. Support: support vector - drawable: 27.0.2 \ - (*) Com. Android. Support: support - core - UI: 27.0.2 (*)Copy the code

It is important to understand the format of Gradle dependency trees before looking up the purpose.

Let’s start with the following three symbols, which are intended for formatting purposes only:

  • +- - -It was the beginning of the dependency branch library.
  • |Identifies the dependency in the previous dependency library, showing the library it depends on.
  • \ -- -- --Is the end of the dependency library.

The asterisk (*) at the end of the dependency library means that further dependencies for that library are not shown because they are already listed in some other subdependency tree.

The most important identifier is ->.

If Gradle finds that multiple dependency libraries all depend on the same library but in different versions, it must make a choice. After all, it doesn’t make sense to include different versions of the same library. In this case, Gradle defaults to the latest version of the library.

Such as:

| + -- com. Android. Support: support - v4:21.0.3 | | \ -- com android. Support: support - annotations: 21.0.3 - > 27.0.2Copy the code

Above, Gradle tells me that, in the support-V4 :21.0.3 dependency tree, support-Annotations :21.0.3 depend on the newer version, support-Annotations :27.0.2, So 27.0.2 will be used.

Now that we know how to read the Gradle dependency resolution tree, we return to the core issue of this article: all com.Android.support libraries must use exactly the same version.

All support libraries belong to the following group com.android.support. As we see in Gradle dependency tree, com. Android. Support: support – v4:21.0.3 21.0.3 and unparsed is the only version to the latest version of the support library 27.0.2, this is the cause of conflict.

How to solve this problem? There are several ways to do this:

ResolutionStrategy **

Enforce Gradle version by ResolutionStrategy.

android {
        configurations.all {
        // To resolve the conflict forCom. Android. Databinding: library: 1.3.1 / / the dependency on the support - v4:21.0.3 resolutionStrategy. The force'com. Android. Support: support - v4:27.0.2'}}Copy the code

The details of the ResolutionStrategy are described in the official documentation:

https://docs.gradle.org/current/dsl/org.gradle.api.artifacts.ResolutionStrategy.html

2. Specify the version in build.gradle

To be in the build. Gradle, explicitly specify added is com. The android. Support: support – v4:27.0.2. This will let Gradle override the older version.

dependencies {
    implementation fileTree(dir: 'libs', include: ['*.jar'])
    implementation 'com. Android. Support. The constraint, the constraint - layout: 1.0.2'
    // To resolve the conflict forCom. Android. Databinding: library: 1.3.1 / / the dependency on the support - v4:21.0.3 implementation'com. Android. Support: support - v4:27.0.2'
    implementation 'com. Android. Support: appcompat - v7:27.0.2'
}
Copy the code

It seems more natural to me to explicitly add dependencies in build.gradle and leave comments. This comment will alert me to it when we update the library again to check if it still needs to be added explicitly.

Once the project is added and synchronized, the error text disappears. Now, if we run the dependency command again, we see support-V4:21.0.3 resolved -> 27.0.2.

Gradle handles dependencies correctly most of the time. Knowing Gradle’s dependencies, I think we should have a better idea of how to solve this problem.

I hope this article gives us a better understanding of Gradle dependency trees and solutions.

Today, I reply to “grow up” in the background of the official account, and I will get some learning materials sorted out by me. I can also reply to “add group”, so that we can learn and progress together.

The original link: https://proandroiddev.com/android-gradle-and-the-curious-case-of-invisible-dependency-7f1bcc8bb79e

Recommended reading:

  • Comics: Programmer, can you “manage” your product manager?
  • Official new Kotlin extension library KTX
  • Lack of critical thinking may be limiting your career as a programmer
  • Android development, Emoji headache?
  • Android signatures and multi-channel packaging solutions | VasDolly