Changes: dotnet/runtime@689f4e9...d9d0ae0
Changes: dotnet/emsdk@dad5528...78be8cd
Changes: dotnet/cecil@aa3ae0d...8debcd2

Updates:

* Microsoft.NET.ILLink: from 9.0.3-servicing.25111.4 to 9.0.4-servicing.25163.4
* Microsoft.NET.ILLink.Tasks: from 9.0.3 to 9.0.4
* Microsoft.NETCore.App.Ref: from 9.0.3 to 9.0.4
* Microsoft.NET.Workload.Emscripten.Current.Manifest-9.0.100: from 9.0.3 to 9.0.4
* Microsoft.DotNet.Cecil: from 0.11.5-alpha.25102.5 to 0.11.5-alpha.25112.2

Other changes:

* Feeds for dotnet/runtime 8.0.15

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

Changes: dotnet/sdk@346d06b...8d515d2

Updates: Microsoft.NET.Sdk: from 9.0.104-servicing.25111.36 to 9.0.105-servicing.25164.42

This test has started failing as soon as a `platform-tools` 36.0.0
appeared on Google's feed:

    _AndroidSdkDirectory was not set to new SDK path C:\a\_work\1\a\TestRelease\03-28_03.15.36\temp\InstallAndroidDependenciesTestGoogleV2\android-sdk. Please check the task output in 'install-deps.log'
    Expected: True
    But was:  False

I'm guessing this is because it is still "preview":

    <remotePackage path="platform-tools">
      <type-details xsi:type="generic:genericDetailsType"/>
      <revision>
        <major>36</major>
        <minor>0</minor>
        <micro>0</micro>
      </revision>
      <display-name>Android SDK Platform-Tools</display-name>
      <uses-license ref="android-sdk-preview-license"/>

As the `.binlog` shows:

    Component Android SDK Platform-Tools r36.0.0 not present on the system
    Component Android SDK Platform-Tools r35.0.2 not present on the system

And then the next build refuses to use the SDK, due to `adb.exe` missing?

    ValidateAndroidSdkLocation: for locator=constructor param, path=`C:\a\_work\1\a\TestRelease\03-28_03.15.36\temp\InstallAndroidDependenciesTestGoogleV2\android-sdk`, result=False
    ValidateAndroidSdkLocation: for locator=preferred path, path=``, result=False
    Looking for Android SDK...
    ValidateAndroidSdkLocation: for locator=all paths, path=`C:\Android\android-sdk`, found adb `C:\Android\android-sdk\platform-tools\adb.EXE`
    ...
    ResolveSdks Outputs:
      AndroidSdkPath: C:\Android\android-sdk

If I change the `GetCurrentPlatformToolsVersion()` method to ignore
entries with:

    <uses-license ref="android-sdk-preview-license"/>

Then the test passes for me locally.

It seems reasonable to ignore "preview" versions of `platform-tools`
for this test.

…02.7

Changes: dotnet/runtime@d9d0ae0...5da49f4
Changes: dotnet/emsdk@78be8cd...b8d8fec

Updates:
Microsoft.NET.ILLink , Microsoft.NET.ILLink.Tasks , Microsoft.NETCore.App.Ref
 From Version 9.0.4-servicing.25163.4 -> To Version 9.0.4-servicing.25202.7

Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>

Context: d5152b6 [API-36 on main]

Note that our repository does not currently have build system support
for having multiple ***stable*** API platform versions in a single
.NET version.  To work around this, this commit treats API-36 as an
"unstable" API level for the context of our build system.  However,
it removes the need for users to use `$(EnablePreviewFeatures)` and
thus is a stable platform version to our users.

If we actually updated `$(AndroidLatestStableApiLevel)` to `36` it
would have (at least) the following issues:

  - We would no longer build or ship API-35 for .NET 9

  - `net9.0-android` would switch from `net9.0-android35.0` to
    `net9.0-android36.0` which we do not want.
    
    Once shipped, `net9.0-android` should not change meaning.

Proper multi-stable support would require expanding
`$(AndroidLatestStableApiLevel)` to something akin to
`$(AndroidMinimumStableApiLevel)`/`$(AndroidMaximumStableApiLevel)` or
`@(AndroidStableApiLevels)`.  We have chosen not to invest in this work
at this time.

Original API-36 support commit message follows:

Context: https://developer.android.com/about/versions/16
Context: https://android-developers.googleblog.com/2025/03/the-third-beta-of-android-16.html

