# Analyzing your Gradle dependencies

DevFeed: [Analyzing your Gradle dependencies](<https://devfeed.tech/articles/analyzing-your-gradle-dependencies-25824.md>)

Original publisher: [Read original article](<https://segunfamisa.com/posts/analyze-gradle-dependencies>)

Author: Segun Famisa

Published: 2024-03-14T20:00:00Z

Content type: tutorial

Language: en

Sources: [Segun Famisa](<https://devfeed.tech/sources/segun-famisa.md>)

Topics: [Gradle](<https://devfeed.tech/topics/gradle.md>), [Android](<https://devfeed.tech/topics/android.md>), [debug](<https://devfeed.tech/topics/debug.md>)

Tags: [android](<https://devfeed.tech/tags/android.md>), [debug](<https://devfeed.tech/tags/debug.md>), [dependency](<https://devfeed.tech/tags/dependency.md>), [gradle](<https://devfeed.tech/tags/gradle.md>), [guide](<https://devfeed.tech/tags/guide.md>)

## AI overview

A practical guide to analyzing Gradle dependencies in Android projects. It explains how dependency configurations determine classpaths, describes the ResolvableConfigurationsTask available in Gradle 7.5 and later, and recommends examining compile classpaths to identify unexpected dependencies in build type and product flavor combinations.

## Source excerpt

Featured in Android Weekly #614 and Kotlin Weekly #398 As Android developers, now and then, we may have to investigate or analyze the Gradle dependencies we are using. Whether we are trying to find out which versions of libraries we are using, or we are trying to find out where one - perhaps unusual dependency is coming from, we may end up needing this knowledge. A short story. Recently, leak canary - which we use to detect memory leaks - was found to be deactivated in our project. Upon investigating, I found that it was deactivated because a test dependency was accidentally added to the classpath of our debug builds. So, I had to investigate to find out what test dependency is there, and how it got there. In this post, I will share some tips that can help you analyze our Gradle dependencies and debug them too. Analyzing the configurations First, to analyze the dependencies, one needs to know which kinds of dependencies one is looking for. We can do this by trying to understand how exactly the dependencies are declared - and that determines how they end up in the classpath. In other words, we need to know the configurations. Configurations are a way for you to tell Gradle how exactly to package these dependencies to achieve the final output. Some dependencies might be used only in compile time, while some are needed both in compile time and runtime. Some might even have special behaviors, or relations to plugins like kapt and ksp, or only available in certain source sets - like tests. As described in Google's guide to declaring dependencies, some of the officially supported configurations include api, implementation, compileOnly, runtimeOnly among others. In version 7.5 and above, Gradle provides a ResolvableConfigurationsTask task that reports all the configurations that can be resolved within your project. The task is run as indicated below. ./gradlew :app:resolvableConfigurations app here can be replaced with whichever Gradle module you are interested in seeing.