Gradle Dependency Types: implementation, api and Runtime Configurations

Read the configuration as a scope

Exact availability depends on the applied plugins and variant model. Android's dependency guide and Gradle's Java library model explain the distinction.

Choose from the code boundary

If a library's public method returns a type from another library, consumers may need that type on their compile classpath. That is a reason to examine api. If the dependency is hidden inside the implementation, exposing it unnecessarily couples consumers to an internal choice.

Do not change every dependency to api merely to fix an unresolved import in a downstream module. Decide whether the downstream module should declare its own dependency or whether the type truly belongs to the upstream public contract.

Keep tests out of production

A mocking or test assertion library normally belongs in a test configuration. Putting it in implementation can add unnecessary code or dependencies to the release graph. Inspect the resolved release configuration rather than assuming a dependency is absent because it is only used by tests.

Understand declarations versus resolution

A declaration is an input to dependency resolution. Transitive requirements, platforms and constraints can select a version different from the one you wrote. Verify the relevant runtime classpath before making size or vulnerability claims.

Review with APKLint

The Gradle Dependency Checker can help inspect declarations and obvious issues. It does not run your complete project graph, so it cannot prove which artifact Gradle selected for every variant. Use it alongside a build-generated dependency report and a clear explanation for each public or runtime dependency.