R8, Shrinking & App Size Interview Questions
BUILD & TOOLING › Gradle
Walk me through what you'd do the first time you enable minifyEnabled on a release build and it crashes with a ClassNotFoundException or NoSuchMethodError that never happens in debug.
What a strong answer covers: First confirm it's an R8-only failure by comparing against an unminified release build, then identify whether the missing class or member is reached only via reflection or serialization, such as a Gson model class, or is referenced only from XML, native code, or JNI where R8 can't see the usage statically. Add the narrowest possible keep rule scoped to that class or member rather than disabling minification, then rerun the release build and exercise that exact path to confirm the fix.
Why would a senior engineer push back on the instinct to add a broad -keep class com.example.** { *; } to make a shrinking crash go away, instead of a narrower rule?
What a strong answer covers: A broad keep rule defeats shrinking and obfuscation for that entire package, bloating the APK and leaving code needlessly easy to reverse-engineer, and it tends to mask the real root cause so future additions to that package silently stay unshrunk without anyone noticing. The better fix is keeping only the specific classes or members actually accessed reflectively, like the exact model classes Gson deserializes, not everything in their package.
How would you validate, before shipping, that your R8 keep rules are correct and complete, rather than just 'it didn't crash in my manual testing'?
What a strong answer covers: Run your automated test suite, ideally instrumented tests exercising reflection-heavy paths like deserialization and DI graph construction, against the actual release-minified build rather than debug, since R8 behavior in full mode can diverge in ways that only show up in that artifact. Use R8's diagnostics such as -whyareyoukeeping to confirm specific classes and members survive shrinking as intended, because a green manual smoke test doesn't cover rare paths like error handling or feature-flagged code that production traffic will eventually hit.