Remove Sentry.Android.AssemblyReader package

[jamescrosswell]

Sentry.Android.AssemblyReader was originally created in #2127 so that we could reuse some of the functionality in both sentry-dotnet and sentry-xamarin.

Since sentry-xamarin isn't seeing any new updates, we may as well move the code from this package back into the Sentry package.

This will also allow us to:

• Use the IDiagnosticLogger directly in the code for the AssemblyReader (without creating a circular dependency)
• Make AndroidAssemblyReaderFactory internal
• Make SentryOptions.AssemblyReader internal (or just remove it altogether, unless we have any custom implementations)

Originally posted by @bruno-garcia in #4457 (comment)

[linear]

NET-423 Remove Sentry.Android.AssemblyReader package

[jamescrosswell]

This is a wee bit more complex than anticipated... mostly to test.

Currently the Sentry.Android.AssemblyReader package targets net8.0 and net9.0:

sentry-dotnet/src/Sentry.Android.AssemblyReader/Sentry.Android.AssemblyReader.csproj

Lines 3 to 6 in fe09683

	<PropertyGroup>
	<TargetFrameworks>net8.0;net9.0</TargetFrameworks>
	<Description>.NET assembly reader for Android</Description>
	</PropertyGroup>

This is convenient, since it allows us to test the assembly reader against the vanilla TFMs (not the netX.0-android ones).

Ideally we'd move everything from sentry-dotnet/src/Sentry.Android.AssemblyReader/** to src/Sentry/Platforms/Android/AssemblyReader/** so that the assembly reader only gets included for the android targets. This is important since the AssemblyReader code has a package dependency on K4os.Compression.LZ4 and we don't need or want that dependency for non-android targets.

However that means the only way to test this is when targeting netX.0-android, which implicitly means we can only run it via our device tests... and that in turn makes it really difficult to do this:

sentry-dotnet/test/Sentry.Android.AssemblyReader.Tests/Sentry.Android.AssemblyReader.Tests.csproj

Lines 31 to 52 in 876ec16

	<!-- Build the Android test app in various configurations during the build of this test project. -->
	<Target Name="BuildTestAPKs" BeforeTargets="BeforeBuild" Condition="'$(TargetPlatformIdentifier)' != 'android'">
	<!-- Restore exactly once: https://learn.microsoft.com/en-gb/visualstudio/msbuild/run-target-exactly-once -->
	<MSBuild Projects="$(MSBuildProjectFullPath)" Targets="EnsureAndroidTestAppRestored" RemoveProperties="TargetFramework" />
	<MSBuild Projects="$(MSBuildProjectFile)" Targets="_InnerBuildTestAPKs" Properties="TargetFramework=net10.0-android" Condition="$(TargetFramework) == 'net10.0'" />
	<MSBuild Projects="$(MSBuildProjectFile)" Targets="_InnerBuildTestAPKs" Properties="TargetFramework=net9.0-android" Condition="$(TargetFramework) == 'net9.0'" />
	</Target>
	<Target Name="_InnerBuildTestAPKs">
	<!-- https://learn.microsoft.com/visualstudio/msbuild/msbuild-batching -->
	<ItemGroup>
	<_TestAPK Include="1" Properties="_Aot=False;_Store=False;_Compressed=False" />
	<_TestAPK Include="2" Properties="_Aot=False;_Store=False;_Compressed=True" />
	<_TestAPK Include="3" Properties="_Aot=False;_Store=True;_Compressed=False" />
	<_TestAPK Include="4" Properties="_Aot=False;_Store=True;_Compressed=True" />
	<_TestAPK Include="5" Properties="_Aot=True;_Store=False;_Compressed=False" />
	<_TestAPK Include="6" Properties="_Aot=True;_Store=False;_Compressed=True" />
	<_TestAPK Include="7" Properties="_Aot=True;_Store=True;_Compressed=False" />
	<_TestAPK Include="8" Properties="_Aot=True;_Store=True;_Compressed=True" />
	</ItemGroup>
	<MSBuild Projects="$(MSBuildProjectFile)" Targets="_BuildTestAPK" Properties="%(_TestAPK.Properties)" BuildInParallel="false" />
	</Target>

We could test all of those scenarios via integration tests instead - essentially we're running these tests for all 8 permutations of AOT (true/false), Store Kind (Store/Directory) and Compressed (true/false).

@jpnurmi @vaind do you think this functionality would be covered implicitly by the integration tests either of you guys are working on (@vaind in particular, I think you have something in the works right)?

[jpnurmi]

Integration tests run real crashing apps and don't collect unit tests results, but maybe those tests could run as part of test/Sentry.Maui.Device.TestApp that runs unit tests on device?

If we'd split unit and integration tests to separate jobs in device-tests-android.yml, we could probably build and run unit tests in a matrix of different configurations, although 8 would be a lot...

[vaind]

AFAIR these tests that read APKs didn't need to run on device at all so it was better (easier and faster) to have them run in standard test suite.

If you want to move it to android device tests, than I second what @jpnurmi - you'd need to change the structure so that the test tests the current app itself (instead of a loose apk) and change the tests to run for each of the configuration.

Or you can leave the AssemblyReader as a separate package.

[jamescrosswell]

AFAIR these tests that read APKs didn't need to run on device at all so it was better (easier and faster) to have them run in standard test suite.

Exactly... well definitely easier and faster anyway.

you'd need to change the structure so that the test tests the current app itself (instead of a loose apk)

Yeah I get it. My question was whether the integration tests you're creating would implicitly test this functionality anyway.

Essentially these assembly reader tests try to open an assembly store/archive and then get the details of a couple of assemblies in the store... which is something you'd have to do in order to correctly symbolicate a managed stack trace on Android anyway.

I think I'm starting to persuade myself this PR isn't worth it. Originally the idea was to have one less NuGet package to manage and to sidestep some problems with circular references. When that was "free" it sounded attractive. Knowing now that it requires significantly restructuring our test infrastructure, it seems like more effort than it's worth...