R8: unconditional -dontobfuscate makes Google Play's Feb 2027 25% obfuscation requirement unachievable

[thimobuchheister]

Summary

proguard_xamarin.cfg — the config the SDK generates and passes to R8 on every $(AndroidLinkTool)=r8 build — contains an unconditional -dontobfuscate. There is no supported property to remove or override it, and no R8 CLI flag that can undo it. The result is that a .NET for Android app cannot produce an obfuscated classes*.dex at all.

That was a cosmetic difference until this month. Google Play has now announced a code-optimization requirement that makes it a compliance problem:

From February 2027, apps and games on Google Play will need to meet minimum optimization requirements. You will need to achieve a minimum of 25% optimization, obfuscation and shrinking for any app uploads to Play Console.

— https://support.google.com/googleplay/android-developer/answer/17492799

The requirement is scoped to non-negligible DEX: >10 MB for apps, >50 MB for games. Announcement: https://android-developers.googleblog.com/2026/08/app-quality-memory-optimization-secure-onboarding.html. Apps that miss the thresholds "may see store visibility impact" and may get a warning shown on their store listing.

Because obfuscation is one of the three metrics and .NET for Android pins it at zero, every .NET MAUI / .NET for Android app above 10 MB of DEX fails that metric by construction, regardless of how the developer configures their project.

Measured on a shipping app

.NET 10, Microsoft.Android.Sdk 36.1.69, $(AndroidLinkTool)=r8, Release, built on ubuntu-latest. Measured on the signed APK actually shipped to users:

classes.dex    8,570,180
classes2.dex   8,354,084
classes3.dex   7,644,760
classes4.dex   1,745,504
               ----------
               26,314,528 bytes = 25.1 MB DEX

R8 markers are present in all four, and full mode is in use:

~~R8{"backend":"dex","compilation-mode":"release","has-checksums":false,
     "min-api":26,"pg-map-id":"3bb8354","r8-mode":"full","version":"8.11.18"}

So shrinking and optimization do run. Obfuscation does not — zero renamed class descriptors in any of the four files:

Landroidx/activity/R$id;
Landroidx/activity/result/contract/ActivityResultContracts$PickVisualMedia$MediaCapabilities$$ExternalSyntheticApiModelOutline0;
...

Count of descriptors matching a minified shape (L(a-z0-9{1,2}/)+a-z0-9{1,2};): 0.

Root cause

proguard_xamarin.cfg is an embedded resource in Xamarin.Android.Build.Tasks.dll and begins:

# This is Xamarin-specific (and enhanced) configuration.

-dontobfuscate

-keep class android.support.multidex.MultiDexApplication { <init>(); }
-keep class net.dot.jni.** { *; <init>(); }
-keep class mono.MonoRuntimeProvider* { *; <init>(...); }
...

R8.cs writes it out inside CreateResponseFile() immediately before invoking r8, so no MSBuild target can get between generation and use. _CalculateProguardConfigurationFiles (Xamarin.Android.Common.targets) then includes it in @(_ProguardConfiguration), which Xamarin.Android.D8.targets passes as ProguardConfigurationFiles, and R8.cs emits one --pg-conf per entry.

The resource carries no comment explaining the flag, and I could not find an issue or PR discussing the decision.

Why the obvious workarounds do not work

1. $(AndroidR8ExtraArguments) cannot force minification back on. R8 8.11.18 (the version shipped in tools/r8.jar) has --no-tree-shaking, --no-minification, --no-data-resources and --no-desugaring, and no positive counterpart to any of them — there is no --minification / --obfuscate.

2. Appending another --pg-conf cannot cancel it. -dontobfuscate is order-independent and sticky, which I verified directly against the shipped r8.jar on a two-class fixture:

configs passed	result
b.cfg (no -dontobfuscate)	Ldemo/Helper; and secretMethodName both renamed
a.cfg (-dontobfuscate) then b.cfg	both names survive
b.cfg then a.cfg (-dontobfuscate) last	both names survive

