How to Fix Duplicate Kotlin Stdlib Class Errors in Android Gradle

By the end of this page, you will understand what a duplicate class error means in an Android Gradle build, why Kotlin stdlib version conflicts happen, and how to fix them by aligning dependency versions instead of deleting downloaded files.

A duplicate class error happens when Gradle resolves two different libraries that both contain the same compiled class name. During the Android build, only one definition of a class can exist on the classpath. If two artifacts provide the same class, the build fails.

In this case, the conflict is between:

• org.jetbrains.kotlin:kotlin-stdlib:1.8.0
• org.jetbrains.kotlin:kotlin-stdlib-jdk7:1.6.0
• org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.6.0

This matters because newer Kotlin versions merged or reorganized parts of the standard library. If your project or one of your dependencies pulls in an older jdk7 or jdk8 stdlib artifact while another dependency uses a newer base stdlib, Gradle may end up with overlapping classes.

A key point: the problem is not the files in your local cache. Those files are just downloaded copies of declared dependencies. Deleting them does not solve the real issue, because Gradle simply downloads them again based on your build configuration.

The real fix is to:

• identify which dependency introduces the old Kotlin libraries
• align Kotlin-related versions
• avoid dynamic versions such as +
• use modern Gradle dependency management consistently

In Android projects, dependency issues often come from transitive dependencies. That means you may not have added kotlin-stdlib-jdk8 directly, but another library may have brought it in for you.

Think of your app build like packing a suitcase for a trip.

• Each dependency is an item you pack.
• Each class is a specific object inside the suitcase.
• If two different bags both contain the exact same object with the same label, security stops you and asks which one is the real one.

That is what Gradle is doing.

Deleting the downloaded files is like removing the object from the suitcase after packing, while your packing list still says to include it. On the next pack, it comes back.

So the correct solution is not to delete files manually. The correct solution is to fix the packing list: your Gradle dependencies.

In Gradle, dependency conflicts are usually fixed by declaring consistent versions or excluding conflicting transitive dependencies.

Example: a clean Kotlin Android dependency setup

plugins {
    id 'com.android.application'
    id 'org.jetbrains.kotlin.android'
    id 'com.google.gms.google-services'
}

android {
    compileSdk 33

    defaultConfig {
        applicationId "com.example.app"
        minSdk 21
        targetSdk 33
        versionCode 1
        versionName "1.0"
    }

    compileOptions {
        sourceCompatibility JavaVersion.VERSION_1_8
        targetCompatibility JavaVersion.VERSION_1_8
    }

    kotlinOptions {
        jvmTarget = '1.8'
    }
}

dependencies {
    implementation "org.jetbrains.kotlin:kotlin-stdlib:1.8.0"
    implementation "androidx.core:core-ktx:1.10.1"
}

Why this helps

• The Kotlin Android plugin is applied explicitly.
• Kotlin uses a known version instead of mixed versions.
• core-ktx:+ is replaced with a fixed version.
• Fixed versions make builds predictable.

Example: excluding old Kotlin stdlib artifacts

If a library brings in old Kotlin artifacts, you can exclude them:

implementation('some.library:example:1.0.0') {
    exclude group: 'org.jetbrains.kotlin', module: 'kotlin-stdlib-jdk7'
    exclude group: 'org.jetbrains.kotlin', module: 'kotlin-stdlib-jdk8'
}

Use this only when needed. Usually, version alignment is a better first step.

Safer version declarations

Avoid this:

implementation "androidx.core:core-ktx:+"

Prefer this:

Consider this simplified dependency situation:

dependencies {
    implementation "org.jetbrains.kotlin:kotlin-stdlib:1.8.0"
    implementation "some.library:example:1.0.0"
}

Assume some.library:example:1.0.0 transitively depends on:

org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.6.0
org.jetbrains.kotlin:kotlin-stdlib-jdk7:1.6.0

What Gradle does

1. It reads your direct dependencies.
2. It reads the transitive dependencies of each library.
3. It builds one full dependency graph.
4. It sees that:
   • kotlin-stdlib:1.8.0 contains classes already included in newer Kotlin packaging.
   • kotlin-stdlib-jdk7:1.6.0 and kotlin-stdlib-jdk8:1.6.0 also contain some of those same classes.
5. During Android packaging, duplicate class names are detected.
6. The build fails.

How you investigate

A common Gradle command is:

./gradlew app:dependencies

This prints the dependency tree so you can see which library pulls in the old Kotlin modules.

You can also inspect one dependency path more closely with:

./gradlew app:dependencyInsight --dependency kotlin-stdlib

Dependency conflict resolution is common in real Android development.

Typical situations

• Adding Firebase and AndroidX libraries together: different libraries may expect different Kotlin versions.
• Updating one library but not others: one dependency becomes newer while another still depends on older Kotlin artifacts.
• Using dynamic versions such as +: a dependency updates silently and introduces a mismatch.
• Large team projects: different modules may declare slightly different versions of the same library.
• Migrating Java apps to Kotlin: Kotlin plugins and libraries may not be configured consistently at first.

Practical examples

• A chat app adds a new image library and suddenly gets duplicate Kotlin classes.
• An ecommerce app updates core-ktx but leaves older navigation or Firebase dependencies.
• A multi-module app has one module on Kotlin 1.8 and another indirectly using Kotlin 1.6 artifacts.

