ProGuard can be run as a task in the Java-based build tool Gradle
(version 2.1 or higher).
Before you can use the proguard task, you have to make sure
Gradle can find it in its class path at build time. One way is to add the
following line to your build.gradle file:
Specifies the names of the output jars (or aars, wars, ears, zips, apks, or
directories). The files are resolved and written lazily, during the
execution phase.
Write out the entire configuration in traditional ProGuard style, to the
standard output or to the given file. Useful to replace unreadable
XML configurations.
Files are specified as Gradle files, which means they can be specified
as simple strings, as File instances, with file(Object), etc.
In Gradle, file names (any strings really) in double quotes can contain
properties or code inside ${...}. These are automatically
expanded.
For example, "${System.getProperty('java.home')}/lib/rt.jar" is
expanded to something like '/usr/local/java/jdk/jre/lib/rt.jar'.
Similarly, System.getProperty('user.home') is expanded to the
user's home directory, and System.getProperty('user.dir') is
expanded to the current working directory.
A class specification is a template of classes and class members (fields and methods). There are two alternative ways to specify such a template:
As a string containing a ProGuard-style class specification. This is the
most compact and most readable way. The specification looks like a Java
declaration of a class with fields and methods. For example:
keep 'public class mypackage.MyMainClass { \
public static void main(java.lang.String[]); \
}'
As a Gradle-style setting: a method calls with named arguments and a
closure. This is more verbose, but it might be useful for programmatic
specifications. For example:
The closure of a Gradle-style class specification can specify class members
with these settings:
fieldfield_constraints
Specifies a field.
methodmethod_constraints
Specifies a method.
constructorconstructor_constraints
Specifies a constructor.
A class member setting can have the following named arguments to express
constraints:
access: 'access_modifiers'
The optional access modifiers of the class. Any space-separated list of
"public", "protected", "private", "static", etc., with optional negators
"!".
'annotation': 'annotation_name'
The optional fully qualified name of an annotation of the class member,
with optional wildcards.
type: 'type'
The optional fully qualified type of the class member, with optional
wildcards. Not applicable for constructors, but required for methods for
which the parameters argument is specified.
name: 'name'
The optional name of the class member, with optional wildcards. Not
applicable for constructors.
parameters: 'parameters'
The optional comma-separated list of fully qualified method parameters,
with optional wildcards. Not applicable for fields, but required for
constructors, and for methods for which the type argument is
specified.
The named arguments are optional. Without any arguments, there are no
constraints, so the settings match all constructors, fields, or methods.
Gradle automatically converts the elements and attributes to Groovy methods,
so converting the configuration is essentially mechanical. The one-on-one
mapping can be useful, but the resulting configuration is more verbose. For
instance: