…rget (#10576)

Context: https://github.com/dotnet/sdk/blob/2b9fc02a265c735f2132e4e3626e94962e48bdf5/documentation/specs/dotnet-run-for-maui.md

This implements the first couple of steps to support new `dotnet run`
behavior in .NET 11.

* `$(Device)` MSBuild property to specify target device (passed from
  `dotnet run --device <id>`). This will simply set `$(AdbTarget)` for
  now.

* `ComputeAvailableDevices` MSBuild target to get the list of
  connected Android devices/emulators using `adb devices` command:

    Target ComputeAvailableDevices  55 ms
      Using "GetAvailableAndroidDevices" task from assembly "D:\src\xamarin-android\bin\Debug\lib\packs\Microsoft.Android.Sdk.Windows\36.1.99\targets\..\tools\Xamarin.Android.Build.Tasks.dll".
      Task GetAvailableAndroidDevices  55 ms
        Assembly = D:\src\xamarin-android\bin\Debug\lib\packs\Microsoft.Android.Sdk.Windows\36.1.99\tools\Xamarin.Android.Build.Tasks.dll
        Parameters
          16:47:08.2643378  C:\Program Files (x86)\Android\android-sdk\platform-tools\adb.exe devices -l
          16:47:08.2867570  List of devices attached
          16:47:08.2867734  0A041FDD400327  device product:redfin model:Pixel_5 device:redfin transport_id:2
          16:47:08.2867765  emulator-5554  device product:sdk_gphone64_x86_64 model:sdk_gphone64_x86_64 device:emu64xa transport_id:1
          16:47:08.2920363  Running process: C:\Program Files (x86)\Android\android-sdk\platform-tools\adb.exe -s emulator-5554 emu avd name
          16:47:08.3172534  pixel_7_-_api_36
          16:47:08.3172747  OK
          16:47:08.3183905  Running process: exit code == 0
          16:47:08.3185099  Found 2 Android device(s)/emulator(s)
        OutputItems
          TargetOutputs
            0A041FDD400327
              Status = Online
              Type = Device
              Device = redfin
              TransportId = 2
              Description = Pixel 5
              Product = redfin
              Model = Pixel_5
            emulator-5554
              Status = Online
              Type = Emulator
              Device = emu64xa
              TransportId = 1
              Description = pixel 7 - api 36
              Product = sdk_gphone64_x86_64
              Model = sdk_gphone64_x86_64

Some of the extra MSBuild item metadata was completely optional, I
just left anything that `adb devices -l` reports to be in here.

Added unit tests for `GetAvailableAndroidDevices` task, that mostly
test input/output parsing without actually running `adb`.

Context: dotnet/sdk#51337
Context: dotnet/sdk#51914

In 63f7cba, we added the `ComputeAvailableDevices` MSBuild target,
which I was able to test end-to-end:

    D:\src\helloandroid> D:\src\dotnet\sdk\artifacts\bin\redist\Debug\dotnet\dotnet.exe run -bl
    Select a device to run on:

    > 0A041FDD400327 - Pixel 5
    emulator-5554 - pixel 7 - api 36

    Type to search

Unfortunately, the AVD name is returned from `adb emu avd name`, which
simply returns the property:

    > adb -s emulator-5554 shell getprop | grep avd_name
    [ro.boot.qemu.avd_name]: [pixel_7_-_api_36]

We can call `TextInfo.ToTitleCase()`, replace underscores with spaces,
and replace "Api" with "API" to make the AVD name more user-friendly.

The only other alternative I considered was parsing the
`~/.android/avd/<name>.ini` file to get the `displayname` property,
but it would still require calling `adb emu avd name` to *get* the
path to this `.ini` file. It felt more straightforward to just format
the AVD name directly.

Context: https://github.com/dotnet/sdk/blob/c164a9bc1246c48191fb780992530f0fe975141b/documentation/specs/dotnet-run-for-maui.md

Implements the `DeployToDevice` MSBuild target per the `dotnet run` spec
for .NET MAUI scenarios. This target allows deploying an already-built
app to a device without rebuilding, supporting the `dotnet run`
workflow.

The target reuses existing deployment logic but skips the full build,
enabling faster iteration when only deployment is needed e.g.
`--no-build`.

Also consolidates `$(SignAndroidPackageDependsOn)`,
`$(InstallDependsOnTargets)`, and `$(UninstallDependsOnTargets)`
properties into `BuildOrder.targets` to keep all target dependency
ordering in one place.

Adds test coverage to verify the target deploys successfully and the
app can be launched via adb commands.

In cd88d9c, we introduced a new `DeployToDevice` target for new
`dotnet run` support.

However, the following `Condition` doesn't work due to build order:

    <DeployToDeviceDependsOnTargets Condition=" '$(_XASupportsFastDev)' == 'true' ">
      $(_MinimalSignAndroidPackageDependsOn);
      _Upload;
    </DeployToDeviceDependsOnTargets>
    <DeployToDeviceDependsOnTargets Condition=" '$(_XASupportsFastDev)' != 'true' ">
      $(_MinimalSignAndroidPackageDependsOn);
      _DeployApk;
      _DeployAppBundle;
    </DeployToDeviceDependsOnTargets>

* `Microsoft.Android.Sdk.BuildOrder.targets` is imported right before
  `Xamarin.Android.Common.targets` where `$(_XASupportsFastDev)` is set.

To fix this:

* Let's rename `$(_XASupportsFastDev)` to `$(_AndroidFastDeploymentSupported)`
  to just modernize the name.

* Move `$(_AndroidFastDeploymentSupported)` to
  `Microsoft.Android.Sdk.DefaultProperties.targets` that is imported
  early on.

* Update a test to verify the proper targets run in `DeployToDevice`
  target.

Context: dotnet/sdk#52046
Context: https://github.com/dotnet/sdk/blob/c164a9bc1246c48191fb780992530f0fe975141b/documentation/specs/dotnet-run-for-maui.md

When the `DeployToDevice` target is run by the `dotnet run` pipeline,
we will no longer need to make the `ComputeRunArguments` target deploy
anything.

We are thinking this feature can ship in future .NET 11 and 10.0.200
SDKs.

Fixes: #10645

For alignment with other platforms, including `dotnet new console`,
`dotnet run` for Android should:

* Show console output for the launched process
* Exit if the app closes
* Close the app on Ctrl+C

A one-liner like this is *close*:

    adb shell 'am start -S -W -n "PACKAGE/ACTIVITY"; pid=$(pidof PACKAGE); logcat --pid=$pid'

But then Ctrl+C does not close the app, so to wire this all together,
add a simple console app to be invoked by `dotnet run`.

We do not initially intend for this app to be run directly by users,
so it is placed in the `tools` folder of the SDK pack and not a .NET
global tool.

New MSBuild properties:

`$(WaitForExit)`

* Default: (empty)
* When `false`, allow users to disable waiting for the app to exit,
which is useful for our existing tests.

`$(_AndroidRunPath)`

* Default: `$(MSBuildThisFileDirectory)..\tools\Microsoft.Android.Run.dll`
* Allows overriding the path to the `Microsoft.Android.Run` assembly.

`$(_AndroidRunExtraArgs)`
* Default: (empty)
* Allows extra args like `--verbose` passed in

This simplifies my work on the dotnet/sdk repo, as the development
branch is still .NET 10 at release/10.0.2xx (or 3xx).

This tool is simple, so it seems fine to use
`$(DotNetStableTargetFramework)` for now and allow it to roll forward.

Fixes: #10657
Fixes: #10654

When using the CoreCLR runtime, the `AppDomain.UnhandledException`
event handlers were not raised. This has many implications, one of
them being that crash reporting tools don't work as expected.

This PR adds the missing functionality of forwarding the exceptions
from native code to managed code. Some notable aspects of this PR:

* We use `ExceptionHandling.RaiseAppDomainUnhandledExceptionEvent`
  instead of Mono's native `mono_unhandled_exception` to raise the
  events. There is one observable change in behavior and that's that
  CoreCLR does not pass the `sender` (Mono passes the app domain). The
  existing unit test had to reflect this change.

* The `JNIEnvInit.Initialize` method returns the UCO fnptr through the
  `args` struct. I believe this is a clean way of doing it and
  hopefully it doesn't add too much confusion. This is a more
  efficient way of obtaining the function pointer than calling
  `coreclr_create_delegate`. We have to use this to get the delegate
  for the `Initialize` method itself, but it might be a good idea to
  return the funptr for `RegisterNatives` this way as well (and avoid
  passing it completely at some later point when we have working
  Marshal Methods on CoreCLR, allowing for (unmeasurably?) faster
  startup and improved trimming)

`prop.Value.GetRawText ()` returns a string value `foo` as `"foo"`.

Let's instead switch on `JsonValueKind` and handle each type
appropriately.

The existing `AppContextTests` should verify this when we enable the
`RuntimeConfig` category.

…10670)

