What can obfuscation (R8/ProGuard) actually protect against, and what can't it?

#Obfuscation was never the primary job

R8 (the tool that replaced ProGuard as Android's default compiler-integrated shrinker) exists first to make your APK smaller and faster: it removes unreferenced classes and methods (shrinking), inlines and simplifies bytecode (optimization), and — as a byproduct of shrinking — renames classes, methods and fields to short, meaningless names (obfuscation) because a.b.c compresses better and there's no reason to ship your real symbol names if nothing external needs them. Security teams later leaned on that renaming as a reverse-engineering deterrent, and it's a reasonable one, but it's worth being precise in an interview about what kind of deterrent it is: it raises the cost of casual reading, it does not create confidentiality.

That distinction shows up immediately once you decompile a release APK. Renaming survives the round trip through a tool like jadx, but almost nothing else about the code's meaning does:

// Source
class UserSessionRepository(private val api: AuthApi) {
    fun refreshToken(refreshToken: String): TokenResponse {
        return api.refresh(refreshToken)
    }
}

// Decompiled from the obfuscated APK
public class a {
    private final b a;

    public a(b api) {
        this.a = api;
    }

    public TokenResponse a(String str) {
        return this.a.a(str);
    }
}

The class and method names are gone, but the shape is fully intact: one dependency injected through the constructor, one public method that delegates to it, and a return type (TokenResponse) that R8 leaves alone because it's part of your data model and — critically — string literals are untouched by default. Any hardcoded API key, base URL, or crypto key embedded as a string constant is sitting in the dex file in plain text, findable with strings on the raw bytes, obfuscation or not.

#What it does reasonably protect

• Casual reading and copy-paste. A competitor's engineer skimming your decompiled code for "how did they implement X" hits a wall of a, b, c classes with no doc comments, no meaningful names, and dead code already stripped out — annoying enough that most people give up short of a serious, funded effort.
• Accidental information leakage. -assumenosideeffects rules that strip Log.d/Log.v calls in release builds mean debug logging you forgot to gate doesn't ship verbose internal state to logcat on every user's device.
• APK size and structure. Removing unused library code (a large fraction of most dependency trees) both shrinks the binary and removes surface area an attacker would otherwise have to wade through.

# proguard-rules.pro
-keep class com.myapp.network.models.** { *; } # keep reflection-accessed model classes

-assumenosideeffects class android.util.Log {
    public static int d(...);
    public static int v(...);
}

-allowaccessmodification
-repackageclasses ''   # R8 full mode: flatten everything into one obfuscated package

#What it does not protect against

• Dynamic instrumentation. Frida hooks by class hierarchy, method signature, and surrounding framework calls, not by whether a name reads as meaningful English. An obfuscated a.a(String) is exactly as hookable as AuthRepository.refreshToken(String) — the attacker just adds one step of figuring out which renamed method is which, usually by watching runtime behavior rather than reading names at all.
• Rooted/jailbroken runtime tampering. SSL-pinning bypass scripts, biometric-check bypasses, and root-detection bypasses operate on the running process, patching method return values or hooking into the framework layer beneath your obfuscated code entirely. Obfuscation doesn't touch that layer.
• Client-authoritative logic. If price calculation, feature gating, or "is this purchase valid" logic lives in the client and only reports a result to the server, obfuscation just makes the patch-and-repackage cycle take an attacker a bit longer — it doesn't make client-side authority safe. That logic belongs on a server you control.
• Repackaging. An attacker can decompile, patch, and re-sign an APK with their own key regardless of how aggressively it was obfuscated. Defending against that requires your backend rejecting requests from unattested/tampered clients (Play Integrity API), not more obfuscation.