Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Closed
brendanzagaeski opened this issue Aug 14, 2020 · 5 comments · Fixed by #4690
Closed

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

brendanzagaeski opened this issue Aug 14, 2020 · 5 comments · Fixed by #4690
Assignees
@dellis1972 @jonathanpeppers
Labels
Area: App+Library Build Issues when building Library projects or Application projects. bug Component does not function as intended.
Milestone
Published: 11.2 (...

Comments

@brendanzagaeski
Copy link
Contributor

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)
@brendanzagaeski brendanzagaeski added the Area: App+Library Build Issues when building Library projects or Application projects. label Aug 14, 2020
@brendanzagaeski brendanzagaeski added this to the Under Consideration milestone Aug 14, 2020
@jonathanpeppers
Copy link
Member

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
Copy link
Contributor Author

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
Copy link
Member

jonathanpeppers commented Aug 14, 2020 •
edited
Loading

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.

dellis1972 added a commit to dellis1972/xamarin-android that referenced this issue Aug 14, 2020
@dellis1972
use AndroidIncludeDebugSymbols for _RemoveRegisterAttribute. Fixes do…
3fcd6ed 
…tnet#5009
@brendanzagaeski
Copy link
Contributor Author

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?

@brendanzagaeski brendanzagaeski mentioned this issue Aug 15, 2020
Merged
dellis1972 added a commit to dellis1972/xamarin-android that referenced this issue Aug 19, 2020
@dellis1972
use AndroidIncludeDebugSymbols for _RemoveRegisterAttribute. Fixes do…
f2248ba 
…tnet#5009
dellis1972 added a commit to dellis1972/xamarin-android that referenced this issue Aug 19, 2020
@dellis1972
Fast Dev V2
0989b07 
use AndroidIncludeDebugSymbols for _RemoveRegisterAttribute. Fixes dotnet#5009
dellis1972 added a commit to dellis1972/xamarin-android that referenced this issue Aug 20, 2020
@dellis1972
Fast Dev V2
e006ca4 
use AndroidIncludeDebugSymbols for _RemoveRegisterAttribute. Fixes dotnet#5009
dellis1972 added a commit to dellis1972/xamarin-android that referenced this issue Aug 20, 2020
@dellis1972
Fast Dev V2
8999147 
use AndroidIncludeDebugSymbols for _RemoveRegisterAttribute. Fixes dotnet#5009
dellis1972 added a commit to dellis1972/xamarin-android that referenced this issue Aug 21, 2020
@dellis1972
Fast Dev V2
ce6b84a 
use AndroidIncludeDebugSymbols for _RemoveRegisterAttribute. Fixes dotnet#5009
dellis1972 added a commit to dellis1972/xamarin-android that referenced this issue Aug 24, 2020
@dellis1972
Fast Dev V2
2734c7e 
use AndroidIncludeDebugSymbols for _RemoveRegisterAttribute. Fixes dotnet#5009
dellis1972 added a commit to dellis1972/xamarin-android that referenced this issue Aug 24, 2020
@dellis1972
Fast Dev V2
6bb2211 
use AndroidIncludeDebugSymbols for _RemoveRegisterAttribute. Fixes dotnet#5009
dellis1972 added a commit to dellis1972/xamarin-android that referenced this issue Sep 1, 2020
@dellis1972
Fast Dev V2
4af8cf9 
use AndroidIncludeDebugSymbols for _RemoveRegisterAttribute. Fixes dotnet#5009
dellis1972 added a commit to dellis1972/xamarin-android that referenced this issue Sep 3, 2020
@dellis1972
Fast Dev V2
d70588b 
use AndroidIncludeDebugSymbols for _RemoveRegisterAttribute. Fixes dotnet#5009
dellis1972 added a commit to dellis1972/xamarin-android that referenced this issue Sep 3, 2020
@dellis1972
Fast Dev V2
9be5bcb 
use AndroidIncludeDebugSymbols for _RemoveRegisterAttribute. Fixes dotnet#5009
dellis1972 added a commit to dellis1972/xamarin-android that referenced this issue Sep 3, 2020
@dellis1972
Fast Dev V2
06b82d3 
use AndroidIncludeDebugSymbols for _RemoveRegisterAttribute. Fixes dotnet#5009
dellis1972 added a commit to dellis1972/xamarin-android that referenced this issue Sep 4, 2020
@dellis1972
Fast Dev V2
a9eff9f 
use AndroidIncludeDebugSymbols for _RemoveRegisterAttribute. Fixes dotnet#5009
dellis1972 added a commit to dellis1972/xamarin-android that referenced this issue Sep 21, 2020
@dellis1972
Fast Dev V2
cba68fa 
use AndroidIncludeDebugSymbols for _RemoveRegisterAttribute. Fixes dotnet#5009
dellis1972 added a commit to dellis1972/xamarin-android that referenced this issue Sep 29, 2020
@dellis1972
Fast Dev V2
cc92a6e 
use AndroidIncludeDebugSymbols for _RemoveRegisterAttribute. Fixes dotnet#5009
dellis1972 added a commit to dellis1972/xamarin-android that referenced this issue Oct 5, 2020
@dellis1972
Fast Dev V2
684309a 
use AndroidIncludeDebugSymbols for _RemoveRegisterAttribute. Fixes dotnet#5009
dellis1972 added a commit to dellis1972/xamarin-android that referenced this issue Oct 5, 2020
@dellis1972
Fast Dev V2
69f5644 
use AndroidIncludeDebugSymbols for _RemoveRegisterAttribute. Fixes dotnet#5009
dellis1972 added a commit to dellis1972/xamarin-android that referenced this issue Oct 8, 2020
@dellis1972
Fast Dev V2
4866d3b 
use AndroidIncludeDebugSymbols for _RemoveRegisterAttribute. Fixes dotnet#5009
dellis1972 added a commit to dellis1972/xamarin-android that referenced this issue Oct 8, 2020
@dellis1972
Fast Dev V2
1b252bd 
use AndroidIncludeDebugSymbols for _RemoveRegisterAttribute. Fixes dotnet#5009
dellis1972 added a commit to dellis1972/xamarin-android that referenced this issue Oct 8, 2020
@dellis1972
Fast Dev V2
adfd244 
use AndroidIncludeDebugSymbols for _RemoveRegisterAttribute. Fixes dotnet#5009
dellis1972 added a commit to dellis1972/xamarin-android that referenced this issue Oct 9, 2020
@dellis1972
[Xamarin.Android.Build.Tasks] Fast Deployment v2.0
1a382ee 
Fixes dotnet#5009
Fixes dotnet#5147

