[CoreCLR] Track libxamarin-app.so as a _BuildApkFastDev input#12205
Conversation
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
34bd7ca to
a595dcb
Compare
There was a problem hiding this comment.
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_BuildApkFastDevStaticInputsso_BuildApkFastDevrepackages/reinstalls whenlibxamarin-app.sochanges. - 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
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) | |||
There was a problem hiding this comment.
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
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
|
Investigated the failures in build 1522388. Neither appears related to this PR:
This PR only adds |

Fixes #12201
The
_BuildApkFastDevtarget 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_CreateApplicationSharedLibrariesrelinkslibxamarin-app.sowith a new CoreCLR Debug typemap, MSBuild treats the target as up to date and skips repackaging, after whichFast Deploy pushes the new assembly to
.__override__while the installed APK keeps the stale typemap and the managed to Java lookup resolves an applicationActivitytojava.lang.Objectand raisesActivityNotFoundExceptionon 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.