Context: https://github.com/dotnet/runtime/blob/242f7b23752599f22157268de41fee91cb97ef6c/docs/design/features/host-startup-hook.md

.NET has a concept of a "startup hook", which appears to work fine
on Mono if you set:

    env.txt
        DOTNET_STARTUP_HOOKS=StartupHook
    (MSBuild)
        <StartupHookSupport>true</StartupHookSupport>
        <RuntimeHostConfigurationOption Include="STARTUP_HOOKS" Value="StartupHook" />

The startup hook is a managed assembly with a static method, in the
"global" namespace:

    class StartupHook
    {
        public static void Initialize()
        {
            // ...
        }
    }

When the runtime starts, it will call `StartupHook.Initialize()` before
any other managed code is executed.

`dotnet watch` (Hot Reload) relies on this feature.

I added tests to verify startup hooks are called on Android for
all runtimes.

* [coreclr] call `System.StartupHookProvider.ProcessStartupHooks()`

This feature only works on CoreCLR if you have a `static void Main()`,
which we do not on Android. For now, I called the `StartupHookProvider`
directly with System.Reflection. We can address in dotnet/runtime
in the future.

Context: #10656
Partial backport of: 9297282

**Minor Build Task Fix:**

* Simplified the `AdbTarget` property in
  `Xamarin.Android.Common.targets` by removing unnecessary quotation
  marks around the device name.

