The D8 and R8 compilers support generating a compiler-input dump for use in reproducing compiler issues.
The dump contains almost all of the inputs that are given to the compiler as part of compilation. In particular, it contains all class definitions in the form of Java classfiles (i.e., bytecode, not the Java source files). If resource shrinking is enabled, the dump also contains all resources (i.e., the manifest, all res folder entries in proto and raw format, and any other file flowing into resource shrinking). In addition to the classfiles, the dump also includes Java resources, the compiler type, version, and flags, such as --debug or --release, main-dex lists or rules, and more. For R8 the dump also contains the full concatenation of all keep rules.
The dump is a zip file containing the above. You should unzip it and review the content locally. The program, classpath, library and resource content will be in nested zip files. The remaining content is in plain text files.
To generate a dump file, run the compiler with the com.android.tools.r8.dumpinputtofile system property set:
java -cp r8.jar -Dcom.android.tools.r8.dumpinputtofile=mydump.zip com.android.tools.r8.D8 <other-compiler-args>
This will generate a dump file mydump.zip and exit the compiler with a non-zero exit value printing an error message about the location of the dump file that was written.
For some builds, there may be many compilations taking place which cannot be easily isolated as individual compilation steps. If so, the system property com.android.tools.r8.dumpinputtodirectory can be set to a directory instead. Doing so will dump the inputs of each compilation to the directory in individual zip files and they will be named using a timestamp in an attempt to maintain an order. The compiler will compile as usual thus not disrupting the build.
To generate a dump from studio, the system property should be set for the build command. This can typically be done by amending the command-line gradle build-target command. Say your build target is assembleRelease, you would run:
./gradlew assembleRelease -Dorg.gradle.caching=false -Dcom.android.tools.r8.dumpinputtofile=mydump.zip --no-daemon
If the build is a debug build, such as assembleDebug, then it will likely be an incremental D8 build in which case the best option is to provide a dump directory and then locate the particular dump file associated with the problematic compilation (if the compilation fails, the interesting dump will hopefully be the last dump):
./gradlew assembleDebug -Dorg.gradle.caching=false -Dcom.android.tools.r8.dumpinputtodirectory=mydumps/ --no-daemon
For R8 compilations you can generate dumps with the R8_DUMP_DIRECTORY environment variable. This will put dumps for all R8 compilations leading up to the target that you are building. For a specific target you can do:
mkdir /tmp/dumps R8_DUMP_DIRECTORY=/tmp/dumps m -j77 SystemUI
The actual dump file for SystemUI will be the last dump in /tmp/dumps.
To reproduce a compiler issue with a dump use the script tools/compiledump.py from the R8 repository. Note that the script is not a standalone script so you will need a full checkout of the R8 project.
Reproducing should then be just:
./tools/compiledump.py -d mydump.zip
Depending on the compiler version that generated the dump additional flags may be needed to specify the compiler and its version. Run --help for a list of options.
The flags can also be used to override the setting specified in the dump. Doing so allows compiling with other compiler versions, or other settings.