R8 shrinking, obfuscation, and optimization

WHAT THIS TESTS The interviewer checks whether you know the distinct responsibilities R8 combines in one pass and can articulate why removing code matters for security, not just app size.

A GOOD ANSWER COVERS R8 is the default Android compiler-and-shrinker that performs three jobs together. Shrinking, also called tree-shaking, builds a reachability graph from your keep rules and entry points, then removes classes, methods, and fields that nothing references, along with unused resources. Obfuscation renames the surviving packages, classes, and members to short, meaningless identifiers like a, b, and c, which both shrinks the dex and makes decompiled code far harder to follow; a mapping file is produced so crash stack traces can be de-obfuscated. Optimization rewrites code for performance and size by inlining small methods, removing dead and unreachable branches, propagating constants, and merging classes where safe.

On the security point: by stripping all code not reachable from your entry points, shrinking removes unused functionality, including dormant, unused, or vulnerable code paths in libraries you depend on. Less shipped code means a smaller attack surface, so a known-vulnerable method that your app never actually calls may be removed entirely. Obfuscation adds friction against reverse engineering by hiding meaningful names.

COMMON WRONG ANSWERS Calling obfuscation encryption, it is renaming, not encryption, and the code still runs and can be decompiled with effort. Claiming obfuscation makes the app secure on its own. Forgetting keep rules, which leads to reflection or serialization breaking when needed symbols get stripped or renamed. Confusing R8 with the older ProGuard, R8 replaced it.

LIKELY FOLLOW-UPS Why do you need keep rules for reflection, JNI, and serialization? What is the mapping file used for? How does R8 differ from ProGuard? Why is obfuscation not a substitute for real security controls?

ONE CONCRETE EXAMPLE Your app pulls in a large utility library but calls only two of its functions. R8 shrinking removes the rest, so if a vulnerable parser elsewhere in that library is never reachable from your code, it never ships, cutting both APK size and exposure. Meanwhile a class named PaymentProcessor becomes a, slowing down an attacker reading the decompiled bytecode.