Backports:
* #10576
* #10623
* #10631
* #10641
* #10640
* #10646
* #10692

Partial backport of:
* #10692
* 9297282

Changes: dotnet/dotnet@a1b9d99...99f9e99

- **Dependency Updates**:
  - From [10.0.0-beta.25612.103 to 10.0.0-beta.26065.102][5]
     - Microsoft.DotNet.Build.Tasks.Feed
  - From [0.11.5-alpha.25612.103 to 0.11.5-alpha.26065.102][5]
     - Microsoft.DotNet.Cecil
  - From [10.0.2-servicing.25612.103 to 10.0.3-servicing.26065.102][5]
     - Microsoft.NET.ILLink
  - From [10.0.102-servicing.25612.103 to 10.0.103-servicing.26065.102][5]
     - Microsoft.NET.Sdk
  - From [10.0.102 to 10.0.103][5]
     - Microsoft.NET.Workload.Emscripten.Current.Manifest-10.0.100
     - Microsoft.NET.Workload.Mono.Toolchain.Current.Manifest-10.0.100
     - Microsoft.TemplateEngine.Authoring.Tasks
  - From [10.0.2 to 10.0.3][5]
     - Microsoft.NETCore.App.Ref

Other changes:

- Feeds for dotnet/runtime 9.0.13

[5]: dotnet/dotnet@a1b9d99...99f9e99

This was introduced when backporting changes, but the test needed
to parameterize on this release branch, such as:

    [TestCase (AndroidRuntime.MonoVM)]
    [TestCase (AndroidRuntime.CoreCLR)]
    public void SubscribeToAppDomainUnhandledException (AndroidRuntime runtime)

And then call `proj.SetRuntime (runtime)` appropriately.

…10730)

Context: dotnet/sdk#52566

Newer .NET SDKs want this value to be set, to prevent a restore of your desktop OS's RID.

Bumps [external/xamarin-android-tools](https://github.com/dotnet/android-tools) from `8722663` to `c8b05f6`.
- [Commits](dotnet/android-tools@8722663...c8b05f6)

---
updated-dependencies:
- dependency-name: external/xamarin-android-tools
  dependency-version: c8b05f6dce08076758f28825ed261b92cf51b491
  dependency-type: direct:production
...

Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

Bumps [external/xamarin-android-tools](https://github.com/dotnet/android-tools) from `c8b05f6` to `ca74eba`.
- [Commits](dotnet/android-tools@c8b05f6...ca74eba)

---
updated-dependencies:
- dependency-name: external/xamarin-android-tools
  dependency-version: ca74eba74c729bbd203008c32040eee6e4d017e4
  dependency-type: direct:production
...

Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Jonathan Peppers <jonathan.peppers@microsoft.com>

Bumps [external/xamarin-android-tools](https://github.com/dotnet/android-tools) from `ca74eba` to `fb95edd`.
- [Commits](dotnet/android-tools@ca74eba...fb95edd)

---
updated-dependencies:
- dependency-name: external/xamarin-android-tools
  dependency-version: fb95edd359e6a6af9aecc4c82520f5a5f2ede824
  dependency-type: direct:production
...

Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>