Usage
To run ProGuard, just type:
java -jar proguard.jar options ...
You can find the ProGuard jar in the lib directory of the ProGuard distribution. Alternatively, the bin directory contains some short Linux and Windows scripts containing this command. Typically, you'll put most options in a configuration file (say, myconfig.pro), and just call:
java -jar proguard.jar @myconfig.pro
You can combine command line options and options from configuration files. For instance:
java -jar proguard.jar @myconfig.pro -verbose
You can add comments in a configuration file, starting with a # character and continuing until the end of the line.
Extra whitespace between words and delimiters is ignored. File names with spaces or special characters should be quoted with single or double quotes.
Options can be grouped arbitrarily in arguments on the command line and in lines in configuration files. This means that you can quote arbitrary sections of command line options, to avoid shell expansion of special characters, for instance.
The order of the options is generally irrelevant. For quick experiments, you can abbreviate them to their first unique characters.
The sections below provide more details:
Input/Output Options
Keep Options
Shrinking Options
Optimization Options
Obfuscation Options
Preverification Options
General Options
Class Paths
File Names
File Filters
Filters
Overview of Keep Options
Keep Option Modifiers
Class Specifications
Input/Output Options
@filename
Short for '-include filename'.
-include filename
Recursively reads configuration options from the given file filename.
-basedirectory directoryname
Specifies the base directory for all subsequent relative file names in these configuration arguments or this configuration file.
-injars class_path
Specifies the input jars (or wars, ears, zips, or directories) of the application to be processed. The class files in these jars will be processed and written to the output jars. By default, any non-class files will be copied without changes. Please be aware of any temporary files (e.g. created by IDEs), especially if you are reading your input files straight from directories. The entries in the class path can be filtered, as explained in the filters section. For better readability, class path entries can be specified using multiple -injars options.
-outjars class_path
Specifies the names of the output jars (or wars, ears, zips, or directories). The processed input of the preceding -injars options will be written to the named jars. This allows you to collect the contents of groups of input jars into corresponding groups of output jars. In addition, the output entries can be filtered, as explained in the filters section. Each processed class file or resource file is then written to the first output entry with a matching filter, within the group of output jars.
You must avoid letting the output files overwrite any input files. For better readability, class path entries can be specified using multiple -outjars options. Without any -outjars options, no jars will be written.
-libraryjars class_path
Specifies the library jars (or wars, ears, zips, or directories) of the application to be processed. The files in these jars will not be included in the output jars. The specified library jars should at least contain the class files that are extended by application class files. Library class files that are only called needn't be present, although their presence can improve the results of the optimization step. The entries in the class path can be filtered, as explained in the filters section. For better readability, class path entries can be specified using multiple -libraryjars options.
Please note that the boot path and the class path set for running ProGuard are not considered when looking for library classes. This means that you explicitly have to specify the run-time jar that your code will use. Although this may seem cumbersome, it allows you to process applications targeted at different run-time environments. For example, you can process J2SE applications as well as JME midlets or Android apps, just by specifying the appropriate run-time jar.
-skipnonpubliclibraryclasses
Specifies to skip non-public classes while reading library jars, to speed up processing and reduce memory usage of ProGuard. By default, ProGuard reads non-public and public library classes alike. However, non-public classes are often not relevant, if they don't affect the actual program code in the input jars. Ignoring them then speeds up ProGuard, without affecting the output. Unfortunately, some libraries, including recent JSE run-time libraries, contain non-public library classes that are extended by public library classes. You then can't use this option. ProGuard will print out warnings if it can't find classes due to this option being set.
-dontskipnonpubliclibraryclasses
Specifies not to ignore non-public library classes. As of version 4.5, this is the default setting.
-dontskipnonpubliclibraryclassmembers
Specifies not to ignore package visible library class members (fields and methods). By default, ProGuard skips these class members while parsing library classes, as program classes will generally not refer to them. Sometimes however, program classes reside in the same packages as library classes, and they do refer to their package visible class members. In those cases, it can be useful to actually read the class members, in order to make sure the processed code remains consistent.
-keepdirectories [directory_filter]
