[Microsoft.Android.Build.Tasks] Generate typemap ProGuard rules by simonrozsival · Pull Request #12821 · dotnet/android

simonrozsival · 2026-09-18T14:40:59Z

Why

R8 cannot see managed-to-Java JNI references. Keeping every entry in the
pre-trim ACW map preserves Java classes that managed trimming no longer
needs, while reading Register attributes is not a common representation
for all typemap implementations.

Generate Java class roots from the retained typemap instead, using a small
shared intermediate format and runtime-specific adapters.

Related to #10790, #11767, and #12814.

Implementation

All new tasks live in Microsoft.Android.Build.Tasks, under the
Microsoft.Android.Tasks namespace.

Runtime / typemap	Retained-key adapter input
CoreCLR / LLVM IR	Generated `.ll` Java-name blobs
CoreCLR / trimmable	Linked typemap DLLs and surviving TypeMap attributes
NativeAOT / trimmable	Final ILC native objects, selecting Java typemap groups through their fixups

Adapters emit ordinal-sorted, distinct JNI class names, one per line,
UTF-8 without a BOM, with LF endings. Representation-specific aliases and
array keys are normalized before producing the shared class-name file.
Missing or malformed required inputs fail rather than silently producing
an empty retention policy.

<GenerateTypeMapProguardConfiguration/> emits class-only keep rules.
Separate configuration handles runtime bootstrap roots and member
preservation. CoreCLR keeps all members of retained JNI-facing classes;
Java-only dependencies remain eligible for member shrinking. NativeAOT
retains the conservative all-members policy. There is no precise
JNI-method inference or runtime obfuscation work here.

The pipeline runs after the relevant trimming/typemap producer and before
R8. Exact per-RID producer paths are propagated and unioned; source-list
and property changes, deleted outputs, incremental builds and Clean are
covered.

NativeAOT no longer generates or scans DGML graphs for this purpose. Its
object adapter currently requires NDK LLVM tools and is explicitly opt-in.
The private $(_AndroidEnableTypemapR8Trimming) override disables or
selects the new pipeline; supported trimmed CoreCLR R8 builds use it
automatically when the override is unset. Complete
$(ProguardConfigFiles) overrides retain their existing behavior.

The active CoreCLR path enables R8 optimization while keeping obfuscation
disabled. Other runtime paths retain their configuration selection.

Validation

421 focused tests passed with warnings treated as errors and no skips,
including real NDK object fixtures, linked-assembly extraction, emitted
LLVM layouts, shared rule generation and MSBuild incremental contracts.
Built, installed and launched stock dotnet new android and MAUI
sample-content applications on ARM64, including Samsung A16 runs for
both CoreCLR typemaps and NativeAOT with trimmable typemaps.
Repeated startup comparisons used matching MIBC profiles where
applicable. Benchmark/profile artifacts and the reverted precise-member
proof of concept are not part of this PR.

For MAUI sample-content with full managed trimming, Release/ARM64 and
obfuscation disabled, total uncompressed DEX sizes were:

Runtime / typemap	Legacy rules	Retained-typemap pipeline
CoreCLR / LLVM IR	4,876,916 bytes	3,314,404 bytes
CoreCLR / trimmable	4,564,308 bytes	3,186,728 bytes
NativeAOT / trimmable	13,070,696 bytes	7,489,768 bytes

CoreCLR comparisons include enabling R8 optimization. With optimization
disabled on both sides, the respective DEX reductions were 3.85% and
0.086%; the NativeAOT reduction remained 42.70%. The Java-policy toggle
did not materially improve startup with matching MIBC profiles already
applied; this is principally a size improvement.

The MAUI template used the same compatible preview6 dependency pin on both
sides because its original preview7 dependencies produced CS1705 against
the locally built SDK. Trimming warnings were not suppressed.
NativeAOT/full sample-content builds retain a Dashboard-loading limitation
with both rule policies; this PR does not claim to fix it.

Scope and review organization

Visual Studio 2026 provides the supported hosting for these .NET tasks.
Standalone .NET Framework CLI MSBuild is outside the support scope; it is
not a readiness blocker for this change.

NativeAOT remains opt-in until the native-object tooling can be supplied
without requiring an NDK. NativeAOT with the LLVM typemap is unsupported
and is excluded from the results.

This changeset is being split into a stack of smaller review units. This
source PR will remain open until the replacement stack is complete and
verified.