[net11.0-android/CoreCLR] Incremental Release builds corrupt the compressed assembly store -> 'assembly is larger than when built' SIGABRT at startup

[gentledepp]

Android application type

.NET Android (net11.0-android), CoreCLR runtime, Release, AndroidEnableAssemblyCompression enabled (default), assembly store (default)

Description

On Release builds with the (default) LZ4-compressed assembly store, incremental rebuilds intermittently corrupt the store: the compressed size recorded in the store index goes out of sync with the actual blob, and the app aborts at startup (SIGABRT) before any UI:

F monodroid-assembly: Compressed assembly 'Mono.Android.dll' is larger than when the application was
built (expected at most 7680, got 2554368). Assemblies don't grow just like that!
F monodroid-assembly: Abort at assembly-store.cc:101:6 ('static std::tuple<uint8_t *, uint32_t>
xamarin::android::AssemblyStore::get_assembly_data(const AssemblyStoreSingleAssemblyRuntimeData &,
const std::string_view &)')
E DOTNET  : Fatal error.
E DOTNET  : Got a SIGABRT while executing native code.
F libc    : Fatal signal 6 (SIGABRT) ...
F DEBUG   : #01 ... libmonodroid.so (xamarin::android::Helpers::abort_application(...)+836)

It is intermittent and build-state dependent: a given build can run fine, and then a later
incremental rebuild/redeploy of the same project produces the crash. The recorded "expected at most"
size (e.g. 7680) is wildly smaller than the actual compressed assembly (e.g. 2.5 MB), which points at a
stale/incorrect store index entry rather than a genuinely changed assembly.

Workaround

A clean build fixes it every time — delete obj/ + bin/ for the Android head project (or
dotnet clean) and rebuild/redeploy; the regenerated store is consistent and the app launches
normally. (AndroidEnableAssemblyCompression=false should also avoid it by removing the compressed
size bookkeeping, but that path is blocked for us because Sentry 6.5.0 hard-errors on it via
_SentryEnsureAndroidEnableAssemblyCompressionDisabled → #9752.)

Steps to reproduce

1. net11.0-android app (CoreCLR), Release, default assembly store + compression.
2. Repeatedly dotnet build -c Release -f net11.0-android -t:Install (incremental, various small changes / redeploys).
3. Eventually the deployed app SIGABRTs at startup with the assembly-store.cc abort above.
4. Wipe obj/bin, clean-build+install → runs fine again.

Expected

Incremental builds should keep the assembly-store index and the compressed blobs in sync, so a redeploy
never produces a size-mismatch abort. At minimum, the tooling could detect/repair a stale store entry
rather than shipping an inconsistent store that aborts at runtime.

Environment

• Host: Windows 11
• .NET SDK: 11.0.100-preview.6.26359.118
• App: .NET MAUI–embedding Avalonia app, TFM net11.0-android, CoreCLR runtime; AndroidLinkMode=SdkOnly, PublishTrimmed=true, EmbedAssembliesIntoApk=true
• Device: Google Pixel 9 Pro (physical, USB)