background
Complex project dependencies have become a nightmare for Android projects. Inconsistency in version numbers often leads to some dependency conflicts. Hence this article.
Phenomenon
When rebuilding an Android project or building a release package, errors may occur:
(1) Inconsistent compilation of the kotlin version leads to errors
compiled with an incompatible version of Kotlin.
The binary version of its metadata is 1.8.0, expected version is 1.6.0.
Looking closely at the English prompts, it means that during the project compilation process, the compiled version and the kotlin version used are inconsistent with the expected version, resulting in failure to compile.
Wouldn't that be easy to handle? The solutions are roughly as follows:
(1) Modify the gradle version so that the kotlin version it uses is consistent with the expected kotlin version.
(2) Upgrade dependencies to make them consistent with the compiled version
(3) Forcefully unify the kotlin version of the project
. Each of the above methods has its own advantages and disadvantages.
For (1), the gradle version of some projects does not need to be upgraded. Internally, there are many connections with some SDK dependencies and configuration file statements involved in the project. Externally, it involves the compilation of some third-party automatic packaging tools. The environment will also have many connections, so upgrading will bring a lot of time and labor costs. The advantage is that the overall compilation environment has been updated, and the speed, quality, and maintainability have been improved.
For (2), upgrading dependencies has an impact mainly within the project. Due to design flaws of some third-party SDKs, major version upgrades often lead to API abandonment or even loss, which also consumes a lot of labor costs.
For (3), the problem can be solved quickly in the short term. But be careful, there are version differences in each dependency! However, generally for this kind of official version, the maintainability is extremely high, so even if the version span is not large, the compatibility is excellent.
This article will use (3) method to solve problems caused by conflicts.
By sorting out the error logs, we can summarize the following conflicts:
kotlin-stdlib
annotation-jvm
androidx.annotation
kotlin-stdlib-jdk7
kotlin-stdlib-jdk8
Therefore, it is necessary to forcefully specify the version of the above dependencies here.
First, you can see the dependencies of the project by clicking gradle–>app–>help->dependencies, and then get the unified version number.
There may be many dependencies, so it is recommended to copy them and compare them.
In this actual combat, version unification was achieved by modifying the project root build.gradle. The core code is as follows:
/*强制统一版本号*/
subprojects {
configurations.all {
resolutionStrategy {
force "org.jetbrains.kotlin:kotlin-stdlib-jdk8:$kotlin_version"
force "org.jetbrains.kotlin:kotlin-stdlib-jdk7:$kotlin_version"
force "androidx.annotation:annotation:1.2.0"
force "androidx.annotation:annotation-jvm:1.6.0"
force "org.jetbrains.kotlin:kotlin-stdlib:$kotlin_version"
}
}
}
The meaning of the above code is to specify the version number of the specific dependencies related to kotlin. The actual dependencies to be specified depend on the error reported and cannot be generalized.
Finally, rebuild and open the release package successfully, then the modification is considered successful.
that’a all-------------------------------------------------------------------------------------