Android 16 Beta 3 has been released.

  * [API-36 Beta 3 vs. API-35][0]
  * [API-36 Beta 3 vs. API-Baklava Beta 2][1]

The Android 16 Preview Program Overview [Timeline and updates][2]
section suggests the following timeline:

  * Nov/Dec: Developer Previews
  * Jan/Feb: Unstable Betas
  * Mar/Apr: Stable Betas
  * ???: Final

Additionally, enumify and mark API-36 as "stable", which changes
`net10.0-android` to default to `net10.0-android36.0`.

We still need to decide on our strategy for backporting this to
.NET 9 service releases.

## Notes

APICompat:

  - There are several `Android.Runtime.RequiresPermissionAttribute`
    fields that have been removed.  As we do not consume this
    attribute, it does not cause any API breakage.

  - Several `[ObsoletedOSPlatformAttribute]` attributes are missing.
    These have all been documented as "undeprecated" in Android's
    change list: https://developer.android.com/sdk/api_diff/36/changes

PublicAPI:

  - Nullable reference type attribute changes (`T?` -> `T!`)

  - Method parameter name changes.  This is technically a source
    breaking change, but something we've never tracked or fixed before.

  - Some consts changed "values" in `PublicAPI*.txt` like from
    `MediaCodecProfileType.Av1profilemain10hdr10` to
    `MediaCodecProfileType.Apvprofile42210hdr10`:

        - const Android.Media.MediaCodecInfo.CodecProfileLevel.AV1ProfileMain10HDR10 = Android.Media.MediaCodecProfileType.Av1profilemain10hdr10 -> Android.Media.MediaCodecProfileType
        + const Android.Media.MediaCodecInfo.CodecProfileLevel.AV1ProfileMain10HDR10 = Android.Media.MediaCodecProfileType.Apvprofile42210hdr10 -> Android.Media.MediaCodecProfileType

    This is a weird enum that has lots of members with the same values,
    and the PublicAPI tooling likely chooses the first alphabetically.
    The const *value* did not actually change, just the way it is
    listed in `PublicAPI*.txt`:

        public enum Android.Media.MediaCodecProfileType {
          [global::System.Runtime.Versioning.SupportedOSPlatformAttribute ("android36.0")]
          Apvprofile42210hdr10 = 4096,
        
          [global::System.Runtime.Versioning.SupportedOSPlatformAttribute ("android29.0")]
          Av1profilemain10hdr10 = 4096,
          // …
        }

MAUI Integration Tests:

  - It looks like the MAUI Integration tests are broken because they
    [explicitly target net10.0-android35.0][3] instead of
    `net10.0-android`.

    The MAUI team will need to update this when our changes
    flow to them.

[0]: https://developer.android.com/sdk/api_diff/36/changes
[1]: https://developer.android.com/sdk/api_diff/36-incr/changes
[2]: https://developer.android.com/about/versions/16/overview
[3]: https://github.com/dotnet/maui/blob/c451130571777aef5d9fa2737789dd987430e6dc/Directory.Build.props#L158

…10031)

Updates xaprepare and Mono.Android to generate API docs against
API-36 sources.

Changes: dotnet/runtime@5da49f4...207cda3
Changes: dotnet/emsdk@b8d8fec...3cddc1f

Updates:

* Microsoft.NET.ILLink: from 9.0.4-servicing.25202.7 to 9.0.5-servicing.25211.5
* Microsoft.NET.ILLink.Tasks: from 9.0.4 to 9.0.5
* Microsoft.NETCore.App.Ref: from 9.0.4 to 9.0.5
* Microsoft.NET.Workload.Emscripten.Current.Manifest-9.0.100: from 9.0.4 to 9.0.5

Other changes:

* [darc] track `Microsoft.NET.Workload.Mono.ToolChain.Current.Manifest-8.0.100`

