Mobile Development 24 min read

How to Tackle Proguard/R8 Code Decay in Android Apps – A Practical Guide

This article explains the hidden problem of engineering decay in Android app development, introduces Proguard/R8 core functions, details global and keep configurations, showcases detection tools and governance practices, and provides actionable steps to reduce build time and APK size.

Alibaba Terminal Technology
Alibaba Terminal Technology
Alibaba Terminal Technology
How to Tackle Proguard/R8 Code Decay in Android Apps – A Practical Guide

Engineering decay is a subtle yet painful issue that appears during app iteration, affecting development efficiency, product quality, stability, APK size and performance. Unlike a one‑time fix, it requires continuous, sustainable governance.

Basic Knowledge

In Android (Java) development, “code Proguard” refers to using the Proguard tool to shrink, optimize and obfuscate Java code, removing dead code, improving logic and shortening symbols. Google now replaces Proguard with the self‑developed R8 in recent Android Gradle Plugin versions, but the term still denotes the processing steps.

Function Introduction

Shrink : static analysis of code references to delete unused classes, fields, methods and resources, reducing APK size.

Optimize : deep analysis of execution logic to remove dead branches, inline methods, and apply dozens of optimizations, decreasing runtime method execution time.

Obfuscate : shorten class, field and method names to further shrink the APK and raise the difficulty of reverse engineering.

A typical processing flow alternates shrink and optimize, possibly looping multiple times (R8 does not allow configuring loop count).

Proguard processing flow
Proguard processing flow

Configuration Items

Proguard offers powerful configuration options, divided into global configurations and keep configurations. R8 disables many global options for consistency.

Global Configuration

Shrink configuration : e.g., -dontshrink disables shrinking; -whyareyoukeeping explains why a class is kept.

# Example: class TestProguardMethodOnly is kept directly by a keep rule
# Proguard result shows the shortest path
com.example.myapplication.proguard.TestProguardMethodOnly
  is kept by a directive in the configuration.

Keep Configuration

Keep rules specify classes, fields or methods that must not be removed or obfuscated. Types include:

Direct keep: -keep (no shrink, no obfuscate).

Keep names: -keepnames (allow shrinking, no obfuscate).

Keep class members: -keepclassmembers (no shrink, no obfuscate for members).

Conditional keep: -keepclasseswithmembers, -keepclasseswithmembernames, etc.

# Sample keep rule
-keep class com.example.myapplication.proguard.TestProguardFieldOnly { *; }

Tool Selection

Android developers can choose between Proguard and R8. R8 offers faster processing and better results, with two modes:

Normal mode – compatible with Proguard.

Full mode – more aggressive optimizations; enable via android.enableR8.fullMode=true in gradle.properties.

Proguard vs R8
Proguard vs R8

Custom Configuration

Custom rules are added per module. The source of each keep rule can be traced, and tools can detect which modules contribute which rules.

# Project:app:1.0
|-- -keepclasseswithmembers class com.example.myapplication.proguard.** { *; }
|-- -keepclassmembers class com.example.myapplication.proguard.** { *; }
|-- -keep class com.example.libraryaar1.CustomImageView { <init>(...); }

Governance Practice

Two main problems arise over time:

Global configuration changes unintentionally affect stability, size and performance.

Keep rules accumulate, increasing build time and APK size.

Detection tools were built to:

List keep rules per module.

Show which classes are hit by each keep rule.

Identify unused keep rules.

* -keep class com.youku.android.widget.TextSetView { <init>(...); }
|-- com.youku.android:moduleOne:1.21.407.6
    |-- com.youku.android.widget.TextSetView

Analysis, processing and verification steps differ for unused, redundant and over‑retained rules, with verification relying on generated usage.txt, mapping.txt and seeds.txt files.

Governance Panorama

After cleaning 20% of keep rules (758 out of 3812), build time for Proguard decreased by 18%. Future work includes centralizing keep rule management, white‑listing necessary rules, and gradually eliminating redundant and over‑retained rules.

Keep rule distribution
Keep rule distribution

What Else Can Be Done

Further research will target detection of redundant and over‑retained keep rules, and systematic cleanup of legacy keep configurations.

References

Proguard official documentation: https://www.guardsquare.com/manual/configuration/usage

R8 official documentation: https://developer.android.com/studio/build/shrink-code

consumerProguardFiles documentation: https://developer.android.com/studio/projects/android-library.html#Considerations

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

AndroidR8ProGuardCode ShrinkingKeep Rules
Alibaba Terminal Technology
Written by

Alibaba Terminal Technology

Official public account of Alibaba Terminal

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.