If you've been developing with React Native or Expo for a while, chances are you've had a project that suddenly refuses to build for what seems like no reason.
Maybe you installed a new package. Maybe you upgraded Expo. Maybe you only changed a single dependency. You confidently run your Android build, expecting it to compile like always...
Instead, Gradle greets you with something like this:
Execution failed for task ':app:checkDebugDuplicateClasses'.
Duplicate class androidx.lifecycle.ViewModelLazy found in modules lifecycle-viewmodel-2.8.2.aar and lifecycle-viewmodel-ktx-2.6.1.aar
Duplicate class com.google.android.gms.internal.measurement.zzab found in modules play-services-measurement-base-22.0.0.aar and play-services-measurement-impl-21.6.2.aar
Duplicate class ...
At first glance, the error looks straightforward: there are duplicate classes. Easy enough, right?
Not exactly.
In reality, this is one of those Android build errors that can send you down a rabbit hole of Gradle files, dependency trees and Stack Overflow threads, only to realize the real cause was something completely different.
Let's break down what's actually happening and, more importantly, how to fix it.
Why this error happens
Every Android library included in your project contains compiled Java or Kotlin classes.
When Gradle builds your application, it combines all of those libraries into a single APK or AAB.
If two different dependencies contain the exact same class, Gradle doesn't know which version should be packaged.
Instead of guessing, it stops the build with a Duplicate class error.
The difficult part is that the dependency causing the conflict usually isn't the one shown in the error.
Very often, it's another package pulling in an older or incompatible version behind the scenes.
The most common causes
After seeing this error many times, these are usually the culprits.
1. Two libraries depend on different versions of the same package
This is by far the most common scenario.
For example:
- Library A requires:
androidx.lifecycle:lifecycle-viewmodel:2.8.2
while Library B depends on:
androidx.lifecycle:lifecycle-viewmodel:2.6.1
Both versions get added to your dependency graph, eventually leading to duplicate classes.
2. An outdated React Native package
Older React Native libraries often haven't been updated for newer AndroidX or Google Play Services versions.
Even though your project is current, that one dependency may still reference libraries released years ago.
3. Expo SDK upgrades
After upgrading Expo, many native dependency versions change.
If one third-party package hasn't caught up yet, Gradle may end up resolving incompatible versions.
This is especially common immediately after major SDK releases.
4. Mixing manual native configuration with Expo-managed dependencies
Sometimes developers manually add Android dependencies that Expo already manages internally.
The result is two copies of essentially the same library.
How to fix it
There isn't one universal solution, but these steps solve the majority of cases.
Step 1 — Read the duplicated class carefully
Don't focus on the entire error.
Look specifically for the two modules involved.
For example:
lifecycle-viewmodel-2.8.2
lifecycle-viewmodel-ktx-2.6.1
Those names usually point you toward the conflicting dependency.
Step 2 — Find who is importing it
Run:
./gradlew app:dependencies
or
./gradlew app:dependencyInsight --dependency lifecycle-viewmodel
This shows which package is pulling each version into your project.
It's much faster than guessing.
Step 3 — Update outdated packages
If one library is significantly behind, updating it often resolves the conflict immediately.
Always check whether a newer version exists before trying complicated Gradle workarounds.
Step 4 — Clean the project
Sometimes Gradle continues using cached artifacts.
Try:
cd android
./gradlew clean
Then rebuild.
Step 5 — Regenerate native files (Expo)
If you're using Expo Prebuild:
npx expo prebuild --clean
This recreates the native Android project using your current configuration.
Step 6 — Force dependency versions (only if necessary)
Sometimes you need to force Gradle to use one specific version.
For example:
configurations.all {
resolutionStrategy {
force "androidx.lifecycle:lifecycle-viewmodel:2.8.2"
}
}
Use this carefully.
If two libraries genuinely require incompatible versions, forcing one version may create runtime problems later.
How to avoid this error in the future
While duplicate class errors can't always be prevented, these habits reduce the chances considerably.
- Keep Expo SDKs reasonably up to date.
- Avoid abandoned React Native libraries.
- Update dependencies together instead of one at a time.
- Review package compatibility before major upgrades.
- Avoid manually adding Android dependencies unless absolutely necessary.
When the error isn't actually the problem
One thing that makes this error frustrating is that the duplicate classes are often just a symptom.
The real issue might be:
- an outdated library,
- conflicting Firebase dependencies,
- mixed AndroidX versions,
- incompatible Google Play Services packages,
- or an incomplete Expo migration.
That's why simply searching the duplicated class name doesn't always lead to the correct fix.
Understanding why those dependencies ended up together is usually more important than the class itself.
How FixMyError can help
Instead of manually digging through Gradle output, dependency trees and dozens of forum posts, you can paste the full error into FixMyError.
The tool analyzes the build log, identifies the likely source of the conflict, explains what's happening in plain English, and suggests fixes based on the specific dependencies involved.
Rather than treating every duplicate class error as identical, it tries to narrow the problem down to the actual cause behind your particular build failure.
Final thoughts
Duplicate class errors are among the most frustrating Android build issues because the message rarely points directly to the package that's responsible.
The good news is that, in most cases, the problem comes down to dependency resolution rather than something fundamentally broken in your project.
Once you identify which libraries are introducing conflicting versions, the fix usually becomes much more straightforward.
If you're currently staring at a wall of Gradle output wondering where to begin, start by identifying the conflicting modules, trace where they're coming from, and work outward from there.
It takes a bit of patience, but it's almost always easier than blindly trying random fixes from different Stack Overflow threads.
Top comments (0)