Changes: dotnet/java-interop@0ad0d40...66312f7

* Bump to dotnet/android-tools@8722663

* [Java.Interop.Tools.JavaCallableWrappers] Improve missing attribute

Changes: dotnet/dotnet@7b29526...ba86126

- **Updates**:
  - From [10.0.0-beta.25523.113 to 10.0.0-beta.25531.102][3]
     - Microsoft.DotNet.Build.Tasks.Feed
  - From [0.11.5-alpha.25523.113 to 0.11.5-alpha.25531.102][3]
     - Microsoft.DotNet.Cecil
  - From [10.0.0-rtm.25523.113 to 10.0.0-rtm.25531.102][3]
     - Microsoft.NET.ILLink
  - From [10.0.100-rtm.25523.113 to 10.0.100-rtm.25531.102][3]
     - Microsoft.NET.Sdk
  - From [10.0.100 to 10.0.100][3]
     - Microsoft.NET.Workload.Emscripten.Current.Manifest-10.0.100
     - Microsoft.TemplateEngine.Authoring.Tasks
  - From [10.0.0 to 10.0.100][4]
     - Microsoft.NET.Workload.Mono.Toolchain.Current.Manifest-10.0.100
  - From [10.0.0 to 10.0.0][3]
     - Microsoft.NETCore.App.Ref

[3]: dotnet/dotnet@7b29526...ba86126

Changes: dotnet/dotnet@ba86126...93970af

- **Dependency Updates**:
  - From [10.0.0-beta.25531.102 to 10.0.0-beta.25563.104][1]
     - Microsoft.DotNet.Build.Tasks.Feed
  - From [0.11.5-alpha.25531.102 to 0.11.5-alpha.25563.104][1]
     - Microsoft.DotNet.Cecil
  - From [10.0.0-rtm.25531.102 to 10.0.1-servicing.25563.104][1]
     - Microsoft.NET.ILLink
  - From [10.0.100-rtm.25531.102 to 10.0.101-servicing.25563.104][1]
     - Microsoft.NET.Sdk
  - From [10.0.100 to 10.0.101][1]
     - 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.0 to 10.0.1][1]
     - Microsoft.NETCore.App.Ref

[1]: dotnet/dotnet@ba86126...93970af

Fixes: #10601
Context: https://android.googlesource.com/platform//system/extras/+/3c784e9fd9f4e3f8e363a023939567c41c19d634%5E%21/#F0

For 64-bit native libraries Android allows the alignment to be 16k at the minimum,
with any higher value acceptable as long as it's a power of two.

With this commit we follow suit, accepting the same set of values as Android.

Fixes: #10596

- Updated the local file path from `AndroidManifestFeed_d17.12.xml`
   to `AndroidManifestFeed_d18.0.xml`

- Updated the fallback URL from `https://aka.ms/AndroidManifestFeed/d17-12`
   to `https://aka.ms/AndroidManifestFeed/d18-0`

The Dev18 (`d18-0`) feed contains the `android-36` and `android-36.1`
platform entries needed for .NET 10.

Co-authored-by: Jonathan Peppers <jonathan.peppers@microsoft.com>

Related: #10567

Implement enhanced `{g,l}ref` logging for CoreCLR and NativeAOT.

Enhanced support allows one to see stack traces of where the global
and local references creation/deletion methods were called from. Output
can go to logcat, a file, or both. Support for this existed in the
MonoVM-based runtime "forever", but it was not implemented in the CoreCLR
or NativeAOT based runtimes.

This caused segmentation faults whenver an application using either
CoreCLR or NativeAOT based runtimes parsed the `debug.mono.log` property
and found the `gref+` or `lref+` keyword in it. This was due to the fact
that the old code never expected to get a `NULL` pointer from the managed
land, instead of a string with the managed stack trace. 
The `NULL` pointer was passed to the native code because the NativeAOT-based 
runtime didn't see the `{g,l}ref` logging categories enabled (on the managed 
side) by the time it called the native `{g,l}ref` management function. This 
resulted in it not collecting the call stack trace and, thus, passing a `NULL` 
pointer.

Furthermore, setting `debug.mono.log` property to `gref=/path/to/file.txt`
would have no effect - no file was created and no traces were logged.

