[Build] Fix JNI remapping counts lost on incremental builds by simonrozsival · Pull Request #11378 · dotnet/android

simonrozsival · 2026-05-16T08:28:10Z

Summary

Fix an incremental build bug where non-empty JNI remapping can be silently disabled after a C#-only incremental rebuild.

Problem

GenerateJniRemappingNativeCode registers JNI remapping counts as an in-memory MSBuild task object. GenerateNativeApplicationConfigSources later reads that task object and writes the counts into environment.*.ll.

For projects with _AndroidRemapMembers, the old _GenerateAndroidRemapNativeCode target had Inputs/Outputs. On an incremental build where that target was skipped as up-to-date but _GeneratePackageManagerJava re-ran, the registered task object was missing. GenerateNativeApplicationConfigSources then wrote zero remapping counts into environment.*.ll, disabling remapping at runtime.

The empty-remap target does not have this problem: when there are no remap members, zero counts are the correct generated output even if no task object is registered.

Fix

Remove Inputs/Outputs only from _GenerateAndroidRemapNativeCode, the non-empty remapping target. This ensures the task runs before _GeneratePackageManagerJava and registers the non-zero counts needed by GenerateNativeApplicationConfigSources.

Keep Inputs/Outputs on _GenerateEmptyAndroidRemapNativeCode, because skipped task data still correctly results in zero generated environment counts for the no-remap case.

Validation / Repro

This PR includes IncrementalBuildTest.JniRemappingCountsSurviveIncrementalBuild, which validates the observable generated output:

Create a Release CoreCLR XamarinAndroidApplicationProject with an _AndroidRemapMembers XML file containing one <replace-type> and one <replace-method>.
Build once and parse the generated obj/Release/android/environment.*.ll; both jni_remapping_replacement_type_count and jni_remapping_replacement_method_index_entry_count are 1.
Touch only MainActivity.cs and rebuild with doNotCleanupOnUpdate: true / saveProject: false.
Assert the generated environment counts are still 1 after the incremental rebuild.

I verified the test fails without this fix by temporarily restoring the old Inputs/Outputs metadata on _GenerateAndroidRemapNativeCode. In that baseline, the incremental rebuild rewrites environment.*.ll with both JNI remapping counts as 0, and the test fails with:

jni_remapping_replacement_type_count should be preserved.
Expected: 1
But was:  0

Validation command used:

./dotnet-local.sh test bin/TestDebug/net10.0/Xamarin.Android.Build.Tests.dll --filter "Name=JniRemappingCountsSurviveIncrementalBuild"

GenerateJniRemappingNativeCode registers JNI remapping counts (type and method replacement counts) as an in-memory MSBuild task object. On incremental builds where the remap target is skipped (outputs up to date) but _GeneratePackageManagerJava re-runs (e.g. due to assembly changes), GenerateNativeApplicationConfigSources finds no registered task object and writes zero counts into environment.ll. This silently disables JNI method remapping at runtime (jniRemappingInUse = false). Fix by persisting the counts to a file (jni_remapping_info.txt) alongside the generated jni_remap.ll sources. GenerateNativeApplicationConfigSources falls back to reading this file when the task object is not available. The info file is also added to both the remap targets' Outputs and the _GeneratePackageManagerJava target's Inputs, ensuring proper incremental build invalidation. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Verifies that building a project with JNI remapping produces a jni_remapping_info.txt file with the correct type and method replacement counts, and that these counts match the values in the generated environment.ll. Without the fix in the previous commit, this file would not be created and the test would fail at the file existence assertion. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…sed fallback The remap targets are very fast (small XML parse + LL file write) and already use CopyIfStreamChanged, so always running them has negligible cost. This ensures the registered task object is always available for GenerateNativeApplicationConfigSources, eliminating the incremental build bug without any new files or fallback logic. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…tal-build

Copilot

Pull request overview

Fixes an incremental build issue in the Android MSBuild pipeline where JNI remapping metadata (replacement counts) can be missing on builds that skip the remap generation targets, resulting in environment.ll being generated with zero counts and remapping being disabled at runtime.

