Starting in Xamarin.Android 10.2, .pdb files are not included in the APK if the managed linker is enabled

[brendanzagaeski]

Context: https://developercommunity.visualstudio.com/content/problem/1036602/debug-only-works-when-linking-is-set-to-none.html

It appears this change might have been introduced in 77ab240. In particular, before that change, only framework assemblies were copied into android/assets/shrunk, but now all assemblies are copied there. It looks like either (a) the .pdb files need to be copied to the android/assets/shrunk directory too or (b) the BuildApk task needs to use a different strategy to locate them since it currently assumes they are alongside the assemblies:

https://github.com/xamarin/xamarin-android/blob/e61ff790ca524ac173be3965fbbad510d8303b43/src/Xamarin.Android.Build.Tasks/Tasks/BuildApk.cs#L349-L352

Perhaps of interest, there is already a _ResolvedSymbols MSBuild item list that contains the symbol locations, but that item list is not currently used in the BuildApk task.

Steps to reproduce

1. Create a new Android App > Single View App project.
2. Ensure the active configuration is Debug.
3. Open the Android Options section of the Visual Studio project property pages.
4. Disable Use Fast Deployment and Use Shared Runtime.
5. Set Linking to Sdk Assemblies Only in the Visual Studio project property pages.
6. Set a breakpoint in the Activity.OnCreate() override.
7. Start debugging the app.

Expected behavior

• The APK should contain .pdb files.
• The debugger should break on the breakpoint.

Actual behavior

• The APK does not contain any .pdb files.
• The debugger does not break on the breakpoint.

Partial workaround

In Visual Studio 2019 version 16.6 or higher, set Build > Advanced > Debugging information to Embedded in the Visual Studio project properties pages. This corresponds to the embedded value for the DebugType MSBuild property in the .csproj file:

<PropertyGroup>
  <DebugType>embedded</DebugType>
</PropertyGroup>

This is only a partial workaround because some projects might have reasons to prefer not to use embedded debugging symbols. Additionally, since embedded debugging symbols are relatively new, they might potentially have other unexpected consequences.

Version information

Affected versions

• Visual Studio 2019 Int Preview version 16.8 Preview 2
  • Xamarin.Android SDK version 11.0.99.34 (d16-8/49ba90e)
• Visual Studio 2019 version 16.5.5
  • Xamarin.Android SDK version 10.2.0.100 (d16-5/988c811)

Last known version that includes the .pdb files in the APK in this scenario

• Visual Studio 2019 version 16.4.11
  • Xamarin.Android SDK version 10.1.4.0 (d16-4/e44d1ae)

[jonathanpeppers]

This configuration emits a warning, right?

https://github.com/xamarin/xamarin-android/blob/8828fef1331490352da15f1f43d7f4e3d7ccf220/src/Xamarin.Android.Build.Tasks/Xamarin.Android.Common.targets#L446-L449

[brendanzagaeski]

Nah, there's no warning in this case because both fast deployment and AndroidUseSharedRuntime are disabled in this scenario. That is, this is the fallback "no fast deployment" scenario that might temporarily become more high traffic again in d16-9, depending on how smoothly the new rewritten fast deployment feature works for customers.

[jonathanpeppers]

When would you want fast deployment off, linker on, and debugging? It seems like a bananas combination, maybe we should have a warning?

It seems like to me that _RemoveRegisterAttribute shouldn't run at all if it is a Debug build though:

https://github.com/xamarin/xamarin-android/blob/8828fef1331490352da15f1f43d7f4e3d7ccf220/src/Xamarin.Android.Build.Tasks/Xamarin.Android.Common.targets#L1825-L1829

This would also solve the issue.

[brendanzagaeski]

I'm not sure it's too terribly bananas. It seems potentially helpful in some edge cases to be able to debug with the linker enabled to try to debug issues that might only happen when the linker is enabled? Or to put it another way, it seems useful to be able to make the Debug configuration as similar to the Release configuration as possible for some edge cases where issues might only appear in the Release configuration.

For example, what if somehow in some outlandish scenario, _RemoveRegisterAttribute causes an exception to appear that doesn't appear if that step doesn't run? Users might expect to be able to debug with symbols in that scenario to break on the exception?