Refactor and rename DexAnnotationSetRefList

Rename the class to ParameterAnnotationsList since the class is only
used for representing parameter annotations. Make `values` private and
replace it with a method that visits all the contained DexAnnotations.

Due to a javac bug that went unfixed for multiple Java versions, the JVM
specification does not require that the number of entries in the
ParameterAnnotations attribute of a method matches the number of
parameters in the method prototype; the number of ParameterAnnotations
entries may be less than the number of prototype parameters for methods
on inner classes.

Change DexParser to pass the actual number of prototype parameters to
ParameterAnnotationsList (in case parameters are missing annotations).

Make FileWriter use countNonMissing() and isMissing() to maintain the
broken ParameterAnnotations attribute created by the javac bug.
The JAR frontend and CF backend preserve the brokenness as they have
done since Id9d60243 32f87feeb, "CF backend: Preserve broken parameter
annotation attribute", 2018-05-03.

There are two ways of accessing the parameter annotations:
* Iterating over the list using forEachAnnotation()
* Using size(), get(i) and isMissing(i)

The forEachAnnotation() method visits all the DexAnnotations specified
in the ParameterAnnotations attribute.
In contrast, the size() and get(i) methods may be used to access the
annotations on individual parameters; these methods automatically shift
parameter annotations up to mitigate the javac bug. The isMissing(i)
accessor is used to determine whether the i'th parameter is missing in
the ParameterAnnotations attribute.

Also fix keepIf() throwing some parameter annotations away: For a method
with annotations on two parameters, if the predicate passed to keepIf()
throws away some annotations on the first and some on the second
parameter, then all of the annotations on the second would be kept
anyway. (Broken since the code was added in I6d6b2d04 19da09429
"Implement annotation removal.", 2017-03-10, in the old prerelease
repository.)

Change-Id: Ib47292a9c65b6fc696f6a5b922bfff7e467bbeb5
26 files changed
tree: 159342f84f4a7d1bbbd2bcb068e3aa6a2b6d17aa
  1. buildSrc/
  2. library-licensing/
  3. scripts/
  4. src/
  5. tests/
  6. third_party/
  7. tools/
  8. .gitignore
  9. AUTHORS
  10. build.gradle
  11. codereview.settings
  12. CONTRIBUTING.md
  13. copyAdditionalJctfCommonFiles.gradle
  14. LIBRARY-LICENSE
  15. LICENSE
  16. README.md
README.md

D8 dexer and R8 shrinker

The R8 repo contains two tools:

  • D8 is a dexer that converts java byte code to dex code.
  • R8 is a java program shrinking and minification tool that converts java byte code to optimized dex code.

D8 is a replacement for the DX dexer and R8 is a replacement for the Proguard shrinking and minification tool.

Downloading and building

The R8 project uses depot_tools from the chromium project to manage dependencies. Install depot_tools and add it to your path before proceeding.

The R8 project uses Java 8 language features and requires a Java 8 compiler and runtime system.

Typical steps to download and build:

$ git clone https://r8.googlesource.com/r8
$ cd r8
$ tools/gradle.py d8 r8

The tools/gradle.py script will bootstrap using depot_tools to download a version of gradle to use for building on the first run. This will produce two jar files: build/libs/d8.jar and build/libs/r8.jar.

Running D8

The D8 dexer has a simple command-line interface with only a few options.

The most important option is whether to build in debug or release mode. Debug is the default mode and includes debugging information in the resulting dex files. Debugging information contains information about local variables used when debugging dex code. This information is not useful when shipping final Android apps to users and therefore, final builds should use the --release flag to remove this debugging information to produce smaller dex files.

Typical invocations of D8 to produce dex file(s) in the out directoy:

Debug mode build:

$ java -jar build/libs/d8.jar --output out input.jar

Release mode build:

$ java -jar build/libs/d8.jar --release --output out input.jar

The full set of D8 options can be obtained by running the command line tool with the --help option.

Running R8

R8 is a Proguard replacement for whole-program optimization, shrinking and minification. R8 uses the Proguard keep rule format for specifying the entry points for an application.

Typical invocations of R8 to produce optimized dex file(s) in the out directory:

$ java -jar build/libs/r8.jar --release --output out --pg-conf proguard.cfg input.jar

The full set of R8 options can be obtained by running the command line tool with the --help option.

Testing

Typical steps to run tests:

$ tools/test.py --no_internal

The tools/test.py script will use depot_tools to download a lot of tests and test dependencies on the first run. This includes prebuilt version of the art runtime on which to validate the produced dex code.

Contributing

In order to contribute to D8/R8 you have to sign the Contributor License Agreement. If your contribution is owned by your employer you need the Corporate Contributor License Agreement.

Once the license agreement is in place, you can upload your patches using ‘git cl’ which is available in depot_tools. Once you have a change that you are happy with you should make sure that it passes all tests and then upload the change to our code review tool using:

$ git cl upload

On your first upload you will be asked to acquire credentials. Follow the instructions given by git cl upload.

On successful uploads a link to the code review is printed in the output of the upload command. In the code review tool you can assign reviewers and mark the change ready for review. At that point the code review tool will send emails to reviewers.

Getting help

For questions, reach out to us at r8-dev@googlegroups.com.

For D8, find known issues in the D8 issue tracker or file a new D8 bug report.

For R8, find known issues in the R8 issue tracker or file a new R8 bug report.