Changes:

Removed Inputs/Outputs from _GenerateEmptyAndroidRemapNativeCode so it no longer gets skipped by MSBuild incremental target skipping.
Removed Inputs/Outputs from _GenerateAndroidRemapNativeCode for the same reason, ensuring the remapping task object is always registered for the current build.

Comments suppressed due to low confidence (2)

src/Xamarin.Android.Build.Tasks/Xamarin.Android.Common.targets:1638

With Inputs/Outputs removed, this target will run whenever it is invoked. Because the target also unconditionally Touches @(_AndroidRemapAssemblySource), the jni_remap.*.ll timestamps will change even when CopyIfStreamChanged keeps content identical, which will force _CompileNativeAssemblySources (Inputs include @(_AndroidRemapAssemblySource)) to re-run on incremental builds. Consider removing the Touch here (now that the target is always executed for task-object registration), or otherwise avoid updating timestamps when the generated file content didn’t change (e.g., only touch when missing).

This issue also appears on line 1652 of the same file.

        Condition=" '@(_AndroidRemapMembers->Count())' == '0' ">
  <GenerateJniRemappingNativeCode
      OutputDirectory="$(_NativeAssemblySourceDir)"
      GenerateEmptyCode="True"
      SupportedAbis="@(_BuildTargetAbis)"

src/Xamarin.Android.Build.Tasks/Xamarin.Android.Common.targets:1656

Same as the empty-code target: now that Inputs/Outputs are removed, this target will execute whenever invoked, and the unconditional Touch of @(_AndroidRemapAssemblySource) will update jni_remap.*.ll timestamps even when the generated content is unchanged. This can unnecessarily invalidate _CompileNativeAssemblySources and cause native recompiles on incremental builds. Consider removing the Touch, or making it conditional so timestamps only change when the .ll content actually changes or is missing.

        DependsOnTargets="$(_GenerateAndroidRemapNativeCodeDependsOn)"
        Condition=" '@(_AndroidRemapMembers->Count())' != '0' ">
  <GenerateJniRemappingNativeCode
      OutputDirectory="$(_NativeAssemblySourceDir)"
      RemappingXmlFilePath="$(_XARemapMembersFilePath)"

Verify JNI remapping counts survive a C#-only incremental rebuild so the remap native code target continues to populate the build-scoped task object before environment.ll is regenerated. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Assert the observable generated environment counts instead of requiring a specific target execution detail. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Only the non-empty remapping target needs to run every build to register non-zero JNI remapping counts. The empty target may remain incremental because skipped task data still correctly results in zero generated environment counts. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

simonrozsival and others added 3 commits May 16, 2026 10:27

simonrozsival added copilot `copilot-cli` or other AIs were used to author this trimmable-type-map labels May 20, 2026

simonrozsival marked this pull request as ready for review May 20, 2026 21:33

Merge branch 'main' into dev/simonrozsival/fix-jni-remapping-incremen…

845dab7

…tal-build

simonrozsival requested a review from jonathanpeppers as a code owner May 20, 2026 21:33

Copilot AI review requested due to automatic review settings May 20, 2026 21:33

Copilot started reviewing on behalf of simonrozsival May 20, 2026 21:33 View session

simonrozsival removed the trimmable-type-map label May 20, 2026

Copilot AI reviewed May 20, 2026

View reviewed changes

simonrozsival and others added 3 commits May 21, 2026 00:35

Fix JNI remapping regression test assertion

df9f24b

Assert the observable generated environment counts instead of requiring a specific target execution detail. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[Build] Fix JNI remapping counts lost on incremental builds#11378

[Build] Fix JNI remapping counts lost on incremental builds#11378
simonrozsival wants to merge 7 commits into
mainfrom
dev/simonrozsival/fix-jni-remapping-incremental-build

simonrozsival commented May 16, 2026 •

edited

Loading

Uh oh!

Copilot AI left a comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

simonrozsival commented May 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Problem

Fix

Validation / Repro

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

simonrozsival commented May 16, 2026 •

edited

Loading