咨询ProGuard指定规则含义及模型类不混淆的配置方案
Let's break down each part of this ProGuard configuration clearly:
-ignorewarnings: This flag tells ProGuard to suppress all warning messages it would normally output. This includes warnings about missing classes, conflicting rules, or potential issues with your configuration. While it might silence noisy logs, it’s generally not recommended for production—hiding warnings can mask real problems that could break your app later.-keep class * { public private *; }:- The
*wildcard matches every class in your codebase. - The block
{ public private *; }means "retain all public and private members (fields and methods) of these classes". Protected members would still be eligible for obfuscation with just this rule.
- The
-keep class * { public private protected *; }:- This is a broader version of the previous rule. It again targets all classes, but this time retains all members regardless of their access modifier (public, private, protected).
- Critically, this rule completely overrides the first
-keeprule—since it covers all access levels, the first rule’s more restricted scope becomes redundant.
Putting it all together: This configuration tells ProGuard to skip obfuscating every class name and every class member in your app, while ignoring any warnings that pop up during the process. It’s essentially a "disable obfuscation entirely" setup, which defeats the purpose of using ProGuard in most cases.
If you have model classes (often used for serialization/deserialization, like with JSON libraries) that you don’t want to obfuscate—especially their class names, field names (the "keys" you’re referring to), and getter/setter methods—here’s how to configure ProGuard properly:
Basic Rule (Target a Specific Package)
First, assume your model classes live in a dedicated package like com.yourapp.models (replace this with your actual package path). Use this rule to retain everything critical:
# Keep all model classes and their members -keep class com.yourapp.models.** { # Retain all fields (including private ones—critical for "key" matching in serialization) <fields>; # Retain all getter methods (e.g., getName(), getAge()) public ** get*(); # Retain all setter methods (e.g., setName(), setAge()) public void set*(***); }
What Each Part Does:
com.yourapp.models.**: The**wildcard matches all classes and sub-packages undercom.yourapp.models.<fields>: Preserves all fields (regardless of access modifier) so their original names stay intact—this is key for tools like Gson or Moshi that map JSON keys to field names.public ** get*(): Keeps all public methods starting withget(your getter methods) from being renamed.public void set*(***):: Preserves all public setter methods starting withset, ensuring they still work with data binding or serialization libraries.
If You Need Even More Specificity
If some model classes have "key" fields you want to explicitly protect (e.g., fields named id, apiKey, or any field with "key" in the name), you can add an extra rule to target those specifically:
# Explicitly retain fields with "key" in their name (case-insensitive) -keepclassmembers class com.yourapp.models.** { *** *key*; }
Why This Matters
Obfuscating model classes or their members would break serialization/deserialization: libraries rely on matching original class names, field names, or getter/setter names to external data (like JSON keys). If these get renamed, your app won’t be able to parse or generate the correct data.
内容的提问来源于stack exchange,提问作者Ali Akram

