A duplicate-class error is easier to diagnose from the dependency graph than from a list of exclusions copied into the build. Start by finding which dependency introduces each competing library.
Inspect the graph
The original commands exported Gradle’s dependency report. The Windows home-directory name below is an example value.
./gradlew app:dependencies > ~/Desktop/libs.txt
on Windows:
gradlew app:dependencies > C:\Users\Example\Desktop\libs.txtExclude at the dependency that introduces the conflict
This older project’s speech dependency used several exclusions:
implementation(projectDependencies.speech) {
exclude module: 'support-v4'
exclude group: 'javax.annotation', module: 'javax.annotation-api'
exclude group: 'com.android.support', module: 'support-annotations'
exclude group: 'com.google.api-client', module: 'google-api-client-appengine'
exclude group: 'org.threeten', module: 'threetenbp'
exclude group: 'com.google.code.findbugs', module: 'jsr305'
exclude group: 'org.apache.commons', module: 'commons-lang'
exclude group: 'org.apache.httpcomponents', module: 'httpclient'
}The list records that project’s resolution. Applying every exclusion to a different application can remove classes it still needs. Keep the exclusion tied to the actual conflicting dependency and check the resulting runtime behavior.
Read Maven coordinates
A dependency coordinate separates the group, module, and version:
net.sf.kxml:kxml2:2.3.0
=> Info
group: net.sf.kxml
module: kxml2
version: 2.3.0 That distinction helps express a narrow exclusion. This historical note does not claim that the listed support libraries or build configuration match a current Android project.