Possibly not, but do not assume. R8 removes unreachable code from your app and its libraries, so a vulnerable method may not be in the shipped binary. Keep rules, reflection and wide entry points can retain it. Treat shrinking as a clue, then confirm with the built artifact and reachability analysis.
What R8 does
Android's documentation says R8 identifies and removes unreachable code from your application and its library dependencies. It analyzes entry points such as activities and services in the manifest, builds a graph of referenced code and removes what is unreferenced. Obfuscation shortens names but does not remove code. Optimization rewrites code, for example by inlining methods and merging classes.
Keep rules protect code from removal. The documentation says to add them when optimization causes errors.
Why this is not a clean answer
An advisory names a vulnerable library version. Your scanner reports it because the library is in your dependency tree. R8 may have removed the vulnerable class from the release build, which would reduce real exposure. Several things can change that:
- Broad keep rules. A rule that keeps a whole package keeps everything in it.
- Reflection and dynamic loading. Code reached by name may be retained or may break if removed.
- Shrinking disabled. Many debug builds, and some release builds, do not enable it.
- Different variants. What was removed in one variant may remain in another.
Three ways to decide
| Method | What it tells you | Effort |
|---|---|---|
| Assume affected because the library is present | Safe default, noisy | None |
| Check the built artifact for the vulnerable class | Whether the code shipped | Medium |
| Reachability analysis of your code paths | Whether your code can call it | Tool dependent |
The second method is concrete. Open the release build in Android Studio's APK Analyzer and look for the class named in the advisory. If the class is absent, the specific flaw is not in that build. If the class is present, check whether your code calls it.
A practical routine
- Read the advisory and note the vulnerable class or method.
- Confirm that R8 or minification is on for the variant you ship.
- Inspect the built artifact for that class.
- Check your keep rules for broad patterns covering the library.
- If present and reachable, update the library.
- Record the decision, with the build it applies to.
Even when the code is absent, updating the library on your normal schedule is cheap and removes the question for future builds.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how the list of findings shrinks once call paths are considered. That is the same idea R8 applies to bytes, applied to alerts.
Quick check
Can I ignore every advisory for a library R8 shrinks?
No. Verify the specific class is gone from the build you ship.
Does obfuscation remove vulnerable code?
No. It renames code. Shrinking removes it.
Safeguard's reachability analysis is built to help separate vulnerabilities your code can reach from those it cannot, and it also covers dependency and SBOM scanning. It does not inspect compiled Android binaries. Try a free scan.
Sources
Last reviewed: 19 October 2026.