3. $(ProguardConfigFiles) "works" but is not a safe answer. It replaces the entire default list, so proguard_xamarin.cfg is never passed and -dontobfuscate never reaches R8. But the same list also carries proguard_project_primary.cfg (the generated -keep for every Android Callable Wrapper) and proguard_project_references.cfg. Re-listing those by hand is required for the app to launch at all, means maintaining a copy of an SDK-internal keep file that drifts silently against the SDK, and fails as a launch crash rather than a build error. The property is also undocumented — it appears on no page under https://learn.microsoft.com/dotnet/android/building-apps/build-properties (which has zero hits for "obfuscat" or "minif" anywhere), and its only description in the tree is the Common.targets comment "to keep backwards compatibility".

Note on #11709

#11709 (merged 2026-06-23) already deals with disallowed global options in library proguard.txt files, and states that "the SDK-generated configs (proguard_xamarin.cfg, proguard_project_primary.cfg, etc.) are left untouched". So the neighbouring code was revisited recently and the global -dontobfuscate was deliberately retained — which is why I am raising this as its own issue rather than assuming it is an oversight.

Ask

Some supported way to opt in to R8 minification, with the SDK continuing to own the keeps that make it safe (ACWs, mono.*, net.dot.jni.*, bound types via GenerateProguardConfiguration). For example an $(AndroidEnableObfuscation) / $(AndroidR8Minification) property that omits -dontobfuscate from the generated config while leaving every generated -keep in place.

Two things that would help even without a full opt-in:

1. Guidance. If obfuscation is unsafe for .NET for Android for a structural reason, documenting that reason — and Microsoft's position on the February 2027 requirement — would let teams plan. Right now the build properties page does not mention obfuscation at all.
2. A supported seam, if the answer is "bring your own config": documenting $(ProguardConfigFiles) and giving a way to append to @(_ProguardConfiguration) minus the one file, so nobody has to hand-copy generated keeps.

Happy to test a fix against a real 25 MB-DEX app and report the resulting Play Console numbers.

Environment

• .NET 10, Microsoft.Android.Sdk.Windows 36.1.69 (tools/Version.commit: d549e1d, release/10.0.1xx)
• R8 8.11.18, r8-mode: full, min-api: 26
• Release build on ubuntu-latest; $(AndroidLinkTool)=r8, $(JavaMaximumHeapSize)=6G

[follesoe]

Independent reproduction on a second app, and I think one finding here changes the shape of the
ask: the blocker is not only -dontobfuscate. Removing it is necessary but not sufficient,
because the SDK's generated keep rules never emit field keeps, and .NET bindings read Java
fields by name through JNI.

Environment: .NET 10, Microsoft.Android.Sdk.Darwin 36.1.69, R8 8.11.18 (r8-mode: full),
min-api 26, .NET MAUI with native embedding + MvvmCross, AndroidEnableMultiDex=true.
Device-verified on a Galaxy Tab Active5 / Android 16 against live hardware.

1. Same starting point

With SDK defaults, $(AndroidLinkTool)=r8 shrinks but does not rename: 34 of 15,235 classes in
mapping.txt, 0.2%. Matches your numbers.

2. A seam that keeps the generated rules

$(ProguardConfigFiles) is unusable for the reason you give. But @(_ProguardConfiguration) is an
ordinary item list assembled in _CalculateProguardConfigurationFiles, so a target can edit it
between assembly and use — removing one entry while leaving all ~104 others in place:

<Target Name="_SwapProguardConfigs"
        AfterTargets="_CalculateProguardConfigurationFiles"
        Condition=" '$(AndroidLinkTool)' == 'r8' ">
  <ItemGroup>
    <_ProguardConfiguration Remove="$(IntermediateOutputPath)proguard\proguard_xamarin.cfg" />
    <_ProguardConfiguration Include="$(MSBuildThisFileDirectory)proguard-xamarin.cfg" />
  </ItemGroup>
</Target>

proguard_project_primary.cfg, proguard_project_references.cfg, aapt_rules.txt and every
AAR's consumer rules stay untouched. Two notes:

• -printmapping lived in the file that was dropped, so the mapping has to be requested via
  $(AndroidR8ExtraArguments) with --pg-map-output "$(AndroidProguardMappingFile)", set inside
  a target because _SetProguardMappingFileProperty assigns that property.
• The SDK still writes its proguard_xamarin.cfg even when it is no longer passed to R8, so the
  copy can be diffed against the SDK's on every build and the build failed on drift. That makes
  pinning a copy survivable across SDK upgrades.

3. The part that is not about -dontobfuscate

With obfuscation enabled the app died at startup, and the interesting one is this:

java.lang.NoSuchFieldError: no "I" field "left" in class "Landroidx/core/graphics/Insets;"
    at crc64….MainContainerView_OnApplyWindowInsetsListener.n_onApplyWindowInsets(Native Method)

proguard_project_references.cfg does keep that class:

-keep class androidx.core.graphics.Insets
-keepclassmembers class androidx.core.graphics.Insets {
   *** add(...);
   *** max(...);
   *** min(...);
   *** of(...);
   *** subtract(...);
   *** toCompatInsets(...);
   *** toPlatformInsets(...);
   *** wrap(...);
}

Nine methods, no fields. And mapping.txt confirms the consequence:

androidx.core.graphics.Insets -> androidx.core.graphics.Insets:
    int left -> a
    int top -> b
    int right -> c
    int bottom -> d

The class is preserved, the methods are preserved, and the fields the binding reads are renamed.
Across that whole generated file (47,187 lines) I count 28,874 method/ctor entries and zero
field entries. So GenerateProguardConfiguration appears to emit member keeps only for methods.
That is invisible today precisely because -dontobfuscate means a name that is never rewritten
cannot be lost — but it means an opt-in property alone would produce broken apps.

A second, smaller gap in the same vein: net.dot.android.ApplicationRegistration is resolved by
string via JNIEnv.FindClass from Android.App.Application.get_Context(), and nothing keeps it.
proguard_xamarin.cfg keeps net.dot.jni.** and net.dot.android.crypto.** but not this
sibling, so it becomes F4.a and the first managed call into Application.Context throws
ClassNotFoundException.

4. What made it work

Two rules on top of the config swap:

-keep class net.dot.android.** { *; }

-keepclassmembernames class * {
    <fields>;
}

-keepclassmembernames preserves member names without preserving the members, so unused fields
are still shrunk away — it costs renaming, not size. Scoped to fields only, since methods are
already covered by the generated rules.

With that in place, and proguard-android.txt swapped the same way to drop -dontoptimize:

	classes	methods	DEX uncompressed	obfuscated
AndroidLinkTool unset	23,462	184,985	24.33 MB	—
=r8, SDK defaults	15,220	118,807	13.51 MB	0.2%
+ obfuscation	15,220	118,808	12.23 MB	67.0%
+ optimization	12,015	94,723	10.73 MB	59.5%

Cold start, navigation, MAUI pages resolved through MvvmCross, drone discovery, telemetry over
protobuf/ZeroMQ and dive-log sync all behave normally. Notably -dontoptimize turned out to be
fine to remove once the field issue was fixed — I had initially misattributed the field crash to
optimization.

5. A trap worth documenting

Incremental builds silently hand R8 about half its configuration. _ExtractLibraryProjectImports
does not repopulate @(ProguardConfiguration) on an up-to-date build, so every AAR's consumer
rules and aapt_rules.txt drop out — 104 pg-conf entries became 49 with no warning, producing
ClassNotFoundException for classes named in the manifest and in layouts. Any R8 investigation
needs a clean obj/, and this cost me two wrong conclusions before I noticed.

6. Suggestion

An opt-in property that only omits -dontobfuscate would still ship broken apps unless
GenerateProguardConfiguration also emits field keeps for bound types. If emitting per-field rules
is too costly, a blanket -keepclassmembernames class * { <fields>; } in the generated config when
obfuscation is enabled would be a cheap and safe default — it constrains renaming only, not
shrinking.

Happy to test a patch against this app and report Play Console's optimization percentages.

[thimobuchheister]

