1. What Google actually asks for. Google's guidance is not 'obfuscate to hide secrets' - it is 'minify and obfuscate so reverse engineering gets more expensive, and keep the real security checks on your server.' The Android build documentation (https://developer.android.com/build/shrink-code) describes R8 as the default code shrinker in the Android Gradle plugin: it performs tree shaking, resource shrinking, optimisation and identifier renaming (obfuscation) in one pass, and Google is explicit that 'obfuscation is not a security feature by itself' - it raises the cost of casual reverse engineering but does not make a client trustworthy. The developer security guide (https://developer.android.com/privacy-and-security/security-best-practices) says the same thing from the other side: never ship secrets, API keys or server-side logic in the APK, because anything on the device can be read.
2. Turn R8 on for release builds. In your app module's build.gradle(.kts) the release build type should set minifyEnabled true (this is R8, which is ProGuard-compatible) and shrinkResources true, and reference proguard-rules.pro. Resource shrinking removes unused resources and only works when minifyEnabled is also on. R8 uses the optimised default rule file (proguard-android-optimize.txt), so beyond shrinking it also applies optimisations such as method inlining, class merging and unused-argument removal. Verify the effect by comparing debug vs release artifact size and by reading build/outputs/mapping/release/mapping.txt.
3. Keep rules are where most release crashes come from. R8 renames and deletes anything it believes is unreachable - including types it cannot see are used reflectively. The usual offenders are JSON parsers (Gson/Moshi/Jackson data classes), Retrofit interfaces and their @SerializedName models, Room entities, kotlinx.serialization, ViewBinding/DataBinding, Parcelable, XML-inflated custom views, and anything loaded by class name (Class.forName, JNI, service loaders). Production symptoms are NoSuchMethodException, ClassNotFoundException, empty or renamed JSON fields, or a crash that happens only in release and never in debug. Add narrow -keep rules (for example -keep class com.example.model.** { *; } for DTOs, -keepclassmembers for @SerializedName fields) rather than -keep everything, and always test the release build, not just debug. Kotlin often needs -keepclassmembers class **$WhenMappings plus metadata rules; AndroidX ships its own consumer rules that R8 merges automatically.
4. Upload mapping.txt so crash reports stay readable. R8 writes build/app/outputs/mapping/release/mapping.txt (plus configuration.txt and seeds.txt). Upload that file with the release to Play Console, or have your release pipeline do it, so Play Console de-obfuscates stack traces and ANRs for you. Without it, every production crash looks like a.a.a.b(Unknown Source) and you lose the ability to triage. Keep the mapping for every version you ship - a rebuilt release needs a new mapping file.
5. Never put the security decision on the client. This is the single most common design mistake: shipping an isPremium / LicenseValid / IsTampered flag that the app evaluates locally. Anything the client decides, the client can patch - a one-byte change with apktool or a Frida hook flips the flag. Move the decision to your backend: the app should send evidence (a token, a purchase token, an integrity verdict) and the server should decide. Concretely, verify Google Play Billing purchases server-side with the Play Developer API (purchases.subscriptionsv2 / purchases.products) instead of trusting the on-device acknowledgement, and treat any 'license check' that never leaves the device as decoration, not protection.
6. Play Integrity API is the supported way to get that server-side verdict. The Play Integrity API (https://developer.android.com/google/play/integrity) replaces the deprecated SafetyNet Attestation API. Your app calls it and receives an encrypted, signed, short-lived integrity verdict that must be decrypted and verified by Google's servers (or by your backend calling the Play Integrity API) - not on the device. The verdict carries device integrity signals (MEETS_BASIC_INTEGRITY / MEETS_DEVICE_INTEGRITY / MEETS_STRONG_INTEGRITY), an app integrity signal (the binary matches what you uploaded, which catches repackaged or modified APKs), and account/licensing signals (PLAY_RECOGNITION / LICENSED). Use Standard requests (recommended) rather than Classic requests, which are the legacy flow. You configure the API for your app in Play Console under App integrity and can watch verdict failure rates there. A failed verdict is a signal, not proof - Google warns against letting one failing device decide, so look for patterns and rate anomalies and do not lock out honest users. The daily request allowance scales with install base (10,000/day by default) and higher limits are requested via the form linked from https://support.google.com/googleplay/android-developer/answer/11395166 .
7. Signing, tamper detection and Play's one-click protection. Two layers. (a) App signing: modern apps use APK Signature Scheme v2/v3 (v4 for fast install). With Play App Signing, Google holds the app signing key while you keep the upload key, so a stolen keystore no longer equals a hijacked app, and the upload key can be rotated. You can compare the app's certificate at runtime against the one you expect, but remember that check is itself patchable - use it as a server-side signal. (b) Google Play's automatic protection ('Protected with Play', https://support.google.com/googleplay/android-developer/answer/13857328) is a one-click Play Console switch that layers runtime anti-tamper and anti-piracy detection into the app and reports when an installed binary does not match the store version; it needs no backend integration from you. Pair it with the Play Integrity app-integrity verdict rather than relying on either alone.
8. Harden the client, but assume it will be read. Beyond obfuscation: keep debuggable false and strip android:debuggable; remove logs in release (R8 can strip Log.d via -assumenosideeffects, or raise the log level); do not hardcode API keys, tokens or endpoints - fetch and rotate them at runtime; store device-side keys in the Android Keystore (https://developer.android.com/privacy-and-security/keystore) instead of embedding them; add certificate/public-key pinning so a fake server or a MITM proxy cannot drive your app; treat root/emulator/debugger detection as a soft signal only (trivially bypassed, but it raises cost and stops the average script); obfuscate or encrypt high-value string constants (endpoints, feature flags) with R8 string obfuscation or a commercial hardening tool when the asset justifies it; and move sensitive logic into NDK/native code only if you accept the build complexity - native is harder, not impossible, to reverse.
9. The policy dimension: clones, repackaging and the limits of obfuscation. Obfuscating your own app is legitimate and encouraged; using obfuscation to hide policy-violating behaviour from Google's review is not. Google's Developer Program Policy (https://support.google.com/googleplay/android-developer/answer/17190352) and its Malware (https://support.google.com/googleplay/android-developer/answer/9888380), Mobile Unwanted Software (https://support.google.com/googleplay/android-developer/answer/9970222) and Deceptive Behavior (https://support.google.com/googleplay/android-developer/answer/16680223) policies forbid apps that are deceptive, that conceal data collection or functionality, or that misuse device, network or personal data; an app that only works because its behaviour is hidden fails review and, if discovered after launch, is removed. On the other side, weak client protection is exactly what lets others repackage your app, strip your billing or clone it - the same policy pages are what you cite when you file an IP or malware report against a rip-off, and Play's impersonation/copycat rules cover lookalikes that copy your identity. Report infringing or malicious clones through the Play Console IP complaint form and the policy report paths.
10. Pre-release decompilation self-audit (do this once per release). (1) Build the release AAB/APK. (2) Point apktool/JADX at the release artifact - not debug - and read the decompiled output: confirm no readable class/method names expose business logic and no plaintext secrets remain. (3) Grep the APK for your API keys, endpoints, 'Bearer ', 'password', 'secret', 'http://' and debug flags (for example strings assets/* | grep -i key). (4) Run Frida on a rooted test device and try the two-minute attacks - flip your license/premium flag, hook the integrity call, read local storage; anything that succeeds must move server-side. (5) Confirm mapping.txt was produced and uploaded for this version. (6) Confirm Play Integrity and/or Protected with Play is enabled and that your backend actually rejects a failing verdict. If obfuscation is your only control, treat the app's data and premium logic as public.