[Xamarin.Android.Build.Tasks] implement dotnet run with an MSBuild target

[jonathanpeppers]

Context: dotnet/sdk#42155
Context: dotnet/sdk#42240
Fixes: dotnet/sdk#31253

The .NET SDK has introduced a new ComputeRunArguments MSBuild target that allows you to set $(RunCommand) and $(RunArguments) in a more dynamic way.

So, on Android:

• ComputeRunArguments depends on Install, so the app is deployed, the <FastDeploy/> MSBuild target runs, etc.

• $(RunCommand) is a path to adb

• $(RunArguments) is an shell am start command to launch the main activity.

The new implementation also allows us to use the -p parameter with dotnet run, such as:

dotnet run -bl -p:AdbTarget=-d

This will pass -d to adb, which allows you to select an attached device if an emulator is running.

Previously, we had no way to pass -p arguments to dotnet run.

[jonathanpeppers]

Note that before, we had no way to parse all the -p arguments passed to dotnet run through to the underlying Run target. We had $(Configuration) hardcoded here, but that was the only one that worked.

[dellis1972]

How will this effect the monodroid RunActivity and debugging system ? https://github.com/xamarin/monodroid/blob/main/tools/msbuild/Xamarin.Android.Common.Debugging.targets#L201

[jonathanpeppers]

The new target here is only invoked by dotnet run, and then the options are to set $(RunCommand) and $(RunArguments) to an adb command.

This won't affect any existing targets, but we could consider refactoring later to try to share more code. I couldn't reuse the <AndroidAdb/> task the way $(RunCommand) is used by the dotnet CLI:

android/src/Xamarin.Android.Build.Tasks/Xamarin.Android.Application.targets

Lines 23 to 29 in 13b7378

	<AndroidAdb
	ToolExe="$(AdbToolExe)"
	ToolPath="$(AdbToolPath)"
	AdbTarget="$(AdbTarget)"
	Command="shell"
	Arguments="am start -S -n &quot;$(_AndroidPackage)/$(AndroidLaunchActivity)&quot;"
	/>

[jonpryor]

What gives me pause is:

ComputeRunArguments depends on Install

which I interpret as meaning "every dotnet run command will implicitly Install the app."

I'm not sure that this is desirable? In a non-fastdev environment, Install takes ~8-9 seconds for an unchanged "hello world" template, because it just re-installs the .apk every time. (The Install and _DeployApk targets don't check that the app has already been installed in any way.)

I think dotnet run shouldn't install-by-default, though I'm overall torn about what semantics should actually be.

Additionally, dotnet run should ensure that the app has been killed before restarting.

[jonathanpeppers]

which I interpret as meaning "every dotnet run command will implicitly Install the app."

If we didn't do this, the app would never be installed.

One example is:

• dotnet build
• dotnet run --no-build

It seems like we have to deploy? Otherwise, we need a "deployed" concept in the dotnet-cli.

Additionally, dotnet run should ensure that the app has been killed before restarting.

If the Install target and <FastDeploy/> task do this already, is there another place this is needed?