Android 混淆打包之类名指定

Class Specifications

The template was designed to look very Java-like, with some extensions for wildcards. To get a feel for the syntax, you should probably look at the examples, but this is an attempt at a complete formal definition:

[@annotationtype] [[!]public|final|abstract|@ ...] [!]interface|class|enum classname
    [extends|implements [@annotationtype] classname]
[{
    [@annotationtype] [[!]public|private|protected|static|volatile|transient ...] <fields> |
                                                                      (fieldtype fieldname);
    [@annotationtype] [[!]public|private|protected|static|synchronized|native|abstract|strictfp ...] <methods> |
                                                                                           <init>(argumenttype,...) |
                                                                                           classname(argumenttype,...) |
                                                                                           (returntype methodname(argumenttype,...));
    [@annotationtype] [[!]public|private|protected|static ... ] *;
    ...
}]

Square brackets "[]" mean that their contents are optional. Ellipsis dots "..." mean that any number of the preceding items may be specified. A vertical bar "|" delimits two alternatives. Non-bold parentheses "()" just group parts of the specification that belong together. The indentation tries to clarify the intended meaning, but white-space is irrelevant in actual configuration files.

• The class keyword refers to any interface or class. The interface keyword restricts matches to interface classes. The enum keyword restricts matches to enumeration classes. Preceding the interface or enum keywords by a ! restricts matches to classes that are not interfaces or enumerations, respectively.
• Every classname must be fully qualified, e.g. java.lang.String. Inner classes are separated by a dollar sign "$", e.g. java.lang.Thread$State. Class names may be specified as regular expressions containing the following wildcards:

  ?	matches any single character in a class name, but not the package separator. For example, "mypackage.Test?" matches "mypackage.Test1" and "mypackage.Test2", but not "mypackage.Test12".
  *	matches any part of a class name not containing the package separator. For example, "mypackage.*Test*" matches "mypackage.Test" and "mypackage.YourTestApplication", but not "mypackage.mysubpackage.MyTest". Or, more generally, "mypackage.*" matches all classes in "mypackage", but not in its subpackages.
  **	matches any part of a class name, possibly containing any number of package separators. For example, "**.Test" matches all Testclasses in all packages except the root package. Or, "mypackage.**" matches all classes in "mypackage" and in its subpackages.

  For additional flexibility, class names can actually be comma-separated lists of class names, with optional ! negators, just like file name filters. This notation doesn't look very Java-like, so it should be used with moderation.

  For convenience and for backward compatibility, the class name * refers to any class, irrespective of its package.

• The extends and implements specifications are typically used to restrict classes with wildcards. They are currently equivalent, specifying that only classes extending or implementing the given class qualify. Note that the given class itself is not included in this set. If required, it should be specified in a separate option.
• The @ specifications can be used to restrict classes and class members to the ones that are annotated with the specified annotation types. An annotationtype is specified just like a classname.
• Fields and methods are specified much like in Java, except that method argument lists don't contain argument names (just like in other tools like javadoc and javap). The specifications can also contain the following catch-all wildcards:

  <init>	matches any constructor.
  <fields>	matches any field.
  <methods>	matches any method.
  *	matches any field or method.

  Note that the above wildcards don't have return types. Only the <init> wildcard has an argument list.

  Fields and methods may also be specified using regular expressions. Names can contain the following wildcards:

  ?	matches any single character in a method name.
  *	matches any part of a method name.

  Types in descriptors can contain the following wildcards:

  %	matches any primitive type ("boolean", "int", etc, but not "void").
  ?	matches any single character in a class name.
  *	matches any part of a class name not containing the package separator.
  **	matches any part of a class name, possibly containing any number of package separators.
  ***	matches any type (primitive or non-primitive, array or non-array).
  ...	matches any number of arguments of any type.

  Note that the ?, *, and ** wildcards will never match primitive types. Furthermore, only the *** wildcards will match array types of any dimension. For example, "** get*()" matches "java.lang.Object getObject()", but not "float getFloat()", nor "java.lang.Object[] getObjects()".

• Constructors can also be specified using their short class names (without package) or using their full class names. As in the Java language, the constructor specification has an argument list, but no return type.
• The class access modifiers and class member access modifiers are typically used to restrict wildcarded classes and class members. They specify that the corresponding access flags have to be set for the member to match. A preceding ! specifies that the corresponding access flag should be unset.

  Combining multiple flags is allowed (e.g. public static). It means that both access flags have to be set (e.g. public and static), except when they are conflicting, in which case at least one of them has to be set (e.g. at least public or protected).

  ProGuard supports the additional modifiers synthetic, bridge, and varargs, which may be set by compilers.