Inspect the relevant configuration
For a typical Android application module, begin with:
./gradlew :app:dependencies --configuration releaseRuntimeClasspath
Use the actual module and variant configuration in your project. A debug or test classpath can differ from the release delivered to users.
The Gradle dependency-report guide explains the graph notation and selected versions. Save the report with the commit and toolchain used to produce it.
Follow the incoming paths
| Observation | Meaning to investigate |
|---|---|
| Library appears under an SDK | SDK metadata introduced it transitively |
| Same library appears on several paths | Removing one parent may not remove the dependency |
| Requested version points to another version | Resolution selected a different version |
| Library exists only in a test configuration | It may not belong to the release runtime graph |
Use dependencyInsight to ask why a particular module was selected rather than reading a large tree by eye alone.
Avoid indiscriminate exclusions
Excluding a transitive library can make a build compile while causing a runtime failure when the parent SDK calls it. First determine why the dependency exists and whether the provider documents it as optional.
Prefer upgrading to compatible parent dependencies, aligning versions through supported constraints or replacing an obsolete SDK. If an exclusion is justified, test the feature path that used the removed library.
Compare before and after
Record the old and new resolved graphs, then inspect the built APK or bundle. A dependency declaration disappearing is not proof that its classes vanished from every artifact, especially when another dependency bundles or shades similar code.
Use the checker with build evidence
APKLint's Gradle tools can review configuration snippets and flag suspicious declarations. They cannot resolve every repository, plugin and variant from a fragment. The authoritative graph comes from the build itself; combine that with package inspection before claiming a dependency, vulnerability or size contribution has been removed.
Follow a removal through two parent dependencies
Consider an illustrative app that includes a support SDK and a payment SDK. Both depend on the same JSON parser. Removing the parser's direct declaration does not remove it from the resolved graph because two parents still request it. Removing the support SDK may leave it present through payments. Build a small path table naming the selected parser version, both parents and the configuration that produced the observation before deciding which change could actually remove it.
If the payment provider documents the parser as required, excluding it can transfer the failure from build time to checkout time. A successful home-screen launch would not exercise that path. In a test environment, create a synthetic payment request, inspect parsing of both success and error responses and check any offline or retry flow that uses the same parser.
Express an exclusion at the reviewed edge
dependencies {
implementation("example:optional-integration:1.0") {
exclude(group = "example.legacy", module = "old-adapter")
}
}This is illustrative syntax using fictional coordinates. It is appropriate only after establishing that this dependency edge can omit the adapter and that another supported implementation covers the required behavior. Gradle's exclusion guide explains the edge-specific mechanism. An exclusion on one declaration does not erase requests made through other dependency paths.
After applying a justified exclusion, compare the relevant runtime reports and inspect the package. If the old adapter remains, determine whether another parent requests it or an SDK embeds equivalent classes inside its own archive. The second situation is a packaging issue that ordinary transitive metadata may not reveal. Preserve the exact artifact names in the investigation so a similarly named module is not mistaken for the same code.
Finally, keep the reason for the exclusion with the dependency declaration and identify the provider guidance or compatibility test supporting it. Revisit that reason when either parent SDK changes. An exception that was correct for one integration version can become unnecessary or unsafe after the publisher changes how it packages the adapter.
Sources and further reading
Reference review: 29 September 2026. Examples illustrate the workflow; check your installed versions, release artifact and account-specific Console requirements before applying them. This guide is not a claim that APKLint executed your project or verified your private account.
Android inspection tools and practical release guides. About APKLint · Report a correction
