Context: https://github.com/dotnet/android/blame/release/9.0.1xx/Directory.Build.props
Context: 61a7677
Context: 0f2a323

Brings in stable versioning changes from previous .NET 9 release
branch.  We've historically added a few new version properties to
represent the stable version and calculate the patch delta.

`$(AndroidPackVersion)` has been updated to "reset" the commit
distance.

Changes: dotnet/java-interop@19be370...0ad0d40

* [generator] Revert changes to [UnsupportedOSPlatform]

Context: #10509

These should already be working on `release/10.0.1xx`, due to changes already reverted.

Update an existing test for #10509.

Context: dotnet/macios#23701
Context: #10453

In 398602e, we moved to the new `MicroBuildTemplate` and `v4` signing template.

It appears there is an additional file we need for `real` signing to work.

When cherry-picking the commit, I noticed:

    Updating 61674e1..e04201b
    Fast-forward
    .../policies/branchClassification.yml\342\200\216"          | 13 +++++++++++++
    1 file changed, 13 insertions(+)
    create mode 100644 ".azuredevops/policies/branchClassification.yml\342\200\216"

`\342\200\216` indicated some weird invisible character!

I must have done this when copy-pasting the file path from GitHub's
web UI?

Rename the file to the correct name:

    Changes to be committed:
        renamed:    ".azuredevops/policies/branchClassification.yml\342\200\216" -> .azuredevops/policies/branchClassification.yml

This will supposedly resolve our signing issues, so I removed this
value and copied the condition in each location.

Changes: dotnet/dotnet@2dea164...23dafb1

- **Updates**:
  - From [10.0.0-beta.25468.104 to 10.0.0-beta.25475.111][1]
     - Microsoft.DotNet.Build.Tasks.Feed
  - From [0.11.5-alpha.25468.104 to 0.11.5-alpha.25475.111][1]
     - Microsoft.DotNet.Cecil
  - From [10.0.0-rc.2.25468.104 to 10.0.0-rtm.25475.111][1]
     - Microsoft.NET.ILLink.Tasks
     - Microsoft.NETCore.App.Ref
  - From [10.0.100-rc.2.25468.104 to 10.0.100-rtm.25475.111][1]
     - Microsoft.NET.Sdk
     - Microsoft.TemplateEngine.Authoring.Tasks

[1]: dotnet/dotnet@2dea164...23dafb1

Context: http://github.com/jpobst/BindingStudio
Context: #10005

Use jpobst/BindingStudio to begin enumifying API-36.1.

Note: current dotnet/java-interop emits an "extra" `,` on `map.csv`
output, which would make for a "noisy" diff (every line changed!).
The diff size is reduced by removing trailing commas:

	sed 's/,$//' < src/Mono.Android/new-map.csv > src/Mono.Android/map.csv

This keeps the diff to a reasonable size.

TODO: update `map.csv` to current BindingStudio output after this
is merged.

Update `build-tools/manifest-attribute-codegen` so that:

 1. It can be executed from topdir.

 2. Warning message are actually emitted when using `dotnet build`.
    Previously, only the fact that the executed command failed would
    be printed, but none of the tool output, which was needed!

~~ Stable API-36.1 ~~

Normally when we declare a new API level as "stable", it is the
*only* API that is built.

For API-36.1, this is not the case: we want to continue building
API-36, *and also* build API-36.1, *and also* using the the API-36.1
build artifacts doesn't require `$(EnablePreviewFeatures)`=true.

Mirror #10005:

  * build both API levels by "repurposing" the
    `$(AndroidLatestUnstable*)` MSBuild properties as an
    "alternate set" of stable API levels.

  * What "really" indicates a `Mono.Android.dll` is unstable is the
    presence of `ANDROID_UNSTABLE` when building it.
    This is conditional on `$(IsUnstableVersion)`.

    Update `$(IsUnstableVersion)` so that it uses the
    [MSBuild version-comparison functions][0] to compare
    `$(AndroidApiLevel)` against `$(AndroidLatestStableApiLevel)`
    (previous behavior) *and also* against
    `$(AndroidLatestStableApiLevel2)` (new property).

    This allows API-36.1 to be built via the `*Unstable*` properties
    while not defining `ANDROID_UNSTABLE.`

