Fix Android Support Library Version Mismatch Errors

This warning often appears after opening an old Android project that looked healthy on its original developer’s machine. Your own dependency declarations may even look consistent. The mismatch is usually hiding one level deeper, inside a library that pulls an older Support Library artifact transitively.

What the message is really reporting

All com.android.support libraries must use the exact same version
specification (mixing versions can lead to runtime crashes).
Found versions 28.0.0, 26.1.0. Examples include
com.android.support:animated-vector-drawable:28.0.0 and
com.android.support:mediarouter-v7:26.1.0

How to read those four lines

• com.android.support identifies the retired Support Library family, not current AndroidX.

• 28.0.0 and 26.1.0 are both present in the resolved dependency graph, even if only one appears directly in your module file.

• The named artifacts are examples that prove the mismatch; another dependency may be the component that requested the older version.

• Deleting build outputs cannot repair a dependency graph that still requests incompatible versions.

Find who requested the older artifact

Before editing versions, ask Gradle for evidence. Use the build variant that fails; debugRuntimeClasspath below can be replaced with releaseRuntimeClasspath or another variant-specific configuration.

$ ./gradlew :app:dependencies --configuration debugRuntimeClasspath

./gradlew :app:dependencyInsight \
  --configuration debugRuntimeClasspath \
  --dependency com.android.support:mediarouter-v7

com.android.support:mediarouter-v7:26.1.0
--- some.legacy:library:1.2.3
     --- debugRuntimeClasspath

Why these reports beat guesswork

• :app:dependencies prints the resolved dependency tree for the application module and selected configuration.

• dependencyInsight reverses the question: it shows which path requested mediarouter-v7 and why Gradle selected its version.

• The sample output is illustrative; use the actual path in your project to decide whether to upgrade, exclude, or replace the parent library.

• These tasks inspect configuration and do not modify project files.

Preferred fix: complete the AndroidX migration

AndroidX replaced the Support Library and gives each Jetpack library its own semantic version. A current project should not solve this old warning by collecting more com.android.support declarations. It should remove the old namespace from the dependency graph.

1. Create a focused migration branch and make sure the existing project builds before changing dependencies.

1. Update or replace third-party libraries that still publish com.android.support dependencies.

1. Use Android Studio’s Refactor → Migrate to AndroidX when the project still contains old imports and artifacts.

1. Review the generated changes against the official artifact and class mappings.

1. Build every important variant and run instrumentation, UI, and release smoke tests.

android.useAndroidX=true
 
# Enable only while an unavoidable third-party binary still needs rewriting.
android.enableJetifier=true

Do not leave Jetifier on by habit

• android.useAndroidX=true selects AndroidX behavior; Android Gradle Plugin 9.0 and later enables it by default.

• android.enableJetifier=true rewrites old third-party binaries, which can slow builds and should be used only when necessary.

• Current Android guidance says Jetifier is normally unnecessary because most library publishers have migrated.

• AGP 10 plans to remove the ability to disable AndroidX, so preserving Support Library builds is a short-term compatibility tactic.

dependencies {
    implementation(libs.androidx.appcompat)
    implementation(libs.androidx.mediarouter)
    implementation(libs.androidx.vectordrawable)
    implementation(libs.material)
}

What changed beyond the group name

• A version catalog centralizes approved coordinates instead of scattering literal versions across modules.

• com.android.support:mediarouter-v7 maps to androidx.mediarouter:mediarouter.

• com.android.support:support-vector-drawable maps to androidx.vectordrawable:vectordrawable.

• com.android.support:design maps to com.google.android.material:material, not an androidx.* artifact.

• AndroidX libraries version independently, so they are not supposed to share one universal version number.

Historical fallback: align on Support Library 28.0.0

Sometimes the assignment is to reproduce an old APK, not modernize it. Support Library 28.0.0 was the final release and is the only sensible alignment target for that temporary branch. Keep this path isolated and document why migration is deferred.

dependencies {
    implementation 'com.android.support:appcompat-v7:28.0.0'
    implementation 'com.android.support:mediarouter-v7:28.0.0'
    implementation 'com.android.support:support-vector-drawable:28.0.0'
}

Limits of this compatibility repair

• Directly declaring mediarouter-v7:28.0.0 can align the historical graph shown in the original error.

• It does not modernize source imports, provide future fixes, or make Support Library compatible with new Jetpack artifacts.

• Every Support Library artifact in the resolved graph must use 28.0.0; fixing only the two examples may reveal another mismatch.

• Prefer upgrading or replacing the dependency that requests 26.1.0 over forcing versions globally without compatibility testing.

Verify the graph, not just the editor

$ ./gradlew :app:dependencies --configuration debugRuntimeClasspath
./gradlew :app:lintDebug
./gradlew :app:assembleDebug

BUILD SUCCESSFUL

What a successful verification proves

• The dependency report lets you search for remaining com.android.support coordinates or unexpected selections.

• lintDebug reruns Android lint against the resolved debug variant.

• assembleDebug proves compilation and packaging, but it does not replace runtime tests on supported Android versions.

• Repeat the checks for release and product-flavor variants because their dependency graphs can differ.

Mistakes that keep the error alive

• Only running `clean`: stale outputs disappear, but the same coordinates resolve again.

• Adding a random direct dependency: it can mask one path while introducing APIs incompatible with the parent library.

• Using dynamic versions such as `28.+`: builds stop being reproducible and may resolve differently later.

• Forcing every version globally: resolution succeeds without proving binary or behavioral compatibility.

• Mixing AndroidX and Support Library: namespaces and artifacts must be migrated as one coherent change.

• Ignoring build variants: a debug graph can pass while release-only dependencies still contain the mismatch.

References and migration maps

• AndroidX migration guidance explains the supported migration path and Jetifier caveats.

• Official artifact mappings map old Support Library coordinates to AndroidX.

• Android dependency resolution demonstrates dependency reports and conflict analysis.