In real projects, developers rarely solve this by deleting cache files. They solve it in the build configuration.

Common patterns

1. Version alignment

Keep Kotlin, AndroidX, and other core libraries on compatible versions.

implementation "androidx.core:core-ktx:1.10.1"

2. Avoid dynamic versions

Dynamic versions make builds unstable.

// Avoid
implementation "androidx.core:core-ktx:+"

// Prefer
implementation "androidx.core:core-ktx:1.10.1"

3. Use platform dependencies correctly

Firebase BoM lets you omit versions for Firebase libraries.

implementation platform('com.google.firebase:firebase-bom:32.7.4')
implementation 'com.google.firebase:firebase-auth'
implementation 'com.google.firebase:firebase-firestore'

4. Exclude transitive dependencies selectively

If one library pulls in an outdated module, exclude it.

implementation('library:example:1.0.0') {
    exclude group: 'org.jetbrains.kotlin', module: 'kotlin-stdlib-jdk7'
    exclude group: 'org.jetbrains.kotlin', module: 'kotlin-stdlib-jdk8'
}

5. Inspect the dependency graph

Developers use Gradle reports to locate the exact source of a conflict.

./gradlew app:dependencies
./gradlew app:dependencyInsight --dependency kotlin-stdlib-jdk8

6. Remove obsolete or duplicate dependencies

1. Deleting files from the Gradle cache

This does not fix the root cause.

.idea/libraries
.gradle/caches

Gradle downloads dependencies again because they are still declared in the build.

Better approach: fix the dependency graph in build.gradle.

2. Using dynamic versions

Broken pattern:

implementation "androidx.core:core-ktx:+"

Why it is risky:

• builds are not reproducible
• dependency versions can change unexpectedly
• new versions may pull in conflicting transitive dependencies

Use a fixed version instead:

implementation "androidx.core:core-ktx:1.10.1"

3. Mixing versioned and BoM-managed Firebase dependencies

Broken pattern:

implementation 'com.google.firebase:firebase-database:20.1.0'
implementation platform('com.google.firebase:firebase-bom:28.4.0')
implementation 'com.google.firebase:firebase-database'

This is inconsistent.

Pick one style: if you use the Firebase BoM, omit versions for Firebase libraries.

4. Declaring the same dependency twice

Example from the provided file:

Duplicate class error quick reference

What it means

Two dependencies contain the same class, so the Android build cannot decide which one to use.

Common causes

• mixed Kotlin versions
• transitive dependency conflicts
• dynamic versions like +
• duplicate or inconsistent library declarations

Useful Gradle commands

./gradlew app:dependencies
./gradlew app:dependencyInsight --dependency kotlin-stdlib
./gradlew app:dependencyInsight --dependency kotlin-stdlib-jdk8

Good practices

• use fixed versions
• apply org.jetbrains.kotlin.android in Kotlin Android apps
• use Firebase BoM consistently
• remove duplicate dependency lines
• exclude old transitive artifacts only when necessary

Avoid

implementation "androidx.core:core-ktx:+"

Prefer

implementation "androidx.core:core-ktx:1.10.1"

Firebase BoM pattern

implementation platform('com.google.firebase:firebase-bom:32.7.4')
implementation 'com.google.firebase:firebase-auth'
implementation 'com.google.firebase:firebase-firestore'

Exclude old Kotlin stdlib modules if needed

Why does deleting the Kotlin files not solve the problem?

Because those files are only cached copies of dependencies declared in Gradle. When you build again, Gradle downloads them again.

What causes duplicate Kotlin stdlib classes?

Usually a version mismatch, such as one dependency using kotlin-stdlib:1.8.0 while another pulls in kotlin-stdlib-jdk7 or kotlin-stdlib-jdk8 from an older version.

Should I remove kotlin-stdlib or kotlin-stdlib-jdk8 manually?

Not from the cache. You should fix the dependency declarations or exclude the transitive dependency in Gradle.

Is core-ktx:+ a bad idea?

Yes, in most real projects. It can upgrade silently and introduce dependency conflicts.

Do I need firebase-core?

In modern Firebase Android projects, it is usually unnecessary. The Firebase BoM and specific Firebase libraries are typically enough.

How do I find which library adds the old Kotlin dependency?

Run:

./gradlew app:dependencyInsight --dependency kotlin-stdlib-jdk8

This shows the dependency path.

Should I use Firebase BoM or explicit Firebase versions?

Usually Firebase BoM is the better choice because it keeps Firebase libraries aligned automatically.

• Gradle dependency management — central to understanding how libraries are resolved in Android builds.
• Transitive dependencies — explains how libraries can bring in other libraries automatically.
• Kotlin standard library — directly related because the error involves Kotlin stdlib artifacts.
• Android Gradle plugin — important because Android builds and packaging are handled through it.
• Firebase BoM — relevant because the sample project uses Firebase and version alignment matters.
• Semantic versioning — helps explain why mixing versions like 1.6.0 and 1.8.0 can cause problems.
• Kotlin Android plugin — important for proper Kotlin setup in Android projects.
• Dependency exclusion — useful when a transitive dependency causes conflicts.