Skip to content

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

Draft
simonrozsival wants to merge 2 commits into
mainfrom
dev/simonrozsival/fix-jni-remapping-incremental-build
Draft

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

Conversation

@simonrozsival
Copy link
Copy Markdown
Member

@simonrozsival simonrozsival commented May 16, 2026

Summary

Fix an incremental build bug where JNI method remapping gets silently disabled.

Problem

GenerateJniRemappingNativeCode registers remapping counts (type and method replacement counts) as an in-memory MSBuild task object via BuildEngine4.RegisterTaskObjectAssemblyLocal. On incremental builds where the remap target is skipped (its outputs are up to date) but _GeneratePackageManagerJava re-runs (e.g. due to a changed framework assembly), GenerateNativeApplicationConfigSources finds no registered task object and writes zero counts into environment.ll. This sets jniRemappingInUse = false at runtime, causing NoSuchMethodError for any remapped methods.

Repro

  1. Build a project with JNI remapping configured (e.g. Mono.Android.NET-Tests)
  2. Modify a source file in Mono.Android (not the remap config) and rebuild
  3. The remap target is skipped but _GeneratePackageManagerJava re-runs
  4. environment.ll now has jni_remapping_replacement_type_count = 0
  5. JNI method remapping tests fail with NoSuchMethodError

Fix

  • GenerateJniRemappingNativeCode now persists the counts to a jni_remapping_info.txt file alongside the generated .ll sources
  • GenerateNativeApplicationConfigSources falls back to reading this file when the task object is not available (i.e. the remap target was skipped)
  • The info file is added to both remap targets' Outputs and _GeneratePackageManagerJava's Inputs, ensuring proper incremental build invalidation in both directions

Test

  • JniRemappingInfoFileRoundTrip — builds a project with JNI remapping, verifies jni_remapping_info.txt is created with correct counts, and confirms the counts match the generated environment.ll

simonrozsival and others added 2 commits May 16, 2026 10:27
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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant