No-change builds repack the APK when EmbedAssembliesIntoApk=true

[Qythyx]

Description

With EmbedAssembliesIntoApk=true, an Android app that has at least one ProjectReference never builds incrementally. Every build — including one run immediately after a successful build, with no file touched — re-runs _BuildApkEmbed, then re-zipaligns and re-signs the APK. That is ~30s in the hello-world repro below, and ~45s in our real app, on every build.

The APK packaging targets themselves look correct: _BuildApkEmbed has proper Inputs/Outputs, and the input it names really is newer than the APK. The problem is upstream of it — the referenced library is recompiled on every build, which invalidates everything downstream.

Removing the single ProjectReference drops the no-change rebuild from 32.5s to 1.0s.

Note: This bug report was written by Claude (AI assistant) based on testing and guidance from the project developer.

Steps to Reproduce

git clone -b android-apk-repack-every-build https://github.com/Qythyx/bug_repros.git
cd bug_repros
dotnet build ReproApp/ReproApp.csproj -f net10.0-android   # first build
dotnet build ReproApp/ReproApp.csproj -f net10.0-android   # no changes — still ~32s

The repro is nothing but dotnet new maui + dotnet new classlib with one ProjectReference added. The only non-template properties in ReproApp.csproj are:

<TargetFrameworks>net10.0-android</TargetFrameworks>
<RuntimeIdentifiers Condition="'$(TargetFramework)' == 'net10.0-android'">android-arm64</RuntimeIdentifiers>
<EmbedAssembliesIntoApk>true</EmbedAssembliesIntoApk>

ReproLib.csproj is an unmodified dotnet new classlib retargeted to net10.0-android.

Measured on the second (no-change) build:

Configuration	Wall time	_BuildApkEmbed
App with ProjectReference, EmbedAssembliesIntoApk=true	32.5s	29.7s
App without any ProjectReference	1.0s	2ms
App with ProjectReference, EmbedAssembliesIntoApk=false (fast deploy)	3.2s	_BuildApkFastDev 202ms

That last row is likely why this isn't already widely reported: the default Debug deploy path uses fast deployment, where the same redundant recompile still happens but packaging is cheap. It only becomes expensive on the embed path — which is what you need when the APK is installed directly (adb install, or an Appium-driven test run) rather than deployed through the SDK.

Link to public reproduction project repository

https://github.com/Qythyx/bug_repros/tree/android-apk-repack-every-build

Root cause

The referenced library is compiled twice per app build, by two MSBuild project configurations. Diffing the two csc command lines: 362 arguments each, differing in exactly one — /define: — carrying the same 75 constants in a different order:

compile 1: /define:TRACE;DEBUG;__XAMARIN_ANDROID_v1_0__;__MOBILE__;__ANDROID__;...;NET;NET10_0;NETCOREAPP;ANDROID;...
compile 2: /define:TRACE;DEBUG;NET;NET10_0;NETCOREAPP;ANDROID;...;__XAMARIN_ANDROID_v1_0__;__MOBILE__;__ANDROID__;...

_GenerateCompileDependencyCache hashes $(DefineConstants) as a string, so the two configurations compute different hashes and overwrite each other's <Project>.csproj.CoreCompileInputs.cache on every build. The last write lands after csc wrote the compile outputs, so on the next build the cache is newer than the outputs and CoreCompile runs "completely" again. The cache content is byte-identical between builds — only the mtime moves — so it never converges.

Constant ordering has no effect on compilation, so this is pure build-system churn.

The resulting cascade, taken from an MSBuild -v d log of the repro (each line is MSBuild's own up-to-date reason):

Input file "obj/Debug/net10.0-android/ReproLib.csproj.CoreCompileInputs.cache"
   is newer than output file "obj/Debug/net10.0-android/ReproLib.xml"
→ Input file ".../ReproLib/bin/Debug/net10.0-android/ReproLib.dll"
   is newer than output file "obj/Debug/net10.0-android/stamp/_ResolveLibraryProjectImports.stamp"
→ Input file "obj/Debug/net10.0-android/android/assets/arm64-v8a/ReproLib.dll"
   is newer than output file "obj/Debug/net10.0-android/stamp/_GenerateJavaStubs.stamp"
→ Input file "obj/Debug/net10.0-android/android/assets/arm64-v8a/ReproLib.dll"
   is newer than output file "obj/Debug/net10.0-android/stamp/_GeneratePackageManagerJava.stamp"
→ Input file "obj/Debug/net10.0-android/android/assets/arm64-v8a/ReproLib.dll"
   is newer than output file "obj/Debug/net10.0-android/android/bin/com.companyname.reproapp.apk"
      → _BuildApkEmbed runs completely (~30s): CreateAssemblyStore,
        WrapAssembliesAsSharedLibraries, then re-zipalign and re-sign

Building the library on its own is perfectly incremental — CoreCompile is skipped, and the cache and the compile outputs share a timestamp. The second configuration only appears when the library is built as a reference of the Android app.

Did you find any workaround?

None that keeps the build both correct and incremental. Tried and ruled out, each verified by measurement:

• Pinning the RID (-p:RuntimeIdentifier=android-arm64, so there is no outer/inner RID split) — no change, still ~48s.
• Removing a third-party build-time formatter that creates extra project configurations (CSharpier.MSBuild, -p:CSharpier_Bypass=true) — no change, still ~41s.
• GenerateDocumentationFile on or off — reproduces either way; it only changes which CoreCompile output the cache is compared against.
• Multi-targeting the library — not required; a single-TFM net10.0-android library reproduces.
• EmbedAssembliesIntoApk=false avoids the cost but not the underlying recompile, and it isn't usable when the APK must be installed directly.

The only practical mitigation we found is to avoid building the app at all when nothing changed — wrapping the app build in a hand-written MSBuild target with its own Inputs/Outputs staleness check, which duplicates work the SDK is already doing.

Android application type

.NET Android (net10.0-android), MAUI app

Affected platform version

.NET SDK                      10.0.101
Workload version              10.0.107
android workload              36.1.53/10.0.100
maui workload                 10.0.20/10.0.100
Microsoft.Android.Sdk.Darwin  36.1.53
Host                          macOS 26.6 (25G72), arm64

Is this a regression from previous behavior?

Unknown — not bisected against earlier SDK versions.

[jonathanpeppers]

With EmbedAssembliesIntoApk=true, an Android app that has at least one ProjectReference never builds incrementally. Every build — including one run immediately after a successful build, with no file touched — re-runs _BuildApkEmbed, then re-zipaligns and re-signs the APK.

Yes, that is the whole point of using EmbedAssembliesIntoApk=false (the default!) in Debug mode. It avoids this process.

• EmbedAssembliesIntoApk=false == Fast Deployment ON
• EmbedAssembliesIntoApk=true == Fast Deployment OFF (or Release mode)

Do you know why you have turned off "Fast Deployment"?

I have considered renaming the property to AndroidFastDeployment, it has had this confusing name for a very long time.

[Qythyx]

I understand that makes the deployment faster, but I feel that if a build is run and no code was changed in the app then it should skip rebuilding and embedding the assemblies. In my case I have a .NET solution with both backend and frontend and a number of projects interconnected. So when I've made backend changes the easiest thing is to just run dotnet build for the solution, with the expectation that unchanged projects won't rebuild.

Why do I have fast deployment turned off? Because I'm running automated UI tests via Appium. With fast deployment the APK is built without the managed assemblies inside it. Instead, the SDK's deploy step pushes the .dlls separately over adb into the app's private override directory, so an incremental deploy only re-pushes the DLLs that changed rather than reinstalling a multi-megabyte APK.

The catch is that the push is part of the SDK's deploy step (-t:Run, or an IDE deploy). Appium doesn't do that — it just adb installs whatever file AppBinaryPath points at. A hand-rolled adb install doesn't either.

So the app launches with its assemblies in neither place: not embedded in the APK, not in the override directory. The native Android runtime aborts during startup, before any managed code runs — which is why it presents as a process crash at launch rather than a catchable .NET exception. The runtime's log line is literally No assemblies found.

[jonathanpeppers]

I understand that makes the deployment faster, but I feel that if a build is run and no code was changed in the app then it should skip rebuilding and embedding the assemblies.

Can you share a .binlog of what you think should be skipped and isn't? https://aka.ms/binlog

If Fast Deployment is off and any .dll file changes, it would need to repack and resign the .apk.

Why do I have fast deployment turned off? Because I'm running automated UI tests via Appium. With fast deployment the APK is built without the managed assemblies inside it.

So, I would recommend doing this for what would work today:

• Turn Fast Deployment back ON
• Use the Install target to deploy, e.g.: dotnet build -t:Install
• Use the appium setting to test an already installed app, there should be an API to use a package name instead.

This is also the workflow we recommended back in the Xamarin.UITest / AppCenter days.

[Qythyx]

Binlogs are linked below. First, though, I think I under-explained the claim in the original report, so let me sharpen it — I don't believe this is a request to skip work that genuinely needs doing.

The claim isn't "don't repack when a .dll changed"

If Fast Deployment is off and any .dll file changes, it would need to repack and resign the .apk.

Agreed, and that part is working correctly. The problem is that a .dll changes on every build when nothing changed.

On a no-change rebuild of the repro (run immediately after a successful build, nothing touched):

• ReproLib is compiled twice per app build — two CoreCompile "completely" runs.

• The resulting ReproLib.dll is byte-identical every time: SHA-256 291b537e…, 4096 bytes, stable across three consecutive no-change builds. Only its mtime moves.

• ReproLib.csproj.CoreCompileInputs.cache is likewise byte-identical between builds (5518b07b…), yet is rewritten every build — and lands after csc wrote the compile outputs:

  ReproLib.dll                             mtime 21:50:15
  ReproLib.csproj.CoreCompileInputs.cache  mtime 21:50:19
  

So the next build sees the cache as newer than the compile outputs, recompiles, rewrites a byte-identical .dll with a fresh timestamp — and from there every downstream check correctly concludes it must re-run. Each individual up-to-date check is behaving properly. They are all being fed a file that was needlessly rewritten.

Why the cache never converges: the two compiles differ in exactly one of 362 csc arguments — /define: — carrying the same 75 constants in a different order (detail in the issue body above). _GenerateCompileDependencyCache hashes $(DefineConstants) as a string, so the two configurations compute different hashes and overwrite each other's cache file on every build.

This is not specific to Fast Deployment being off

With EmbedAssembliesIntoApk=false I still get two CoreCompile "completely" runs for ReproLib per build, the same staged-assembly churn, _GenerateJavaStubs and _GeneratePackageManagerJava re-running, and the APK re-signed:

Input file "obj/.../ReproLib.csproj.CoreCompileInputs.cache" is newer than output file "obj/.../ReproLib.pdb".
Input file "obj/.../android/assets/arm64-v8a/ReproLib.dll" is newer than output file "obj/.../stamp/_GenerateJavaStubs.stamp".
Input file "obj/.../android/assets/arm64-v8a/ReproLib.dll" is newer than output file "obj/.../stamp/_GeneratePackageManagerJava.stamp".
Input file "obj/.../android/bin/com.companyname.reproapp.apk" is newer than output file "bin/.../com.companyname.reproapp-Signed.apk".

Fast Deployment doesn't avoid the redundant work — it makes the packaging step cheap enough (_BuildApkFastDev 202ms vs _BuildApkEmbed ~30s) that the waste is invisible. That's why I'd suggest the recompile is worth fixing on its own, independently of which deployment mode a project uses.

Binlogs

Both captured on a no-change rebuild immediately following a successful build, same repro:

• Fast Deployment OFF (EmbedAssembliesIntoApk=true): https://github.com/Qythyx/bug_repros/raw/android-apk-repack-every-build/binlogs/no-change-rebuild.binlog
• Fast Deployment ON (EmbedAssembliesIntoApk=false): https://github.com/Qythyx/bug_repros/raw/android-apk-repack-every-build/binlogs/fastdeploy-on-rebuild.binlog

On the Appium recommendation

Thank you — that's genuinely useful and I'll try it: Fast Deployment on, deploy with dotnet build -t:Install, and point Appium at the package name rather than at app. That does address our deployment problem, and I'd rather follow the supported path than keep Fast Deployment off. I'd just like to keep it separate from the build-correctness question above, since that one shows up with Fast Deployment on as well.

(And for what it's worth: AndroidFastDeployment would have been much clearer. The current name gave me no hint that it selected a deployment strategy.)

[jonathanpeppers]

Agreed, and that part is working correctly. The problem is that a .dll changes on every build when nothing changed.

ReproLib.csproj.CoreCompileInputs.cache is likewise byte-identical between builds (5518b07b…), yet is rewritten every build — and lands after csc wrote the compile outputs:

These are implemented in the .NET SDK (dotnet/sdk) and Roslyn (dotnet/roslyn), not here. Is there a specific thing we are doing in the Android workload to cause this behavior? I find that unlikely, but certainly possible.

[Qythyx]

Is there a specific thing we are doing in the Android workload to cause this behavior?

Yes — _ResolveMonoAndroidSdks in Xamarin.Android.Common.targets appends to $(DefineConstants),
and its position relative to the SDK's AddImplicitDefineConstants isn't fixed. Whichever runs first
determines the order of the constants, and the two differ per project configuration.

Here is MSBuild's own property tracking from a single build of the repro
(Microsoft.Android.Sdk.Darwin/36.1.53, .NET SDK 10.0.101), filtered to reassignments of
$(DefineConstants) for ReproLib:

ReproLib.csproj | _ResolveMonoAndroidSdks     | TRACE;DEBUG;__XAMARIN_ANDROID_v1_0__;__MOBILE__;__AN…
ReproLib.csproj | AddImplicitDefineConstants  | TRACE;DEBUG;__XAMARIN_ANDROID_v1_0__;__MOBILE__;__AN…

ReproLib.csproj | AddImplicitDefineConstants  | TRACE;DEBUG;NET;NET10_0;NETCOREAPP;ANDROID;ANDROID36…
ReproLib.csproj | _ResolveMonoAndroidSdks     | TRACE;DEBUG;NET;NET10_0;NETCOREAPP;ANDROID;ANDROID36…

Same project, same build, two configurations, opposite order:

• In the first, _ResolveMonoAndroidSdks (Xamarin.Android.Common.targets(820,3)) runs first and
  puts __XAMARIN_ANDROID_v1_0__;__MOBILE__;__ANDROID_*__ in front; AddImplicitDefineConstants
  (Microsoft.NET.Sdk.BeforeCommon.targets(295,7)) then appends NET;NET10_0;NETCOREAPP;….
• In the second, AddImplicitDefineConstants runs first, and _ResolveMonoAndroidSdks appends the
  Android constants at the end.

That is where the two different $(DefineConstants) strings come from — same 75 constants, two
orders. _GenerateCompileDependencyCache then hashes that string, the two configurations write
different hashes to the same ReproLib.csproj.CoreCompileInputs.cache, and the recompile-every-build
loop follows from there.

You can see it in either binlog already attached, or reproduce it directly:

dotnet build ReproApp/ReproApp.csproj -f net10.0-android -v d > log.txt
grep -F 'Property reassignment: $(DefineConstants)' log.txt

To be fair about where the fix belongs: there are two halves, and only one is yours. The SDK hashing
an order-sensitive string is the fragile half, and AddImplicitDefineConstants at least runs at a
fixed point in the SDK's graph. The variable half is on the Android side — _ResolveMonoAndroidSdks
is pulled in as a dependency of many Android targets, so when it runs (and therefore whether it
appends before or after the SDK's constants) depends on which targets a given build request asks for.

If the Android constants were contributed as ImplicitDefineConstants items and left for the SDK's
single AddImplicitDefineConstants to assemble, rather than appended to the property separately, the
ordering would be pinned regardless of target ordering. That looked like the smallest change on your
side, but you'd know far better than I would whether _ResolveMonoAndroidSdks needs the property
populated that early for something else.

Happy to file the other half against dotnet/sdk if you think the hash should be order-insensitive
there too.