Android Library AAR混淆:求清晰分步教程与最优实现方案
Hey there! I totally get how frustrating it can be to hunt down clear, step-by-step guides for obfuscating an Android Library (AAR) when you're just starting out—most answers online are scattered or assume you already know the basics. Let me walk you through a straightforward, beginner-friendly process, plus share some best practices to make this go smoothly.
1. Enable Obfuscation in Your Library's Build Config
First things first, open your library module's build.gradle file (not the root project's one—look for the folder with your library code, like :my-library).
Inside the android block, find the buildTypes section. We only want to obfuscate release builds (debug builds don't need it, since it slows down debugging). Update it to look like this:
android { buildTypes { release { // Turn on minification (obfuscation) minifyEnabled true // Use Google's default ProGuard rules + your custom rules proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro' } debug { // Keep debug builds unobfuscated for easier testing minifyEnabled false } } }
The proguard-android-optimize.txt file has Google's recommended base rules, and proguard-rules.pro is where you'll add your custom rules next.
2. Configure Custom ProGuard Rules (proguard-rules.pro)
This is the most important part—you need to tell ProGuard which parts of your library can't be obfuscated. If you skip this, apps using your AAR will crash because they won't find the classes/methods they need. Here's what to add:
a. Keep Your Public APIs
Any class, method, or field that other apps will use (your library's public interface) must stay unobfuscated. For example:
# Keep all public classes/methods/fields in your library's main package -keep public class com.your.library.package.** { public protected *; } # If you only want to keep specific public components, use this instead: # -keep public class com.your.library.package.MyPublicClass { # public void myPublicMethod(); # public String myPublicField; # }
Pro tip: Double-check your library's public API before setting this up—you don't want to accidentally obfuscate something users need.
b. Preserve Annotations
If your library uses annotations (like @Nullable, @SerializedName, or custom ones), ProGuard might strip them out unless you tell it not to:
# Keep all annotation attributes -keepattributes *Annotation* # If you have custom annotations, keep their usage on fields/methods -keepclassmembers class * { @com.your.library.annotations.MyCustomAnnotation <fields>; @com.your.library.annotations.MyCustomAnnotation <methods>; }
c. Protect Model/ Data Classes
If you have data classes used for serialization (Gson, Moshi) or databases (Room), don't obfuscate their fields—otherwise, the library won't be able to map data correctly:
# Example for Gson: Keep all model classes in your models package -keep class com.your.library.package.models.** { *; } # Example for Kotlin data classes with Moshi: -keepclassmembers class com.your.library.package.models.** { <init>(...); // Keep the constructor } -keepnames class com.your.library.package.models.** // Keep class names
d. Keep Native Methods (If You Use JNI)
If your library has native (C/C++) code, you need to keep the native method names so the JVM can find them:
-keepclasseswithmembernames class * { native <methods>; }
e. Add Rules for Third-Party Libraries
If your library depends on other libraries (like Retrofit, Glide), check their official docs for required ProGuard rules. For example, Retrofit needs these:
-keepattributes Signature -keepattributes Exceptions -keep class retrofit2.** { *; } -keepclasseswithmembers class * { @retrofit2.http.* <methods>; }
3. Test the Obfuscated AAR
Don't just build it and call it done—you need to make sure your obfuscated library still works as expected:
- Build the release variant: Run
./gradlew :your-library-module:assembleReleasein the terminal, or go to Build > Make Module 'your-library-module' in Android Studio. - Find the AAR file: It's in
your-library-module/build/outputs/aar/(look for something likemy-library-release.aar). - Create a test app: Add a new Android app module to your project, add the AAR as a dependency, and write code that uses every part of your library's public API.
- Run the test app in release mode: Switch the test app's build variant to Release (via Build > Select Build Variant) and launch it. Make sure there are no crashes, and all features work like they should.
4. Save the Mapping File for Debugging
When you obfuscate, ProGuard generates a mapping.txt file that maps obfuscated class/method names back to their original ones. This is critical for debugging crashes reported by users.
- You'll find it in
your-library-module/build/outputs/mapping/release/. - Store this file somewhere safe (like a cloud storage or version control) for every release—you'll need it if you ever have to de-obfuscate a stack trace.
- Only obfuscate release builds: Debug builds should stay unobfuscated to make it easier to fix issues while developing your library.
- Don't over-obfuscate: Only hide internal code that's not exposed to users. Keeping your public API clear is non-negotiable.
- Test after every change: Anytime you add new code to your library, re-test the obfuscated AAR to make sure nothing breaks.
- Document your public API: This helps you remember what needs to be kept in ProGuard rules, and makes it easier for users to work with your library.
内容的提问来源于stack exchange,提问作者Happy