After manually updating `Versions.Details.xml`, we can setup `darc` to manage the
missing feed for dotnet/runtime 8.0.16:

    darc update-dependencies --id 264054 --name Microsoft.NET.Workload.Mono.ToolChain.Current.Manifest-8.0.100
    Looking up build with BAR id 264054
    Updating 'Microsoft.NET.Workload.Mono.ToolChain.Current.Manifest-8.0.100': '8.0.16' => '8.0.16' (from build '20250411.10' of 'https://github.com/dotnet/runtime')
    Checking for coherency updates...
    Local dependencies updated based on build with BAR id 264054 (20250411.10 from https://github.com/dotnet/runtime@release/8.0)

Going forward, we can do this for newer .NET 8 runtimes.

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

…ing API Docs (#10052)

Commit 3a3beeb allows Mono.Android to be built for both API 35 and 36,
while still marking API 36 as "unstable". The API docs update targets
should explicitly pass the API level we want to build for to account for
this and to allow us to generate docs for API level 36.

The docs build also doesn't need to run the ApiCompat targets.

Context: #9914
Context: d5152b6
Context: #10045

In #9914 / d5152b6, we completed enumification of Android API-36 and
marked it as stable.

A bug in this is that we were not consistent with our capitalization
of the `Android.Ranging.Ble.CS` namespace:

Methods were placed in the `Android.Ranging.Ble.CS` namespace but
enums were placed in the `Android.Ranging.Ble.Cs` namespace.

Fix the following enums to have the correct "CS" namespace:

  * Android.Ranging.Ble.CS.BleCsRangingCapabilitiesCsSecurityLevel
  * Android.Ranging.Ble.CS.BleCsRangingParamsLocationType
  * Android.Ranging.Ble.CS.BleCsRangingParamsSightType

Brings in API docs for API Level 36.

Changes: dotnet/android-api-docs@492e524...d382c5b

….8 (#10068)

Fixes: #9925

Partial backport of: #10050

For backporting to .NET 9, we just need to suppress a warning that JDK
21 will show when using `javac -source 1.8 -target 1.8`.

Changes: dotnet/sdk@8d515d2...a348b98

Updates:

* Microsoft.NET.Sdk: from 9.0.105-servicing.25164.42 to 9.0.300-rtm.25252.5

* 9.0.100 harcoded version band

Solves the error:

    error NU1101: Unable to find package Microsoft.NET.Workload.Mono.ToolChain.Current.Manifest-9.0.200. No packages exist with this id in source(s):...

We also don't want to change *our* version band to 9.0.200, so we
hardcode the version band to 9.0.100.

* dotnet/runtime 8.0.16 NuGet feeds

* Update IncrementalBuildTest.cs

The warning message changed:

    dotnet/sdk/9.0.300/Microsoft.Common.CurrentVersion.targets(2190,5): warning MSB9008: The referenced project ../MyLibrary/MyLibrary.csproj does not exist.

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

…rsion band (#10112)

In fc72bb4, we migrated to a 9.0.300 .NET SDK, which unfortunately
resulted in an Android workload manifest with a 9.0.300 version band:

    Microsoft.NET.Sdk.Android.Manifest-9.0.300.35.0.73.nupkg

To stay on 9.0.100, we need should use `$(DotNetAndroidManifestVersionBand)`
for the manifest version band instead of `$(DotNetSdkManifestsFolder)`.

I also had to make a similar change in `DotNet.targets`.

Context: dotnet/macios#22685
Context: dotnet/macios#19370

To simplify inclusion of the Mono diagnostics component, the
iOS/macOS/etc. workloads are introducing a new `$(EnableProfiler)`
MSBuild property.

To align with Android, we can add an `$(EnableProfiler)` MSBuild
property which works the same way as the existing
`$(AndroidEnableProfiler)` MSBuild property.

I documented `$(AndroidEnableProfiler)` (which was missing!), and
also added an entry about the new, `$(EnableProfiler)` property.

Context: dotnet/macios#22982
Context: dotnet/runtime#115473 (comment)

We are aligning WASM, iOS, Android to all use the same property name for this.

….1xx@0ec8d44d (#10175)

Changes: https://devdiv.visualstudio.com/DevDiv/_git/android-platform-support/branchCompare?baseVersion=GC41f8660f009f6efe6c440100ecf13ce1e276177b&targetVersion=GC0ec8d44d5d90dd2b8ab69cc9791e22da4ff16a52
Fixes: #10167

FastDev binary utilities are rebuilt with 16k page alignment
for arm64, which causes them not to segfault on devices or
emulators which enabled 16k page support.

At the same time, the 16k-aligned binaries work fine on 4k-page
devices/emulators. Tested both on Android 16.

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

Updates the repo reference that provides common yaml templates from

  * https://github.com/xamarin/yaml-templates

to

  * https://devdiv.visualstudio.com/DevDiv/_git/Xamarin.yaml-templates