Duplicate Class Build Errors: Find the Two Owners of the Same Class

Capture both owners

Copy the class name and both artifact paths from the error. Typical causes include a local JAR plus its Maven equivalent, a bundled SDK plus a standalone copy, or old and new library families included together.

Use the Android dependency guidance to trace how those inputs reach the module.

Inspect the dependency paths

./gradlew :app:dependencies --configuration releaseRuntimeClasspath
./gradlew :app:dependencyInsight \
  --dependency conflicting-module \
  --configuration releaseRuntimeClasspath

The second command uses a placeholder module name. The Gradle report guide explains how to read selection and parent paths.

Remove the redundant ownership

A version force cannot solve every case because the duplicate may come from different coordinates.

Do not hide code duplication with resource rules

Packaging exclusions intended for metadata files are not a general solution for duplicate executable classes. Removing a class from an archive manually also creates an unsupported artifact with unclear compatibility.

A narrow transitive exclusion can be valid, but verify that the remaining copy satisfies all consumers and that the publisher supports the combination.

Recheck every relevant variant

Build the same variant that failed, then check other flavors using different SDK sets. APKLint's dependency review can help locate suspicious overlaps, but the complete error and resolved build inputs are necessary to identify the two actual owners. Keep those artifacts and paths in the fix record so the same duplicate does not return during a later SDK update.