Description
R8 by default?
Context: https://developer.android.com/studio/preview/features/#R8-enabled
We are already planning to enable D8 by default in some future Xamarin.Android release.
In the current Android Studio preview, R8 is enabled by default. (not just D8!)
To turn R8 off, you can add the following to your build.gradle
:
// android.enableR8 is true by default
android.enableR8 = false
Looking through the details minifyEnabled
also defaults to false
.
Given R8's help output:
Usage: r8 [options] <input-files>
where <input-files> are any combination of dex, class, zip, jar, or apk files
and options are:
--release # Compile without debugging information (default).
--debug # Compile with debugging information.
--output <file> # Output result in <file>.
# <file> must be an existing directory or a zip file.
--lib <file> # Add <file> as a library resource.
--min-api # Minimum Android API level compatibility.
--pg-conf <file> # Proguard configuration <file>.
--pg-map-output <file> # Output the resulting name and line mapping to <file>.
--no-tree-shaking # Force disable tree shaking of unreachable classes.
--no-minification # Force disable minification of names.
--no-desugaring # Force disable desugaring.
--main-dex-rules <file> # Proguard keep rules for classes to place in the
# primary dex file.
--main-dex-list <file> # List of classes to place in the primary dex file.
--main-dex-list-output <file> # Output the full main-dex list in <file>.
--version # Print the version of r8.
--help # Print this message.
We think Android Studio is running R8 by default with --no-minification
.
This means:
- They are using "tree shaking" by default. (Removing unreachable classes)
- They are using "desugar" by default.
I suspect the --no-minification
switch is used, merely because it
speeds up the build and perhaps it breaks Java debugging in some way?
Investigation
To be confident in what is actually happening, we should create a Java
class in Android Studio Preview that is using R8 by default. We should
create an instance of the Java type and call it via Java's reflection
APIs and see if that breaks.
If such Java reflection fails, then likely the "tree shaking" feature
is for sure being used. C# will likely fail in the exact same way as
Java refection, unfortunately.
We can test such a configuration in Xamarin.Android by doing:
<AndroidDexTool>d8</AndroidDexTool>
<AndroidLinkTool>r8</AndroidLinkTool>
<AndroidR8ExtraArguments>--no-minification</AndroidR8ExtraArguments>
NOTE: This project should have no proguard configuration files.
We will need to see what happens to a "hello world" Xamarin.Forms app
using this combination.
Implementation
A big TODO here. More investigation is needed.