This commit fixes all of the above issues and, additionally, makes stack
trace logging more efficient, more secure (no more use of raw pointers) as
well as with less code duplication.

Also implemented are minute changes to the NativeAOT application init
sequence, so that we have the logging categories properly set in the
managed land before any code that needs them runs.

Changes: dotnet/dotnet@93970af...ed2ddf8

- **Dependency Updates**:
  - From [10.0.0-beta.25563.104 to 10.0.0-beta.25605.116][3]
     - Microsoft.DotNet.Build.Tasks.Feed
  - From [0.11.5-alpha.25563.104 to 0.11.5-alpha.25605.116][3]
     - Microsoft.DotNet.Cecil
  - From [10.0.1-servicing.25563.104 to 10.0.2-servicing.25605.116][3]
     - Microsoft.NET.ILLink
  - From [10.0.101-servicing.25563.104 to 10.0.102-servicing.25605.116][3]
     - Microsoft.NET.Sdk
  - From [10.0.101 to 10.0.102][3]
     - 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.1 to 10.0.2][3]
     - Microsoft.NETCore.App.Ref

[3]: dotnet/dotnet@93970af...ed2ddf8

Other changes:

* Feeds for dotnet/runtime 9.0.12

Co-authored-by: Jonathan Peppers <jonathan.peppers@microsoft.com>

…o` (#10642)

Fixes: #10634

Amazon application store appears to verify the uploaded archives by,
among other steps, comparing names of libraries packaged into per-ABI
`lib/` directories. If it finds library names that don't correspond to
entries in any of the other `lib/{ABI}` directories, it decides that
the application is incorrectly constructed and rejects the upload.

In our case the check failed because of names of the assembly store files
in the archive which are named `libassemblies.{ABI}.blob.so` and, thus,
would have unique entries in every `lib/{ABI}/` directory. This is an artifact
from the time where all stores were placed in a single directory (`assemblies/`)
and had to have distinct names in order for that to work.

The Amazon store check, in this regard, is just an unnecessary obstacle
(since there's no reason, technical or otherwise, for different ABIs to
have identical sets of libraries), but since a we have no way to fix it
other than to comply with the Amazon store requirements and, this PR
renames assembly store files to have a uniform name across all the ABIs
present in the application: `libassembly-store.so`

Co-authored-by: Marek Habersack <grendel@twistedcode.net>

…10626)

**Logging around test timeouts**

* Added a new `diagnose-hanging-processes.yaml` template that collects
  detailed diagnostics about running processes, disk/memory usage,
  network connections, and system logs for both macOS/Linux and
  Windows agents. This helps troubleshoot stuck test jobs by providing
  more actionable information.

* Integrated the new template into the `run-nunit-tests.yaml` and
  `run-sliced-nunit-tests.yaml` pipelines, so diagnostics are
  automatically run when tests hang or fail.

This allowed copilot to discover:

    The problem: `dotnet nuget locals` command is spinning at 85-77% CPU for 129+ minutes (process ID 27626)

    This process started at 11:36PM and was still running at 1:48AM when diagnostics were captured, consuming massive CPU:

    runner  27626  85.2%  /Users/runner/work/1/s/bin/Release/dotnet/dotnet nuget locals --list global-packages

**Fix**

* Improved the `FindNugetGlobalPackageFolder` method in
  `FileSystemUtils.cs` by adding result caching. This avoids repeated
  environment checks and process invocations, reducing overhead during
  test setup.

Changes: dotnet/dotnet@ed2ddf8...a1b9d99

- **Dependency Updates**:
  - From [10.0.0-beta.25605.116 to 10.0.0-beta.25612.103][1]
     - Microsoft.DotNet.Build.Tasks.Feed
  - From [0.11.5-alpha.25605.116 to 0.11.5-alpha.25612.103][1]
     - Microsoft.DotNet.Cecil
  - From [10.0.2-servicing.25605.116 to 10.0.2-servicing.25612.103][1]
     - Microsoft.NET.ILLink
  - From [10.0.102-servicing.25605.116 to 10.0.102-servicing.25612.103][1]
     - Microsoft.NET.Sdk
  - From [10.0.102 to 10.0.102][1]
     - 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.2][1]
     - Microsoft.NETCore.App.Ref

[1]: dotnet/dotnet@ed2ddf8...a1b9d99