~~ Fix assertion failure in <CheckApiCompatibility/> ~~

When attempting to declare API-36.1 as the latest stable API,
my local (Debug) build promptly started *crashing*.

Which was rather unexpected.

The most useful lesson in this context: *do not* call
`Debug.Assert()` or throw exceptions from code which is called from
the Thread Pool.  `Debug.Assert()` -- in Debug config builds -- will
immediately exit the process, which in turn means that MSBuild `binlog`
output is *incomplete*, as MSBuild never gets a chance to flush
everything (courtesy of the process aborting!).

Throwing an exception is very similar: unhandled exceptions on the
thread pool cause the process to abort.  MSBuild never has a chance
to write complete binlog data.

Plumb logging through to `CodeGenDiff` so that the assertion failure
can instead become an "Internal Error" message.  This fixes the crash.

Then there's the matter of the former assertion failure now error
message: why was `currentObject.InternalCounter` negative?

`currentObject.InternalCounter` was negative because of this line
(newlines added for readability, but it's all one line):

	public static void AddEventHandler<TInterface, TImplementor>(
	  [System.Runtime.CompilerServices.NullableAttribute((byte)2)] ref System.WeakReference? implementor,
	  System.Func<TImplementor> creator,
	  System.Action<TInterface> setListener,
	  System.Action<TImplementor> add)
	where TInterface : class
	where TImplementor : Java.Lang.Object, TInterface
	{
	}

The `where TInterface : class ` was matching this check:

        content.IndexOf (" class ", StringComparison.Ordinal)

and thus the method was being interpreted as the introduction of
a new type declaration instead of something to add to the existing
`currentObject` scope.  This meant that the new
`currentObject.InternalCounter` was 0, then we hit `}` to decrement
`.InternalCounter`, resulting in a negative value.

Fix this by checking for ` partial class `, as was done previously
with ` partial struct `, as `Microsoft.DotNet.GenAPI.dll` always
emits the `partial` modifier on everything except `enum`s.
This fixes the now internal error message former assertion.

[0]: https://learn.microsoft.com/en-us/visualstudio/msbuild/property-functions?iew=vs-2022#msbuild-version-comparison-functions

Context: dotnet/dotnet@23dafb1...e1eaf1b

- **Updates**:
  - From [10.0.0-beta.25475.111 to 10.0.0-beta.25476.104][1]
     - Microsoft.DotNet.Build.Tasks.Feed
  - From [0.11.5-alpha.25475.111 to 0.11.5-alpha.25476.104][1]
     - Microsoft.DotNet.Cecil
  - From [10.0.0-rtm.25475.111 to 10.0.0-rtm.25476.104][1]
     - Microsoft.NET.ILLink.Tasks
     - Microsoft.NETCore.App.Ref
  - From [10.0.100-rtm.25475.111 to 10.0.100-rtm.25476.104][1]
     - Microsoft.NET.Sdk
     - Microsoft.TemplateEngine.Authoring.Tasks

[1]: dotnet/dotnet@23dafb1...e1eaf1b

This pull request updates the following dependencies

## From https://github.com/dotnet/dotnet
- **Subscription**: [e03b5b1d-315d-470a-ace2-7afe9c8b5586](https://maestro.dot.net/subscriptions?search=e03b5b1d-315d-470a-ace2-7afe9c8b5586)
- **Build**: [20251012.2](https://dev.azure.com/dnceng/internal/_build/results?buildId=2814080) ([286686](https://maestro.dot.net/channel/5173/github:dotnet:dotnet/build/286686))
- **Date Produced**: October 12, 2025 11:22:00 PM UTC
- **Commit**: [0b60d265d30d96c827b73dbce74cb78f600d3c92](dotnet/dotnet@0b60d26)
- **Branch**: [release/10.0.1xx](https://github.com/dotnet/dotnet/tree/release/10.0.1xx)


- **Updates**:
  - From [10.0.0-beta.25476.104 to 10.0.0-beta.25512.102][2]
     - Microsoft.DotNet.Build.Tasks.Feed
  - From [0.11.5-alpha.25476.104 to 0.11.5-alpha.25512.102][2]
     - Microsoft.DotNet.Cecil
  - From [10.0.0-rtm.25476.104 to 10.0.0-rtm.25512.102][2]
     - Microsoft.NET.ILLink.Tasks
     - Microsoft.NETCore.App.Ref
  - From [10.0.100-rtm.25476.104 to 10.0.100-rtm.25512.102][2]
     - Microsoft.NET.Sdk
     - Microsoft.TemplateEngine.Authoring.Tasks

[2]: dotnet/dotnet@e1eaf1b...0b60d26

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

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

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

Otherwise, the linker step will fail because path can contain spaces, for example:

    C:\Program Files\dotnet\packs\Microsoft.Android.Runtime.NativeAOT.36.android-x64\36.0.0-rc.2.332\runtimes\android-x64\native\libnaot-android.debug-static-debug.a

)

Context: #10194
Context: https://discord.com/channels/732297728826277939/732297837953679412/1427681737957441577
Fixes: #6739

PR #10194 was originally meant to fix #6739, but did not when testing
a sample project. The test written in #10194 passed even without the
fixes, so we did not have a proper test case.

After reviewing the failing project, I noticed `<Aapt2Link/>` was passed:

    AndroidManifestFile = D:\Downloads\test_sdk26\AndroidManifest.xml

This is the developer's `AndroidManifest.xml` in their project, which
should completely omit `<uses-sdk/>` in favor of the
`$(SupportedOSPlatformVersion)` MSBuild property. I suspect the fix
for #10194 would have worked if `<uses-sdk/>` was present.

`<Aapt2Link/>` can run quite early, before we have generated the final
`AndroidManifest.xml` file. So, a solution here is to pass in
`$(SupportedOSPlatformVersion)` to `<Aapt2Link/>`.

I also updated the test so it properly tests this scenario.

Fixes: #10544
Context: 1a62af3
Context: cba39dc

cba39dc introduced code to preload at startup native libraries which use JNI, 
to work around an issue in Android which prevents such libraries from being 
properly loaded at the later time of application life.

Part of the workaround was support for updating handle of such a library in
our shared library cache. Since every library has different entries in the 
cache (because we search the array using xxHash generated from various forms
of the library name), after preloading it we had to update every entry in the
DSO cache with the correct handle, so that the library is never loaded again.

The code which generates the caches and indexes at application build time worked
fine in my testing (using `dotnet build`) but it turns out that using `dotnet publish`
instead breaks the code in a subtle, but nasty way. 

The issue is that the code which generated the index of shared libraries to preload
reused an array which stored the indexes, while generating code for different RIDs.
This resulted in the very first RID to process to contain valid indexes, the
second one would **append** its own indexes to the preceding RID's data, the third
RID would further append its own data etc.

This would result in the following index code generated for the subsequend RIDs:

```
; android-arm
; Indices into dso_cache[] of DSO libraries to preload because of JNI use
@dso_jni_preloads_idx = dso_local local_unnamed_addr constant [4 x i32] [
        i32 15, ; libSystem.Security.Cryptography.Native.Android.so
        i32 0, ; libSystem.Security.Cryptography.Native.Android
        i32 7, ; System.Security.Cryptography.Native.Android.so
        i32 8 ; System.Security.Cryptography.Native.Android
], align 4
```

```
; android-arm64
; Indices into dso_cache[] of DSO libraries to preload because of JNI use
@dso_jni_preloads_idx = dso_local local_unnamed_addr constant [8 x i32] [
        i32 15, ; libSystem.Security.Cryptography.Native.Android.so
        i32 0, ; libSystem.Security.Cryptography.Native.Android
        i32 7, ; System.Security.Cryptography.Native.Android.so
        i32 8, ; System.Security.Cryptography.Native.Android
        i32 10, ; Invalid index 4
        i32 0, ; Invalid index 5
        i32 1, ; Invalid index 6
        i32 14 ; Invalid index 7
], align 4
```

```
; android-x64
; Indices into dso_cache[] of DSO libraries to preload because of JNI use
@dso_jni_preloads_idx = dso_local local_unnamed_addr constant [12 x i32] [
        i32 15, ; libSystem.Security.Cryptography.Native.Android.so
        i32 0, ; libSystem.Security.Cryptography.Native.Android
        i32 7, ; System.Security.Cryptography.Native.Android.so
        i32 8, ; System.Security.Cryptography.Native.Android
        i32 10, ; Invalid index 4
        i32 0, ; Invalid index 5
        i32 1, ; Invalid index 6
        i32 14, ; Invalid index 7
        i32 10, ; Invalid index 8
        i32 0, ; Invalid index 9
        i32 1, ; Invalid index 10
        i32 14 ; Invalid index 11
], align 16
```

In effect, when running on an arm64 device, we would try to load, and cache the
handle, of an entirely different shared library, leading to further problems to
find a requested symbol:

```
10-17 11:25:18.062 27900 27900 F monodroid-assembly: Failed to load symbol 'AndroidCryptoNative_EcKeyCreateByKeyParameters' from shared library 'libSystem.Security.Cryptography.Native.Android'
10-17 11:25:18.110  1444  4298 I ActivityManager: Process com.companyname.test_jwt (pid 27900) has died: fg  TOP 
10-17 11:25:18.110  1444  1712 I libprocessgroup: Removed cgroup /sys/fs/cgroup/apps/uid_10361/pid_27900
10-17 11:25:18.111   913   913 I Zygote  : Process 27900 exited cleanly (0)
```

Native code attempted to load the symbol from a library that happened to be
stored at the index valid for `android-arm` but not for e.g. `android-arm64`,
which was not `libSystem.Security.Cryptography.Native.Android`, leading to
the above red herring error.

Note: if **all** of RIDs enabled for the application are 32-bit or **all**
of them are 64-bit, things would work even though the generated code would
be technically incorrect. This is because all of the hashes and, thus, sort
order of the `dso_cache` entries would be the same.

Fix this by making sure that the index array is not shared between different
RIDs when generating the DSO cache code.

We found the following errors with many `javac` errors:

    class MyTextObjectFont : Android.Graphics.Pdf.Component.PdfPageTextObjectFont
    {
        public MyTextObjectFont(Android.Graphics.Pdf.Component.PdfPageTextObjectFont font) : base(font)
        {
        }
    }

Such as:

    obj\Debug\net10.0-android36.1\android\src\crc643b87557a63e7c027\MainActivity_MyTextObjectFont.java(5,40): error JAVAC0000:  error: package android.graphics.pdf.component does not exist
        extends android.graphics.pdf.component.PdfPageTextObjectFont

This appears to be caused by the use of:

    "C:\Program Files (x86)\Android\android-sdk\platforms\android-36\android.jar"

When the build *should* be using:

    "C:\Program Files (x86)\Android\android-sdk\platforms\android-36.1\android.jar"

Update various MSBuild logic to handle non-integer API levels.

**API Level Property Standardization**

* Replaced `AndroidSdkPlatform` with `AndroidApiLevel` in all relevant
  MSBuild targets and task classes, including `Aapt2Link`,
  `GenerateMainAndroidManifest`, `GetJavaPlatformJar`, and others.

**Parsing and Usage Improvements**

* Updated logic to parse `AndroidApiLevel` using
  `MonoAndroidHelper.TryParseApiLevel` where necessary, supporting
  both major and minor versions and defaulting to sensible values when
  parsing fails.

**Code Cleanup and Refactoring**

* Removed unused or obsolete parameters and code paths related to
  `AndroidSdkPlatform` in several classes and methods, such as
  `GenerateJavaStubs` and `JCWGenerator`.
* Updated test cases for `CheckGoogleSdkRequirements` to use
  `AndroidApiLevel` instead of `TargetFrameworkVersion`, and corrected
  assertions for warnings and errors.

**MSBuild Targets Updates**

* Modified MSBuild target files to use the new `AndroidApiLevel`
  property, ensuring that all build steps and tooling reference the
  correct property name.

Changes: dotnet/dotnet@0b60d26...50d7970

- **Updates**:
  - From [10.0.0-beta.25512.102 to 10.0.0-beta.25520.117][2]
     - Microsoft.DotNet.Build.Tasks.Feed
  - From [0.11.5-alpha.25512.102 to 0.11.5-alpha.25520.117][2]
     - Microsoft.DotNet.Cecil
  - From [10.0.0-rtm.25512.102 to 10.0.0][2]
     - Microsoft.NET.ILLink.Tasks
     - Microsoft.NETCore.App.Ref
  - From [10.0.100-rtm.25512.102 to 10.0.100-rtm.25520.117][2]
     - Microsoft.NET.Sdk
  - From [10.0.100-rtm.25512.102 to 10.0.100][2]
     - Microsoft.TemplateEngine.Authoring.Tasks

[2]: dotnet/dotnet@0b60d26...50d7970

Other changes:

* Track runtime workload manifests at dotnet/dotnet

* Feeds for dotnet/runtime 9.0.11

* Track `Microsoft.NET.ILLink` instead of `Microsoft.NET.ILLink.Tasks`

Co-authored-by: Jonathan Peppers <[email protected]>

Changes: dotnet/dotnet@50d7970...7b29526

Changes: https://devdiv.visualstudio.com/DevDiv/_git/android-platform-support/branchCompare?baseVersion=GCbdce1c1dc27c5a58da5cd12ae2f4113d76ddc2da&targetVersion=GC2ca8c22cc27b2f437275ee01e054c92847728617

* Merged PR 681428: [Xamarin.ManifestGenerator] add `platform;android-36.1`

* Merged PR 681033: Bump to dotnet/android-tools@c8b05f6

* Merged PR 679787: Align Android NDK versions

* Merged PR 679733: [installer] fix host-arch detection

* Merged PR 674631: Bump version to 18.1

Given that API 36.1 is "api stable", and we have a `$(TargetFramework)` available.

We normally would also bump the product version to 36.1.x to signify this.

`main` will remain `36.1.99-preview.1.x` for now, however it may need to change to 999.

Fixes: #10528
Fixes: #10563

There is a report in .NET 10 of *something* going wrong with
incremental builds (and possibly design-time builds)...

The app crashes with an error such as:

    android.content.res.Resources$NotFoundException: String resource ID #0x7f1000be at
    android.content.res.Resources.getText(Resources.java:466) at android.content.Context.getText(Context.java:933) at
    androidx.appcompat.widget.Toolbar.setNavigationContentDescription(Toolbar.java:1001) at
    crc64e02730b4d0e10e64.CustomShellRenderer_SectionRenderer.n_onCreateView(Native Method) at
    crc64e02730b4d0e10e64.CustomShellRenderer_SectionRenderer.onCreateView(CustomShellRenderer_SectionRenderer.java:36) ...

Where the resource ID is invalid.

After some debugging, after watching the video:

* #10528 (comment)

I was able to reproduce the issue, when I did:

1. Open emulator
2. Open project in VS
3. Ctrl+F5 (see app running)
4. Close VS (make sure emulator stays open)
5. Reopen VS
6. Ctrl+F5 again
7. App crashes

Reviewing builds logs, I saw this oddity on the design-time build on
step 5:

    Target _GenerateRtxt
    Building target "_GenerateRtxt" completely.
    Input file "Bug.Dependency.csproj" does not exist.

That is a referenced project file, it definitely should exist!

However, I noticed the path is wrong:

    Target _CollectProjectReferenceResources
        Task MSBuild
            OutputItems
                LibraryResourceDirectories
                    D:\src\dotnet-android-bug-10528\src\Bug.Dependency\Resources
                        StampFile = Bug.Dependency.csproj

`%(StampFile)` is a relative path, which can be fixed via:

    StampFile="$(MSBuildProjectFile)"
    StampFile="$(MSBuildProjectFullPath)"

This problem was introduced in .NET 10 via:

* 9ed1469

The target also uses `$(MSBuildProjectDirectory)`, which is a full path,
so it is ok. See:

* https://learn.microsoft.com/visualstudio/msbuild/msbuild-reserved-and-well-known-properties

I was also able to reproduce this issue by adding a class library to
the existing `BuildInDesignTimeMode()` test.