No. A compileOnly dependency is available when compiling and is not packaged in the build output. A runtimeOnly dependency is the reverse: packaged, but not on the compile classpath. For vulnerability work, the configuration tells you whether the library actually reaches users.
The four configurations
The Android documentation describes them like this.
| Configuration | Compile classpath | Packaged in output | Notes |
|---|---|---|---|
implementation | Yes, not exposed to other modules | Yes | Default for most modules |
api | Yes, exposed to consumers | Yes | Use sparingly |
compileOnly | Yes | No | Optional dependencies; cannot be used with AAR dependencies |
runtimeOnly | No | Yes | Rare on Android; for example a logging backend |
For compileOnly, your code must check at runtime whether the dependency is present.
Why this matters for triage
A scanner that reads your build file may report a vulnerable library whether it is compileOnly or not. If it is compileOnly, the code is not in your release, though the module that supplies it at runtime might be.
The opposite error is also possible. A runtimeOnly library never appears in a compile time search of your source, yet it runs in production.
For the api and implementation split, see Gradle api vs implementation.
Steps to apply
- List configurations for each flagged dependency. Do not stop at its name.
- For
compileOnly, ask who provides the class at runtime and whether that provider is vulnerable. - For
runtimeOnly, add it to your inventory even though no source imports it. - Confirm against the built artifact when stakes are high, by listing its contents.
- Note the configuration beside the dependency in your records.
Try it yourself
Click through it at your own pace, or open it full screen. See how separating present, reachable and shipped code changes which findings you act on first.
Safeguard builds an SBOM and scans your dependencies for known vulnerabilities, and you can run a free scan at gold.safeguard.sh/scan to see what your own project pulls in.
Quick check
Is a compileOnly finding always a false alarm?
Not always. The code is not packaged by your build, but something else at runtime may provide it. Check that.
Why would anyone use runtimeOnly?
For code needed when the app runs, such as a logging backend your consumers supply.
Sources
Last reviewed: 19 October 2026.