Thank you — the field-keep finding is the important half of this and I had it wrong. My ask (a
property that only omits -dontobfuscate) would indeed have shipped broken apps. And you are right
that @(_ProguardConfiguration) is editable between assembly and use; I looked at
$(ProguardConfigFiles), rejected it for the reason you quote, and stopped there instead of looking
one level up at the item list. That seam keeps the generated keeps intact, which was my whole
objection.

Adding the one thing I can contribute that isn't in your report: Play Console's own scoring, which
you offered to go and get. For the SDK-default bundle in the opening post (25.1 MB DEX, r8-mode: full),
App Bundle Explorer → Details reports:

Field	Value
App optimization	Low
Optimization percentage	–
Obfuscation percentage	1%
Shrinking percentage	–
R8 configuration	–

Two things in that worth flagging.

The obfuscation number tracks mapping.txt closely. Play says 1%; you measured 34 of 15,235
classes renamed (0.2%) on your app. In our bundle the small non-zero share is R8's own synthetic
output — the dex is full of $$ExternalSyntheticApiModelOutline* types, which do get generated
names. So Play's obfuscation metric appears to be derived from the mapping, and it is the metric
that will move if the field-keep problem is solved.

Optimization and shrinking are not scored at all — they are dashes, not low numbers. The same
analysis pass produced a real value for obfuscation on the same bundle, so this does not look like a
rollout gap. The bundle does carry a mapping file: the SDK embeds it as
com.android.tools.build.obfuscation/proguard.map (Xamarin.Android.Common.targets), and Play
surfaces it as a 57.8 MB downloadable ReTrace mapping. So Play has the mapping and still declines to
score two of the three metrics, alongside an empty "R8 configuration" field.

I have not established why, and I want to be explicit that the following is a hypothesis rather
than a finding: it looks like those two fields are populated from build metadata that AGP emits and
.NET for Android does not, rather than from the dex or the mapping. If that is right, then the
February 2027 requirement needs two independent things from this SDK — the obfuscation work you have
mapped out here, and whatever metadata backs the other two fields — and fixing only the first
would leave an app scoring 25%+ obfuscation with two metrics still unscored. If someone on the team
knows what populates "R8 configuration", that would settle it quickly and I will stop guessing.

Happy to run your config-swap against this app and post the resulting Play Console numbers — a 25 MB
DEX Blazor-hybrid MAUI app with Firebase, OneSignal, GMS Ads, Play Billing and the Amazon Appstore
SDK is a fairly different Java closure from yours, so it should be a useful second data point on
whether the two rules are sufficient in general.

[thimobuchheister]

One follow-up that narrows the second half of this considerably.

AndroidAppBundleMetaDataFile already exists as a general-purpose item — Xamarin.Android.Common.targets:2269, consumed as MetaDataFiles="@(AndroidAppBundleMetaDataFile)" at :2464 and :2586 — and the SDK populates it with exactly one entry:

<AndroidAppBundleMetaDataFile
    Condition=" Exists('$(AndroidProguardMappingFile)') "
    Include="com.android.tools.build.obfuscation/proguard.map:$(AndroidProguardMappingFile)"
/>

The Include is <namespace>/<filename>:<source path>, so a project can add arbitrary BUNDLE-METADATA/ entries from its own csproj without any SDK change.

That lines up with the Play Console reading I posted above: obfuscation gets a real percentage and the other two are blank, and obfuscation is the one metric backed by a metadata file this SDK actually emits. I want to be clear this is correlation, not a demonstrated mechanism — I have not established what Play reads for the optimization and shrinking scores or for the empty "R8 configuration" field.

So the question that would unblock this for everyone is narrow: what BUNDLE-METADATA/ entry (namespace + filename) backs those, and is it something R8 already produces as a side output? If it is just a file, AndroidAppBundleMetaDataFile means app authors can emit it today and the SDK fix is a one-line ItemGroup addition next to the existing one — a much smaller change than the keep-rule work in this thread, and independent of it.

If anyone on the team can point at the AGP task that writes it, I am happy to do the digging from there and report back with Play Console numbers from both an SDK-default build and a fixed one.