Follow a public type
Suppose module :networking exposes a method returning a third-party HTTP client's response type. Consumers compiling against that method need to understand the exposed type. That suggests an api relationship—or a redesign that returns your own stable model instead.
If the HTTP client is used only inside private implementation code, implementation keeps that detail out of the consumer-facing compile contract.
The Gradle Java library documentation explains API separation, while Android's dependency guide describes its use in Android modules.
Compare the design consequences
| Choice | Review question |
|---|---|
Expose third-party type with api |
Are consumers intentionally coupled to this dependency? |
Hide type with implementation |
Does the public API remain usable without the internal library? |
| Add dependency directly to consumer | Does the consumer independently use that library? |
| Wrap the type in your own model | Is the extra abstraction justified by stability needs? |
A compilation error after changing api to implementation can reveal an existing coupling rather than a Gradle bug.
Do not confuse visibility with packaging
implementation does not mean the dependency is excluded from runtime packaging. It controls dependency exposure and classpaths under the applied plugin model. Inspect the release runtime graph and resulting package for size or distribution questions.
Similarly, compileOnly is not a smaller equivalent of implementation; the required runtime implementation must be supplied through an appropriate mechanism.
Make changes with consumer tests
Build every module that consumes the library, run API-facing tests and exercise the release variant. A library compiling in isolation does not prove that downstream modules still compile or run correctly.
Inspect declarations with APKLint
The Gradle Dependency Checker can highlight scope choices and duplicate declarations. It cannot infer your intended public API from a build snippet alone. Pair its findings with source-level review of exposed types and the build-generated dependency graph.
Sources and further reading
Reference review: 22 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
