Android – All com.android.support libraries must use the exact same version specification
This Android Gradle warning occurs when an application resolves two or more com.android.support libraries from different release versions. For example, the project may use AppCompat 27.1.1 while another direct or transitive dependency supplies the Design Support Library 27.1.0.
If you have encountered a notification similar to the following
“All com.android.support libraries must use the exact same version specification (mixing versions can lead to runtime crashes). Found versions 27.1.1, 27.1.0. Examples include com.android.support:animated-vector-drawable:27.1.1 and com.android.support:design:27.1.0 less… (Ctrl+F1)
There are some combinations of libraries, or tools and libraries, that are incompatible, or can lead to bugs. One such incompatibility is compiling with a version of the Android support libraries that is not the latest version (or in particular, a version lower than your targetSdkVersion).”
Why Android reports mismatched support library versions
The legacy Android Support Library was released as a coordinated set of artifacts. Libraries such as appcompat-v7, design, support-v4, cardview-v7, and animated-vector-drawable should therefore resolve to the same version.
A mismatch can be introduced directly in the app module or transitively by a third-party library. The artifact named in the warning is not necessarily declared explicitly in your Gradle file. For example, animated-vector-drawable may be brought into the project by AppCompat.
Its corresponding build.gradle file is
apply plugin: 'com.android.application'
apply plugin: 'kotlin-android'
android {
compileSdkVersion 27
...
}
dependencies {
implementation fileTree(dir: 'libs', include: ['*.jar'])
implementation"org.jetbrains.kotlin:kotlin-stdlib-jre7:$kotlin_version"
implementation 'com.android.support:appcompat-v7:27.1.1'
implementation 'com.android.support.constraint:constraint-layout:1.1.0'
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'
implementation 'com.android.support:design:27.1.0'
}
In this example, appcompat-v7 uses 27.1.1 but design uses 27.1.0. The versions of ConstraintLayout, JUnit, the test runner, and Espresso do not need to match 27.1.1 because they are separate library families.
Fix the com.android.support version mismatch
Even though the main versions are same, the sub-versions are different. As specified in the message, this may lead to runtime crashes. You need to provide the same sub-versions in the dependencies.
For example, all the implementations that you mention in the dependencies should be either 27.1.1 or all should be 27.1.0.
More precisely, align every dependency whose group begins with com.android.support. When possible, use the newer compatible version throughout the legacy project. Check the release requirements of third-party libraries before changing versions.
Correct build.gradle file is (using 27.1.1 for all dependencies)
apply plugin: 'com.android.application'
apply plugin: 'kotlin-android'
android {
compileSdkVersion 27
...
}
dependencies {
implementation fileTree(dir: 'libs', include: ['*.jar'])
implementation"org.jetbrains.kotlin:kotlin-stdlib-jre7:$kotlin_version"
implementation 'com.android.support:appcompat-v7:27.1.1'
implementation 'com.android.support.constraint:constraint-layout:1.1.0'
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'
implementation 'com.android.support:design:27.1.1'
}
or (using 27.1.0 for all dependencies)
apply plugin: 'com.android.application'
apply plugin: 'kotlin-android'
android {
compileSdkVersion 27
...
}
dependencies {
implementation fileTree(dir: 'libs', include: ['*.jar'])
implementation"org.jetbrains.kotlin:kotlin-stdlib-jre7:$kotlin_version"
implementation 'com.android.support:appcompat-v7:27.1.0'
implementation 'com.android.support.constraint:constraint-layout:1.1.0'
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'
implementation 'com.android.support:design:27.1.0'
}
Find the dependency that introduces an older support library
If all visible com.android.support declarations already use the same version, inspect the resolved dependency graph. From the project directory, run the dependencies task for the relevant build variant:
./gradlew app:dependencies --configuration debugRuntimeClasspath
On Windows Command Prompt, use gradlew.bat instead of ./gradlew. Replace app or debugRuntimeClasspath when your module or variant has a different name.
For a focused report, use dependencyInsight with the artifact named in the warning:
./gradlew app:dependencyInsight \
--configuration debugRuntimeClasspath \
--dependency com.android.support:animated-vector-drawable
The report shows which dependency requested the artifact and which version Gradle selected. You can then update the third-party library, align its compatible support dependency, or exclude an unwanted transitive dependency when the library can operate without it.
Rebuild the Android project after aligning dependencies
After editing the module-level build.gradle file, sync the project with Gradle files and rebuild it. You can also verify the change from the terminal:
./gradlew clean assembleDebug
If the warning remains, inspect every module in the project. A library module can declare a different support version even when the application module is correctly aligned. Cleaning alone does not resolve a genuine dependency mismatch; the dependency declarations or transitive dependency selection must be corrected.
AndroidX projects should not add com.android.support libraries
The com.android.support artifacts in this example belong to the legacy Support Library. Current Android projects normally use AndroidX artifacts with the androidx namespace. If the project has already migrated to AndroidX, do not solve the warning by adding another legacy support dependency. Identify the old library that still depends on com.android.support, update or replace it, and confirm that the project is consistently using AndroidX.
For an older project that has not migrated, align the legacy support versions first so that the project builds reliably. Migration to AndroidX should be handled as a separate change and tested across all application and library modules.
Common mistakes when correcting support library versions
- Changing only the dependency named first in the warning while leaving another
com.android.supportartifact on a different version. - Trying to make unrelated dependencies, such as ConstraintLayout or JUnit, use the support library version number.
- Assuming that deleting build files or invalidating caches permanently fixes a dependency graph conflict.
- Forcing every dependency to one version without checking whether a third-party library is compatible with that version.
- Mixing legacy
com.android.supportartifacts with AndroidX dependencies in a partially migrated project.
FAQs about exact Android support library versions
Do all Gradle dependencies need the same version number?
No. Only artifacts belonging to the coordinated legacy com.android.support family need to be aligned for this warning. ConstraintLayout, Kotlin, JUnit, Espresso, and other independent libraries follow their own version schemes.
Why does the warning mention a library not listed in build.gradle?
It is probably a transitive dependency included by another library. Use Gradle’s dependencies or dependencyInsight task to find the dependency path that introduced it.
Should I use support library 27.1.0 or 27.1.1?
Use one version consistently across the legacy support artifacts. For the example in this tutorial, 27.1.1 is the newer aligned choice, provided the project’s other libraries support it. A project constrained by an older dependency may temporarily need 27.1.0 throughout.
Does running Gradle clean fix the version mismatch?
No. Cleaning removes generated build output but does not change declared or transitive dependency versions. Correct the dependency graph first, then clean and rebuild to verify the result.
Support library mismatch verification checklist
- Confirm that every declared
com.android.supportartifact uses the same full version, including patch numbers. - Inspect
debugRuntimeClasspathor the applicable variant for transitive support libraries. - Check every application and library module rather than only the main app module.
- Keep unrelated library versions independent from the support library version.
- Verify that the project uses either the legacy Support Library or AndroidX consistently.
- Sync Gradle and run a clean debug build after correcting the dependency declarations.
TutorialKart.com