Skip to content

[CoreCLR] Track libxamarin-app.so as a _BuildApkFastDev input#12205

Merged
jonathanpeppers merged 8 commits into
dotnet:mainfrom
kotlarmilos:dev/kotlarmilos/fastdev-typemap-input
Jul 23, 2026
Merged

[CoreCLR] Track libxamarin-app.so as a _BuildApkFastDev input#12205
jonathanpeppers merged 8 commits into
dotnet:mainfrom
kotlarmilos:dev/kotlarmilos/fastdev-typemap-input

Conversation

@kotlarmilos

@kotlarmilos kotlarmilos commented Jul 22, 2026

Copy link
Copy Markdown
Member

Fixes #12201

The _BuildApkFastDev target packages the generated typemap library @(_ApplicationSharedLibrary) into the APK but does not list that item in _BuildApkFastDevStaticInputs, so when a source edit changes the app assembly MVID and _CreateApplicationSharedLibraries relinks libxamarin-app.so with a new CoreCLR Debug typemap, MSBuild treats the target as up to date and skips repackaging, after which

Fast Deploy pushes the new assembly to .__override__ while the installed APK keeps the stale typemap and the managed to Java lookup resolves an application Activity to java.lang.Object and raises ActivityNotFoundException on the next launch. The mismatch surfaces on CoreCLR because its Debug typemap is MVID keyed by #10065 and the Mono typemap is independent of the MVID.

Copilot AI review requested due to automatic review settings July 22, 2026 07:12
The `_BuildApkFastDev` target packages the generated typemap library
`@(_ApplicationSharedLibrary)` into the APK but does not list that item in
`_BuildApkFastDevStaticInputs`, so when a source edit changes the app assembly
MVID and `_CreateApplicationSharedLibraries` relinks `libxamarin-app.so` with a
new CoreCLR Debug typemap, MSBuild treats the target as up to date and skips
repackaging, after which Fast Deploy pushes the new assembly to `.__override__`
while the installed APK keeps the stale typemap and the managed to Java lookup
resolves an application `Activity` to `java.lang.Object` and raises
`ActivityNotFoundException` on the next launch. The mismatch surfaces on CoreCLR
because its Debug typemap is MVID keyed by dotnet#10065 whereas the Mono typemap is
independent of the MVID, and the missing input has existed since
`_BuildApkFastDev` moved into this repository in dotnet#9364, so adding
`@(_ApplicationSharedLibrary)` to `_BuildApkFastDevStaticInputs` to match the
sibling `_BuildApkEmbedInputs` rebuilds and reinstalls the APK whenever the
typemap library changes and fixes dotnet#12201.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: fd64bd8f-1056-4745-8aad-7e13d81dfad7
@kotlarmilos
kotlarmilos force-pushed the dev/kotlarmilos/fastdev-typemap-input branch from 34bd7ca to a595dcb Compare July 22, 2026 07:15

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR fixes an incremental build/install correctness issue in Fast Deploy by ensuring _BuildApkFastDev is considered out-of-date when the app typemap shared library (libxamarin-app.so, @(_ApplicationSharedLibrary)) changes (e.g., due to an assembly MVID change in CoreCLR Debug typemaps), and adds CI smoke coverage to run the test app under Mono as well.

Changes:

  • Add @(_ApplicationSharedLibrary) to _BuildApkFastDevStaticInputs so _BuildApkFastDev repackages/reinstalls when libxamarin-app.so changes.
  • Add an additional package-test instrumentation run intended to exercise the Mono runtime path in CI.
Show a summary per file
File Description
src/Xamarin.Android.Build.Tasks/Xamarin.Android.Common.targets Tracks @(_ApplicationSharedLibrary) as an input to _BuildApkFastDev to prevent stale APK packaging during Fast Deploy.
build-tools/automation/yaml-templates/stage-package-tests.yaml Adds a Mono-focused instrumentation lane in the package tests stage.

Copilot's findings

  • Files reviewed: 1/1 changed files
  • Comments generated: 0

@kotlarmilos kotlarmilos changed the title [XABT] Track libxamarin-app.so as a _BuildApkFastDev input [CoreCLR] Track libxamarin-app.so as a _BuildApkFastDev input Jul 22, 2026
@kotlarmilos kotlarmilos self-assigned this Jul 22, 2026
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 84bdb893-d6de-4a7c-a405-55f811a0bd28
@@ -2352,6 +2324,7 @@ because xbuild doesn't support framework reference assemblies.
;@(_ShrunkFrameworkAssemblies)
;@(_AndroidNativeLibraryForFastDev)
;@(_DexFileForFastDevInput)
;@(_ApplicationSharedLibrary)

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, my copilot actually has the exact same fix from overnight, but I like the test it wrote better than the one here.

I'll add some changes on top of this, thanks!

Replace the target-scheduling test with an MSBuildDeviceIntegration test that verifies an app-defined activity still resolves after an incremental assembly update.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

Copilot-Session: c74c08f8-5d07-4567-ac35-9de7021e5a4a
Carry forward the FastDeploy2 tests added on main while retaining the incremental typemap device regression.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

Copilot-Session: c74c08f8-5d07-4567-ac35-9de7021e5a4a
Place the typemap regression beside the stable Fast Deploy tests so current main can merge without overlapping the FastDeploy2 additions.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

Copilot-Session: c74c08f8-5d07-4567-ac35-9de7021e5a4a
Leave the FastDeploy2 coverage to main and retain only the typemap regression at a non-overlapping insertion point.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

Copilot-Session: c74c08f8-5d07-4567-ac35-9de7021e5a4a

@jonathanpeppers jonathanpeppers left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

New tests passes:

Image

Going to rerun some of the other flaky failures to see if those turn green.

@kotlarmilos
kotlarmilos enabled auto-merge (squash) July 22, 2026 18:10
@jonathanpeppers jonathanpeppers added the ready-to-review This PR is ready to review/merge, I think any CI failures are just flaky (ignorable). label Jul 22, 2026
Updating the app assembly regenerates libxamarin-app.so, so the incremental install correctly reinstalls the APK while still Fast Deploying only changed managed assemblies.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

Copilot-Session: 5178fba3-c160-4fb4-90bc-9b581b36408f
@jonathanpeppers
jonathanpeppers disabled auto-merge July 23, 2026 12:41
@jonathanpeppers

Copy link
Copy Markdown
Member

Investigated the failures in build 1522388. Neither appears related to this PR:

  • MSBuild+Emulator 4: MarshalMethodsAppRuns(CoreCLR) timed out waiting for XXX:OnStart done. Both attempts launched the activity but produced no app/CoreCLR output. This is the recurring cross-PR failure tracked by [CoreCLR] MarshalMethodsAppRuns crashes in Java_mono_android_TypeManager_n_activate #12206.
  • MSBuild+Emulator 8: the .NET SDK installation failed with curl: (6) Could not resolve host: builds.dotnet.microsoft.com. The later TestRelease artifact error is a consequence of that infrastructure/DNS failure.

This PR only adds @(_ApplicationSharedLibrary) to _BuildApkFastDev inputs for incremental Fast Deploy packaging. The MarshalMethods test is a Release startup test with no incremental edit, and the other failure occurred before tests could run.

@jonathanpeppers
jonathanpeppers merged commit d7f90fa into dotnet:main Jul 23, 2026
41 of 44 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

ready-to-review This PR is ready to review/merge, I think any CI failures are just flaky (ignorable).

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[CoreCLR][Fast Deploy] App crashes after an incremental C# edit on device or emulator

6 participants