Resolve Gradle Dependency Conflicts with dependencyInsight

Ask why a version was selected

Use dependencyInsight for the affected configuration:

./gradlew :app:dependencyInsight \
  --dependency example-library \
  --configuration releaseRuntimeClasspath

Replace the placeholder with the relevant module name. The dependency-report documentation explains selection reasons and dependency paths.

Read the graph, not just the build file

A platform, constraint, transitive dependency or resolution rule can influence selection. Two visible declarations are only part of the story.

Compare the selected version with the requirements of the libraries that use it. A build can resolve successfully and still fail at runtime if a consumer expects an API that the selected version does not provide.

Choose the least surprising correction

Forcing a version globally should be an explicit compatibility decision, not the first reaction.

Avoid fixing one variant while breaking another

Inspect release and debug graphs, plus relevant test configurations. Product flavors can bring in different SDKs, and an exclusion that helps one flavor may remove a needed class from another.

The Android dependency guide provides configuration context. Keep the reason for any constraint or exclusion next to the declaration or in a linked build note.

Prove the resolved outcome

Re-run the report, build the release and exercise the dependent feature. APKLint's Gradle tools can flag suspicious declarations and support review, but only Gradle's resolved graph shows which version your actual repositories and rules selected.