[Android .NET 10] Stack traces not symbolicated - assembly store blob not found due to renamed libassembly-store.so

[InterstellarStella]

Package

Sentry

.NET Flavor

.NET

.NET Version

10.0.2

OS

Android

OS Version

Android 16 (API level 36)

Development Environment

Visual Studio v18.x

SDK Version

6.0.0

Self-Hosted Sentry Version

No response

Workload Versions

MAUI Android project

UseSentry or SentrySdk.Init call

SentrySdk.Init(options =>
{
    options.Dsn = "*********";
    options.Debug = true;
    options.DiagnosticLevel = SentryLevel.Debug;
});

Build config: <TargetFramework>net10.0-android</TargetFramework> with <EmbedAssembliesIntoApk>True</EmbedAssembliesIntoApk>

Steps to Reproduce

1. Create a .NET MAUI app targeting net10.0-android
2. Install Sentry SDK v6.0.0 from NuGet
3. Build in Release/production configuration (with EmbedAssembliesIntoApk=true, which is the default)
4. Upload debug files (PDBs) via sentry-cli
5. Trigger an exception on an Android device
6. Observe the event in Sentry

Expected Result

Stack traces should be symbolicated. The event should contain a debug_meta.images section with pe_dotnet debug images, allowing Sentry's symbolicator to match frames to uploaded PDB files. This works correctly on iOS (net10.0-ios) and worked on Android with net9.0-android.

Actual Result

Stack traces are not symbolicated. Every frame shows symbolicator_status: "unknown_image". There is no "Images Loaded" section in the Sentry UI, and debug_meta is completely absent from the event JSON. Example event is provided in the internal Linear ticket.

iOS (net10.0-ios) symbolication works correctly with the same SDK version.

.NET 10 Android changed the assembly store blob filename from libassemblies.{abi}.blob.so to libassembly-store.so (see dotnet/android#10249). The SDK's StoreReader.GetBlobName() still uses the old naming pattern:

// Current code in StoreReader.cs line 90
private static string GetBlobName(string abi) => $"libassemblies.{abi}.blob.so";

This causes the following failure chain (from logcat with Debug diagnostics enabled):

Debug: Opening APK: /data/app/.../base.apk
Debug: Unable to read store information for .../base.apk: Unable to find any blob entries
Debug: Unable to read store information for .../split_config.arm64_v8a.apk: Unable to find any blob entries
Debug: Could not find V2 AssemblyStoreExplorer for the supported ABIs: arm64-v8a, armeabi-v7a, armeabi
Debug: APK doesn't use AssemblyStore
Debug: File Sentry does not exist in the APK
Debug: No entry found for path 'lib/arm64-v8a/lib_Sentry.so' in archive '.../base.apk'
Debug: Skipping debug image for module 'Sentry' because assembly wasn't found: ''
Debug: Skipping debug image for module 'myApp.AndroidUI.dll' because assembly wasn't found: ''
Debug: Skipping debug image for module 'Mono.Android' because assembly wasn't found: ''
Debug: Merging 0 debug images from stacktrace.

The sentry-cli upload confirms the actual blob filenames in the APK are:

UPLOADED a9736aab-... (lib/arm64-v8a/libassembly-store.so; arm64 debug companion)
UPLOADED ecc8a81a-... (lib/armeabi-v7a/libassembly-store.so; arm debug companion)

The SDK looks for lib/arm64-v8a/libassemblies.arm64-v8a.blob.so but the actual file is lib/arm64-v8a/libassembly-store.so.

The v3 AssemblyStore binary format parsing (added in #4583) appears correct; only the blob file lookup path is wrong

Workaround: Setting <AndroidUseAssemblyStore>false</AndroidUseAssemblyStore> in the .csproj restores symbolication by packaging assemblies as individual files that the fallback AndroidAssemblyDirectoryReader can find.

[linear]

NET-600

[jamescrosswell]

Hm, this is interesting. Firstly because you've got issues with the symbolication on Android (which I'll look into shortly)... but also because you're saying symbolication on iOS is working fine. Have you configured <EnableAssemblyILStripping>false</EnableAssemblyILStripping> on iOS? Without that, I haven't been able to get symbolication working on iOS due to an issue in the dotnet sdk.

[jamescrosswell]

@InterstellarStella I'm not seeing this when running samples/Sentry.Samples.Maui/ in Android:

Are you able to put together a minimal repro of the issue? I think it will come down to working out why our Sample works and the repro you have doesn't (maybe comparing the properties in the respective *.csproj files).

[aghozzy]

we can confirm this Android behavior (.net 10.0.3, Sentry MAUI SDK 6.1.0), while AOT and Optimize flags are enabled (typically for release builds) and symbols auto-uploaded by sentry-cli via MSBuild (upload verified), line numbers go missing and symbolication do not work due to missing debug_meta.

After long experimentation we found only that symbolication and line numbers appear if we set Optimize flag to False OR AndroidUseAssemblyStore to False, obviously we can not give up on the optimize flag to be false.
Note: all tests conducted using published .apk (not aab) via dotnet publish on win emulators (android-x64)

<PropertyGroup Condition="'$(Configuration)|$(TargetFramework)|$(Platform)'=='Release|net10.0-android|AnyCPU'">
   <TargetFramework>net10.0-android</TargetFramework>
   <RuntimeIdentifiers>android-arm;android-arm64;android-x64</RuntimeIdentifiers>
   <RunAOTCompilation>True</RunAOTCompilation>
   <AndroidEnableProfiledAot>False</AndroidEnableProfiledAot>

   <!-- Sentry .NET needs access to per-assembly PE data to emit debug_meta for server-side symbolication.
        With AssemblyStore enabled, assemblies are packaged into a shared store (e.g. libassembly-store.so),
        and Sentry can't currently resolve them, resulting in missing debug_meta and no line numbers. -->
   <AndroidUseAssemblyStore>false</AndroidUseAssemblyStore>

   <Optimize>True</Optimize>
   <DebugSymbols>True</DebugSymbols>
   <DebugType>portable</DebugType> 
   <AndroidLinkMode>SdkOnly</AndroidLinkMode> 
 </PropertyGroup>

 <PropertyGroup>
   <SentryUploadSymbols>true</SentryUploadSymbols>
   <SentryUploadAndroidProGuardMapping>true</SentryUploadAndroidProGuardMapping>
   <SentryUploadSources>false</SentryUploadSources>
 </PropertyGroup>

[jamescrosswell]

@aghozzy are you able to provide a minimal reproducible example (e.g. a github repo with a tiny sample app that illustrates the issue)?

I wasn't able to reproduce this.