The Fast Deployment system used for debugging Xamarin.Android
apps has been completely re-written. This is mostly due to
changes in the android OS which means we can no longer use
the external storage directory to store assemblies.

Fast Deployment works by not including files which change often,
like assemblies, in the actual apk. This means the .apk will
mostly not need to be re-installed during a debugging/development
session. Instead the assemblies are "Fast Deployed" to a special
directory where a debug version of our runtime knows where to find
them.

Historically this was on the external storage directory such as

    `/storage/emulated/0/Android/data/com.some.package`
    `/mnt/shell/emulated/0/Android/data/com.some.package`
    `/storage/sdcard/Android/data/com.some.package`

With the advent of Android 11, these directories are no longer accessable.
So instead we need to deploy the assemblies into the app internal `files`
directory. This is usually located in `/data/data/com.some.package`. This
is not a global writable folder, so we need to use the `run-as` tool to
run all the commands to copy the files into that diectory.

The `run-as` tool does not always work on older devices. So from this point on
Fast Deployment will only be available on API 21 devices or newer. If a certain
device does not support the `run-as` tool, then you can always fall back to
debugging without Fast Deployment. While this is slower, it should still work
on most devices.

The [Enhanced Fast Deployment](~/android/deploy-test/building-apps/build-properties.md#AndroidFastDeploymentType) mode is still available with this new system.
This will deploy both assemblies, native libraries, typemaps and dexes to the `files`
directory. Support for Fast Deploying resources and assets via that system was
removed in commit [f0d565f](dotnet@f0d565f). This was becuase it required the use of
depreicated API's to work.

The Shared Runtime has also be removed in this new system. Before we used to deploy
the BCL and API specific assemblies via seperate .apks. This new system removes
the need for that. All the BCL and API specific assemblies will be deployed to the
`files` directory like all the other assemblies.

The new system is on par with the existing system when it comes to speed. More
improvements are planned in future releases which should make it much quicker.

Using the `samples\HelloWorld` project these are the performance differences
using `HelloWorld.csproj /restore /t:Install /v:n`

Old From Clean Time Elapsed 00:00:11.42
Old C# Change Time Elapsed 00:00:02.58

New From Clean Time Elapsed 00:00:11.78
New C# Change Time Elapsed 00:00:02.43
dellis1972 added a commit to dellis1972/xamarin-android that referenced this issue Oct 9, 2020
@dellis1972
[Xamarin.Android.Build.Tasks] Fast Deployment v2.0
42de456 
Fixes dotnet#5009
Fixes dotnet#5147
Fixes dotnet#4996

The Fast Deployment system used for debugging Xamarin.Android
apps has been completely re-written. This is mostly due to
changes in the android OS which means we can no longer use
the external storage directory to store assemblies.

Fast Deployment works by not including files which change often,
like assemblies, in the actual apk. This means the .apk will
mostly not need to be re-installed during a debugging/development
session. Instead the assemblies are "Fast Deployed" to a special
directory where a debug version of our runtime knows where to find
them.

Historically this was on the external storage directory such as

    `/storage/emulated/0/Android/data/com.some.package`
    `/mnt/shell/emulated/0/Android/data/com.some.package`
    `/storage/sdcard/Android/data/com.some.package`

With the advent of Android 11, these directories are no longer accessable.
So instead we need to deploy the assemblies into the app internal `files`
directory. This is usually located in `/data/data/com.some.package`. This
is not a global writable folder, so we need to use the `run-as` tool to
run all the commands to copy the files into that diectory.

The `run-as` tool does not always work on older devices. So from this point on
Fast Deployment will only be available on API 21 devices or newer. If a certain
device does not support the `run-as` tool, then you can always fall back to
debugging without Fast Deployment. While this is slower, it should still work
on most devices.

The [Enhanced Fast Deployment](~/android/deploy-test/building-apps/build-properties.md#AndroidFastDeploymentType) mode is still available with this new system.
This will deploy both assemblies, native libraries, typemaps and dexes to the `files`
directory. Support for Fast Deploying resources and assets via that system was
removed in commit [f0d565f](dotnet@f0d565f). This was becuase it required the use of
depreicated API's to work.

The Shared Runtime has also be removed in this new system. Before we used to deploy
the BCL and API specific assemblies via seperate .apks. This new system removes
the need for that. All the BCL and API specific assemblies will be deployed to the
`files` directory like all the other assemblies.

The new system is on par with the existing system when it comes to speed. More
improvements are planned in future releases which should make it much quicker.

Using the `samples\HelloWorld` project these are the performance differences
using `HelloWorld.csproj /restore /t:Install /v:n`

Old From Clean Time Elapsed 00:00:11.42
Old C# Change Time Elapsed 00:00:02.58

New From Clean Time Elapsed 00:00:11.78
New C# Change Time Elapsed 00:00:02.43
dellis1972 added a commit to dellis1972/xamarin-android that referenced this issue Oct 9, 2020
@dellis1972
[Xamarin.Android.Build.Tasks] Fast Deployment v2.0
d2d0179 
Fixes dotnet#5009
Fixes dotnet#5147
Fixes dotnet#4996

The Fast Deployment system used for debugging Xamarin.Android
apps has been completely re-written. This is mostly due to
changes in the android OS which means we can no longer use
the external storage directory to store assemblies.

Fast Deployment works by not including files which change often,
like assemblies, in the actual apk. This means the .apk will
mostly not need to be re-installed during a debugging/development
session. Instead the assemblies are "Fast Deployed" to a special
directory where a debug version of our runtime knows where to find
them.

Historically this was on the external storage directory such as

    `/storage/emulated/0/Android/data/com.some.package`
    `/mnt/shell/emulated/0/Android/data/com.some.package`
    `/storage/sdcard/Android/data/com.some.package`

With the advent of Android 11, these directories are no longer accessable.
So instead we need to deploy the assemblies into the app internal `files`
directory. This is usually located in `/data/data/com.some.package`. This
is not a global writable folder, so we need to use the `run-as` tool to
run all the commands to copy the files into that diectory.

The `run-as` tool does not always work on older devices. So from this point on
Fast Deployment will only be available on API 21 devices or newer. If a certain
device does not support the `run-as` tool, then you can always fall back to
debugging without Fast Deployment. While this is slower, it should still work
on most devices.

The [Enhanced Fast Deployment](~/android/deploy-test/building-apps/build-properties.md#AndroidFastDeploymentType) mode is still available with this new system.
This will deploy both assemblies, native libraries, typemaps and dexes to the `files`
directory. Support for Fast Deploying resources and assets via that system was
removed in commit [f0d565f](dotnet@f0d565f). This was becuase it required the use of
depreicated API's to work.

The Shared Runtime has also be removed in this new system. Before we used to deploy
the BCL and API specific assemblies via seperate .apks. This new system removes
the need for that. All the BCL and API specific assemblies will be deployed to the
`files` directory like all the other assemblies.

The new system is on par with the existing system when it comes to speed. More
improvements are planned in future releases which should make it much quicker.

Using the `samples\HelloWorld` project these are the performance differences
using `HelloWorld.csproj /restore /t:Install /v:n`

Old From Clean Time Elapsed 00:00:11.42
Old C# Change Time Elapsed 00:00:02.58

New From Clean Time Elapsed 00:00:11.78
New C# Change Time Elapsed 00:00:02.43
dellis1972 added a commit to dellis1972/xamarin-android that referenced this issue Oct 12, 2020
@dellis1972
[Xamarin.Android.Build.Tasks] Fast Deployment v2.0
4b6fd6b 
Fixes dotnet#5009
Fixes dotnet#5147
Fixes dotnet#4996

The Fast Deployment system used for debugging Xamarin.Android
apps has been completely re-written. This is mostly due to
changes in the android OS which means we can no longer use
the external storage directory to store assemblies.

Fast Deployment works by not including files which change often,
like assemblies, in the actual apk. This means the .apk will
mostly not need to be re-installed during a debugging/development
session. Instead the assemblies are "Fast Deployed" to a special
directory where a debug version of our runtime knows where to find
them.

Historically this was on the external storage directory such as

    `/storage/emulated/0/Android/data/com.some.package`
    `/mnt/shell/emulated/0/Android/data/com.some.package`
    `/storage/sdcard/Android/data/com.some.package`

With the advent of Android 11, these directories are no longer accessable.
So instead we need to deploy the assemblies into the app internal `files`
directory. This is usually located in `/data/data/com.some.package`. This
is not a global writable folder, so we need to use the `run-as` tool to
run all the commands to copy the files into that diectory.

The `run-as` tool does not always work on older devices. So from this point on
Fast Deployment will only be available on API 21 devices or newer. If a certain
device does not support the `run-as` tool, then you can always fall back to
debugging without Fast Deployment. While this is slower, it should still work
on most devices.

The [Enhanced Fast Deployment](~/android/deploy-test/building-apps/build-properties.md#AndroidFastDeploymentType) mode is still available with this new system.
This will deploy both assemblies, native libraries, typemaps and dexes to the `files`
directory. Support for Fast Deploying resources and assets via that system was
removed in commit [f0d565f](dotnet@f0d565f). This was becuase it required the use of
depreicated API's to work.

The Shared Runtime has also be removed in this new system. Before we used to deploy
the BCL and API specific assemblies via seperate .apks. This new system removes
the need for that. All the BCL and API specific assemblies will be deployed to the
`files` directory like all the other assemblies.

The new system is on par with the existing system when it comes to speed. More
improvements are planned in future releases which should make it much quicker.

Using the `samples\HelloWorld` project these are the performance differences
using `HelloWorld.csproj /restore /t:Install /v:n`

Old From Clean Time Elapsed 00:00:11.42
Old C# Change Time Elapsed 00:00:02.58

New From Clean Time Elapsed 00:00:11.78
New C# Change Time Elapsed 00:00:02.43
dellis1972 added a commit to dellis1972/xamarin-android that referenced this issue Oct 12, 2020
@dellis1972
[Xamarin.Android.Build.Tasks] Fast Deployment v2.0
9d4828a 
Fixes dotnet#5009
Fixes dotnet#5147
Fixes dotnet#4996

The Fast Deployment system used for debugging Xamarin.Android
apps has been completely re-written. This is mostly due to
changes in the android OS which means we can no longer use
the external storage directory to store assemblies.

Fast Deployment works by not including files which change often,
like assemblies, in the actual apk. This means the .apk will
mostly not need to be re-installed during a debugging/development
session. Instead the assemblies are "Fast Deployed" to a special
directory where a debug version of our runtime knows where to find
them.

Historically this was on the external storage directory such as

    `/storage/emulated/0/Android/data/com.some.package`
    `/mnt/shell/emulated/0/Android/data/com.some.package`
    `/storage/sdcard/Android/data/com.some.package`

With the advent of Android 11, these directories are no longer accessable.
So instead we need to deploy the assemblies into the app internal `files`
directory. This is usually located in `/data/data/com.some.package`. This
is not a global writable folder, so we need to use the `run-as` tool to
run all the commands to copy the files into that diectory.

The `run-as` tool does not always work on older devices. So from this point on
Fast Deployment will only be available on API 21 devices or newer. If a certain
device does not support the `run-as` tool, then you can always fall back to
debugging without Fast Deployment. While this is slower, it should still work
on most devices.

The [Enhanced Fast Deployment](~/android/deploy-test/building-apps/build-properties.md#AndroidFastDeploymentType) mode is still available with this new system.
This will deploy both assemblies, native libraries, typemaps and dexes to the `files`
directory. Support for Fast Deploying resources and assets via that system was
removed in commit [f0d565f](dotnet@f0d565f). This was becuase it required the use of
depreicated API's to work.

The Shared Runtime has also be removed in this new system. Before we used to deploy
the BCL and API specific assemblies via seperate .apks. This new system removes
the need for that. All the BCL and API specific assemblies will be deployed to the
`files` directory like all the other assemblies.

The new system is on par with the existing system when it comes to speed. More
improvements are planned in future releases which should make it much quicker.

Using the `samples\HelloWorld` project these are the performance differences
using `HelloWorld.csproj /restore /t:Install /v:n`

Old From Clean Time Elapsed 00:00:11.42
Old C# Change Time Elapsed 00:00:02.58

New From Clean Time Elapsed 00:00:11.78
New C# Change Time Elapsed 00:00:02.43
dellis1972 added a commit to dellis1972/xamarin-android that referenced this issue Oct 12, 2020
@dellis1972
[Xamarin.Android.Build.Tasks] Fast Deployment v2.0
74485cc 
Fixes dotnet#5009
Fixes dotnet#5147
Fixes dotnet#4996

The Fast Deployment system used for debugging Xamarin.Android
apps has been completely re-written. This is mostly due to
changes in the android OS which means we can no longer use
the external storage directory to store assemblies.

Fast Deployment works by not including files which change often,
like assemblies, in the actual apk. This means the .apk will
mostly not need to be re-installed during a debugging/development
session. Instead the assemblies are "Fast Deployed" to a special
directory where a debug version of our runtime knows where to find
them.

Historically this was on the external storage directory such as

    `/storage/emulated/0/Android/data/com.some.package`
    `/mnt/shell/emulated/0/Android/data/com.some.package`
    `/storage/sdcard/Android/data/com.some.package`

With the advent of Android 11, these directories are no longer accessable.
So instead we need to deploy the assemblies into the app internal `files`
directory. This is usually located in `/data/data/com.some.package`. This
is not a global writable folder, so we need to use the `run-as` tool to
run all the commands to copy the files into that diectory.

The `run-as` tool does not always work on older devices. So from this point on
Fast Deployment will only be available on API 21 devices or newer. If a certain
device does not support the `run-as` tool, then you can always fall back to
debugging without Fast Deployment. While this is slower, it should still work
on most devices.

The [Enhanced Fast Deployment](~/android/deploy-test/building-apps/build-properties.md#AndroidFastDeploymentType) mode is still available with this new system.
This will deploy both assemblies, native libraries, typemaps and dexes to the `files`
directory. Support for Fast Deploying resources and assets via that system was
removed in commit [f0d565f](dotnet@f0d565f). This was becuase it required the use of
depreicated API's to work.

The Shared Runtime has also be removed in this new system. Before we used to deploy
the BCL and API specific assemblies via seperate .apks. This new system removes
the need for that. All the BCL and API specific assemblies will be deployed to the
`files` directory like all the other assemblies.

The new system is on par with the existing system when it comes to speed. More
improvements are planned in future releases which should make it much quicker.

Using the `samples\HelloWorld` project these are the performance differences
using `HelloWorld.csproj /restore /t:Install /v:n`

Old From Clean Time Elapsed 00:00:11.42
Old C# Change Time Elapsed 00:00:02.58

New From Clean Time Elapsed 00:00:11.78
New C# Change Time Elapsed 00:00:02.43
jonpryor pushed a commit that referenced this issue Oct 12, 2020
@dellis1972
[Xamarin.Android.Build.Tasks] Fast Deployment v2.0 (#4690)
71dc718 
Fixes: #4996
Fixes: #5009
Fixes: #5147

Changes: xamarin/monodroid@1ac5333...767f647

  * xamarin/monodroid@767f64715: [msbuild] Fast Deployment v2.0 (#1090)
  * xamarin/monodroid@0f04ba56d: Merge pull request #1115 from xamarin/remove-xreitem
  * xamarin/monodroid@d75341fc3: Remove provisionator file completely
  * xamarin/monodroid@b62e8c693: Replace XreItem with supported Xcode and JavaJDK syntax

The Fast Deployment system used for debugging Xamarin.Android apps has
been completely re-written.  This is mostly due to changes in Android
which means we can no longer use the external storage directory to
store assemblies.

Fast Deployment works by not including files which change often,
like assemblies, in the actual apk.  This means the `.apk` will mostly
not need to be re-installed during a debugging/development session.
Instead the assemblies are "Fast Deployed" to a special directory where
a debug version of our runtime knows where to find them.

Historically this was on the external storage directory such as

	/storage/emulated/0/Android/data/com.some.package
	/mnt/shell/emulated/0/Android/data/com.some.package
	/storage/sdcard/Android/data/com.some.package

With Android 11, these directories are no longer accessible.  Instead,
we need to deploy the assemblies into the app's internal `files`
directory.  This is usually located in `/data/data/@PACKAGE_NAME@`.
This is not a global writable folder, so we need to use the `run-as`
tool to run all the commands to copy the files into that directory.

The `run-as` tool does not always work on older devices.  From this
point on Fast Deployment v2 will only be available on API-21+ devices.
If a certain device does not support the `run-as` tool, then you can
always fall back to debugging without Fast Deployment.  While this is
slower, it should still work on most devices.

[`$(AndroidFastDeploymentType)`][0] is still supported.  This will
deploy both assemblies, native libraries, typemaps, and `.dex` files to
the `files` directory.  Support for Fast Deploying Android resources
and assets was removed in commit f0d565f, as it required the use of
deprecated API's to work.

The Shared Runtime has also be removed in this new system.  Previously,
we used to deploy the BCL and API specific assemblies via separate
`.apk` files.  This new system removes the need for that.  All the BCL
and API specific assemblies will be deployed to the `files` directory
like all the other assemblies.

The new system is on par with the existing system when it comes to
speed.  More improvements are planned in future releases which should
make it much quicker.

Using the `samples\HelloWorld` project these are the performance
differences using `HelloWorld.csproj /restore /t:Install /v:n`:

  * Deploy "from Clean"
    * v1: 00:00:11.42
    * v2: 00:00:11.78 [3% longer]
  * Incrementally deploy C#-based change
    * v1: 00:00:02.58
    * v2: 00:00:02.43 [6% faster]

[0]: https://docs.microsoft.com/en-us/xamarin/android/deploy-test/building-apps/build-properties#androidfastdeploymenttype
@brendanzagaeski brendanzagaeski added the bug Component does not function as intended. label Nov 10, 2020
@brendanzagaeski
Copy link
Contributor Author

Release status update

A new Preview version of Xamarin.Android has now been published that includes the fix for this item.

Fix included in Xamarin.Android SDK version 11.1.99.168.

Fix included on Windows in Visual Studio 2019 version 16.9 Preview 1. To try the Preview version that includes the fix, check for the latest updates in Visual Studio Preview.

Fix included on macOS in Visual Studio 2019 for Mac version 8.9 Preview 1. To try the Preview version that includes the fix, check for the latest updates on the Preview updater channel.

@ghost ghost locked as resolved and limited conversation to collaborators Jun 4, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@dellis1972 dellis1972

@jonathanpeppers jonathanpeppers

Labels
Area: App+Library Build Issues when building Library projects or Application projects. bug Component does not function as intended.
Projects
None yet
Milestone
Published: 11.2 (d16-9)
Development

Successfully merging a pull request may close this issue.

[Xamarin.Android.Build.Tasks] Fast Deployment v2.0 dellis1972/xamarin-android
3 participants
@dellis1972 @jonathanpeppers @brendanzagaeski