[Build] Fix JNI remapping counts lost on incremental builds

[simonrozsival]

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 could be skipped as up-to-date while _GeneratePackageManagerJava re-ran. In that case, the registered task object was missing, so GenerateNativeApplicationConfigSources 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

The remapping flow is:

_AndroidRemapMembers
  -> _CollectAndroidRemapMembers
     -> $(_XARemapMembersFilePath)
        -> _GenerateAndroidRemapNativeCode
           -> jni_remap.<abi>.ll
           -> in-memory JniRemappingNativeCodeInfo
              -> GenerateNativeApplicationConfigSources
                 -> environment.<abi>.ll

$(_XARemapMembersFilePath) is the output of _CollectAndroidRemapMembers, but it is an input to _GenerateAndroidRemapNativeCode. Changes to that merged XML must also invalidate _GeneratePackageManagerJava, because GenerateNativeApplicationConfigSources consumes the remap counts and writes them into environment.*.ll.

Make _GenerateAndroidRemapNativeCode use the same incremental input boundary as _GeneratePackageManagerJava, plus the merged remap XML:

Inputs="@(_GeneratePackageManagerJavaInputs);$(_XARemapMembersFilePath)"
Outputs="$(_AndroidStampDirectory)_GenerateAndroidRemapNativeCode.stamp"

The stamp file is needed because _GenerateAndroidRemapNativeCode has an important non-file side effect: it registers JniRemappingNativeCodeInfo in MSBuild's in-memory task-object cache. That object has no timestamp and disappears between builds.

If the target used jni_remap.*.ll as its outputs, MSBuild could skip the target because those files are up-to-date, but then the in-memory counts would not be registered. That is the original bug. If we explicitly touched jni_remap.*.ll, we would dirty native inputs and force unnecessary native recompilation.

The stamp records that the remap target ran for the same inputs that can cause environment.*.ll to be regenerated. If environment generation can skip, the remap target can skip too. If environment generation must run, the stamp is stale and remap generation runs first, recreating the in-memory counts.

Validation / Repro

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

1. Create a Release CoreCLR XamarinAndroidApplicationProject with an _AndroidRemapMembers XML file containing one <replace-type> and one <replace-method>.
2. 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.
3. Record the generated obj/Release/android/jni_remap.*.ll timestamps.
4. Touch only MainActivity.cs and rebuild with doNotCleanupOnUpdate: true / saveProject: false.
5. Assert the generated environment counts are still 1 after the incremental rebuild.
6. Assert the jni_remap.*.ll timestamps did not change when regenerated with unchanged contents.

Validation command used:

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

[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)"

[simonrozsival]

/review

[github-actions]

✅ Android PR Reviewer completed successfully!

[github-actions]

✅ LGTM — well-crafted incremental build fix

Summary: The fix correctly identifies that _GenerateAndroidRemapNativeCode has an in-memory side effect (JniRemappingNativeCodeInfo via RegisterTaskObject) that disappears between builds, so its Outputs can't be the .ll files alone. Switching to a stamp file tied to the same input boundary as _GeneratePackageManagerJava ensures the target re-runs whenever environment generation needs the counts.

What's good:

• Root cause analysis is thorough and the PR description explains the "why" behind each design choice (stamp vs touching .ll files, shared input boundary)
• Adding $(_XARemapMembersFilePath) to _GeneratePackageManagerJavaInputs correctly propagates remap XML changes to downstream targets
• The regression test validates both the observable output (environment counts) and the no-unnecessary-rebuild property (.ll timestamps)
• Test follows repo patterns (Touch + Build with doNotCleanupOnUpdate/saveProject: false)

CI: dotnet-android ✅ succeeded, license/cla ✅ passed. Xamarin.Android-PR not visible in checks — may need a maintainer trigger or re-run.

One minor 💡 suggestion inline about strengthening the test assertion.

Generated by Android PR Reviewer for issue #11378 · ● 12.6M

[github-actions]

🤖 💡 Testing — Consider asserting that _GenerateAndroidRemapNativeCode was actually skipped during the incremental build (e.g., b.Output.AssertTargetIsSkipped ("_GenerateAndroidRemapNativeCode")). This would directly verify the MSBuild target-skip behavior, making the test more diagnostic if it ever fails — you'd know whether the target ran unnecessarily vs. ran but produced wrong output.

Rule: Test assertions must be specific