Practical ProGuard obfuscation for Android releases

ProGuard for code obfuscation in Android is most useful when a release contains code that nobody needs to read after it ships. Shrinking, optimisation and name replacement make a package smaller and harder to analyse, but they do not make it secret. The practical goal is a reproducible build that preserves real behaviour while removing unused work.

Most current projects use R8, the modern Android replacement for ProGuard, with configuration expressed through familiar ProGuard-style rules. This work belongs on a developer machine or CI runner. If a DigitalOcean Droplet hosts the API, logging in via SSH to configure phpMyAdmin is a separate administrative task; obfuscation is part of application delivery, not server hardening.

Australian teams add a few practical wrinkles. Developers in Sydney and Melbourne often share release duties with colleagues in Brisbane and Perth, so the process must survive different working hours and devices. Australian organisations may distribute an APK through a managed-device portal rather than a public app store, and those working with government often expect controls aligned with Australian Signals Directorate guidance. In plain Aussie terms, the setup should be a fair dinkus, not a heroic afternoon before launch.

What obfuscation actually changes

Obfuscation has three related jobs. The shrinker removes unreferenced classes and methods, the optimiser simplifies bytecode, and the obfuscator replaces readable names with short generated ones. Resource shrinking can also discard unused assets. Together these steps reduce download size and reverse-engineering time, although none should be treated as encryption.

A normal release build may already use default optimisation rules. Your custom rules define exceptions: classes reached only through reflection, native code, dependency injection or serialisation must remain reachable. The smallest safe keep rule is better than a broad package-wide exemption, because every exception reduces optimisation and increases the chance of exposing internals.

Build mode	Unused code	Identifiers	Typical purpose
Debug build	Mostly retained	Fully readable	Day-to-day development
Minified release	Removed when safe	Shortened	Store or managed distribution
Custom keep rules	Preserved selectively	Obfuscated except required items	Reflection, JNI and JSON binding

Read R8 warnings as part of the build output, then remove obsolete rules after each dependency upgrade. The release mapping.txt file is essential for translating a production stack trace back to source names, so decide where it will be stored before the first obfuscated launch.

Configure the release build

In the Groovy DSL, enable minification and resource shrinking for the release variant in app/build.gradle. Keep the standard Android rules and add project-specific exceptions in proguard-rules.pro:

android {
    buildTypes {
        release {
            minifyEnabled true
            shrinkResources true
            proguardFiles(
                getDefaultProguardFile("proguard-android-optimize.txt"),
                "proguard-rules.pro"
            )
        }
    }
}

The default proguard-android-optimize.txt file enables the standard optimiser, while the local rules file protects application contracts. Start with no custom exceptions, run the app, and add narrow rules only when a reproducible failure identifies a genuine requirement. Broad -keep class com.example.** { *; } blocks hide real problems.

Reusable build patterns are worth keeping close to the project. This Magik snippet workflow demonstrates how snippets can be organised for quick reuse, a habit that translates neatly to Gradle blocks and keep expressions. Store shared patterns in source control so another developer in Adelaide or overseas can inspect them.

Preserve code reached indirectly

A missing keep rule often appears as ClassNotFoundException, NoSuchMethodError, a blank JSON field or an unresolved dependency-injection binding. These failures occur because a framework looks up a name that the optimiser removed or renamed. The affected path may be obvious in source yet invisible during static call analysis.

Add the narrowest rule that matches the failing contract. For example:

# Keep an explicitly retained entry point
-keep public class com.example.app.MainActivity

# Preserve Gson metadata and annotated fields
-keepattributes Signature,*Annotation*
-keep,allowobfuscation,allowoptimization class com.google.gson.reflect.TypeToken
-keep,allowobfuscation,allowoptimization class * extends com.google.gson.reflect.TypeToken
-keepclassmembers,allowobfuscation class * {
    @com.google.gson.annotations.SerializedName <fields>;
}

Treat each exception as technical debt with an owner and a reason. Prefer a library’s consumer rules for Gson, Moshi, Retrofit or JNI, and document bespoke rules beside the feature that needs them. Re-test after every Android Gradle Plugin or dependency upgrade, because R8’s analysis and default rules can change.

Verify the release artefact

A green debug test says little about an obfuscated release. Build the signed release variant, run the relevant tests, and install the exact package intended for users. A short smoke test should cover startup, authentication, navigation, network data, notifications and deep links.

Build and rule checks

• Build both assembleRelease and bundleRelease with the same rules.
• Run unit and instrumentation tests against minified output where practical.
• Exercise login, JSON round trips, push notifications and deep links.
• Review R8 missing-rule warnings and remove obsolete exemptions.

After code checks, verify the packaged output and its delivery path:

Distribution checks

• Archive mapping.txt with the build number and commit hash.
• Upload the mapping file to Play Console when using Play App Signing.
• Test the exact APK installed through enterprise mobile-device management.
• Confirm analytics and crash reporting retain readable source names.

Make this a release gate, not an occasional cleanup task. Australian teams can assign it to the on-call engineer in Melbourne while a colleague in Brisbane checks the store listing, without relying on office hours or a quick verbal handover.

Roll out with confidence and traceability

Automate the release build in CI, publish the app bundle, and save the mapping file as a restricted build artefact. Include the commit hash, tool versions and test results in the release record. A repeatable pipeline gives teams in Sydney, Perth and smaller regional offices the same auditable result without depending on one developer’s local setup.

Obfuscation raises the cost of analysis; it does not protect embedded credentials. Keep API secrets and database passwords on a secured backend, and restrict phpMyAdmin access to a VPN or an SSH tunnel. Obfuscated code should never become a reason to leave a private key, admin password or customer record inside the package.

Enable the release configuration in a branch, build a signed app bundle, exercise the critical user journeys and archive the mapping file with the release record. Make that check part of every production release so the next Android artefact is smaller, harder to inspect and no less reliable.