gradle 'Execution failed for task :app:checkDebugDuplicateClasses' after a dependency bump

TL;DR

Two dependencies contain the same classes, and the dex step refuses the duplicates. Find which dependencies bring the overlapping classes, exclude the duplicate module from one of them (or align both to versions that do not overlap), then rebuild.

Error

gradle 'Execution failed for task :app:checkDebugDuplicateClasses' after a dependency bump

Steps

1. Read the error: it lists the duplicated class files. Expected output: You know which classes collide.

2. Find the owners: ./gradlew :app:dependencies and search for the libraries containing those classes. Expected output: You see the two (or more) dependencies contributing the same classes.

3. Exclude the duplicate from one side: add an exclude for the overlapping group and module on one dependency declaration. Expected output: The dependency graph carries the classes exactly once.

4. If both sides are the same library at different versions, align them instead: force one version or adopt a platform BOM. Expected output: A single version of the library remains in the graph.

5. Rebuild: ./gradlew :app:assembleDebug. Expected output: checkDebugDuplicateClasses passes and the APK builds.

When to use

• Gradle fails with execution failed for task :app:checkDebugDuplicateClasses after a dependency bump
• A bump pulled in a library that bundles classes another dependency already ships
• Jetified old support libraries collide with AndroidX equivalents

When not to use

• The failure is could not resolve all files; that is resolution, which happens earlier
• The duplicates are in your own source sets; fix the source duplication instead
• The build fails at mergeDebugNativeLibs; that is native libraries, a different dedup problem

Variant phrasings

Duplicate classes after adding a fat AAR dependency

Fat AARs bundle their transitive deps; exclude the bundled modules you already get elsewhere.

checkDebugDuplicateClasses fails after a major bump

The new major repackaged classes that another dependency still ships under the old path.

AndroidX versus support library duplicates

The migration shape; exclude the old support artifacts or finish the AndroidX migration.

Why it happens

A bump can introduce a dependency that embeds classes another dependency already provides: fat AARs, relocated packages published under both old and new coordinates, or a library that absorbed a former transitive dep. The dex toolchain requires each class exactly once, so the build stops at the duplicate check.

Edge cases

• Excluding too aggressively can remove classes the app needs at runtime; run the app, not just the build.
• Aligning versions with a BOM prevents the whole class of problem for library families like AndroidX.
• The duplicate check runs per variant; a fix for debug may need repeating for release if the graphs differ.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstSGBlKlUHjfBWluFLccSAA