AAR集成后ProGuard混淆致崩溃日志行号异常求助

Hey there, let's work through this tricky line number issue in your obfuscated AAR crash reports together! I've run into similar headaches before, so here are the most common fixes to get your crash logs pointing to the right code lines:

1. Double-Check Your AAR's ProGuard Rules #

First, make sure your AAR's proguard-rules.pro has the correct rules to preserve line numbers—sometimes even a tiny typo can break this. Add or confirm these lines are present:

# Preserve source file names and line numbers for crash debugging
-renamesourcefileattribute SourceFile
-keepattributes SourceFile,LineNumberTable

Also, watch out for conflicting rules that might override these. For example, if you're using aggressive optimizations like -optimizations code/simplification/inline, they can sometimes collapse code and mess up line number mapping. Temporarily disable optimizations to test if that fixes the line number issue.

2. Stop the Host App from Re-Obfuscating Your AAR #

Even if your AAR is properly obfuscated, the host app's ProGuard might re-process the AAR's classes, which scrambles the line numbers. Add this rule to the host app's proguard-rules.pro to exclude your AAR's package from re-obfuscation:

# Replace with your AAR's root package name
-keep class com.your.aar.package.** { *; }
-keepattributes SourceFile,LineNumberTable

This tells the host's ProGuard to leave your AAR's code and its line number metadata untouched.

3. Match the Exact Mapping File to Your AAR Version #

Crash logs only de-obfuscate correctly if you use the exact mapping.txt file generated for the crashing AAR version. Even tiny code changes between releases will shift the mapping, leading to wrong line numbers. Make sure you store each release's mapping.txt alongside your AAR artifacts (like in your Maven repo or build storage) so you can grab the right one when parsing crashes.

4. Align Build Types Between AAR and Host App #

If your AAR uses different ProGuard settings for debug vs release builds, ensure the host app is integrating the correct variant of the AAR. For example, if you're testing a release host build but accidentally pulled a debug AAR, the line numbers won't match—debug builds often have partial or no obfuscation.

5. Validate Your Crash Parsing Workflow #

When de-obfuscating, use the right tools correctly. For example, using Android Studio's built-in crash analyzer? Make sure you import both the host app's mapping.txt and the AAR's mapping.txt (if the crash involves both codebases). If you're using ProGuard's retrace tool, run this command to get accurate results:

retrace.sh -verbose path/to/aar/mapping.txt crash-stacktrace.txt

Double-check that you're pointing to the AAR's mapping file, not just the host app's.

内容的提问来源于stack exchange，提问作者droidev