Changes:dotnet/runtime@689f4e9...d9d0ae0Changes:dotnet/emsdk@dad5528...78be8cdChanges:dotnet/cecil@aa3ae0d...8debcd2Updates:* 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.2Other changes:* Feeds for dotnet/runtime 8.0.15Co-authored-by: Jonathan Peppers <jonathan.peppers@microsoft.com>

Changes:dotnet/sdk@346d06b...8d515d2Updates: 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.0appeared 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:  FalseI'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 systemAnd 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-sdkIf I change the `GetCurrentPlatformToolsVersion()` method to ignoreentries 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.7Changes:dotnet/runtime@d9d0ae0...5da49f4Changes:dotnet/emsdk@78be8cd...b8d8fecUpdates: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.7Co-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 supportfor 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)` andthus is a stable platform version to our users.If we actually updated `$(AndroidLatestStableApiLevel)` to `36` itwould 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 workat this time.Original API-36 support commit message follows:Context:https://developer.android.com/about/versions/16Context:https://android-developers.googleblog.com/2025/03/the-third-beta-of-android-16.htmlAndroid 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  * ???: FinalAdditionally, 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.## NotesAPICompat:  - 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/changesPublicAPI:  - 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 againstAPI-36 sources.

Changes:dotnet/runtime@5da49f4...207cda3Changes:dotnet/emsdk@b8d8fec...3cddc1fUpdates:* 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.5Other 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 themissing 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 fromhttps://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)Commit3a3beeb allows Mono.Android to be built for both API 35 and 36,while still marking API 36 as "unstable". The API docs update targetsshould explicitly pass the API level we want to build for to account forthis and to allow us to generate docs for API level 36.The docs build also doesn't need to run the ApiCompat targets.

Context:#9914Context:d5152b6Context:#10045In#9914 /d5152b6, we completed enumification of Android API-36 andmarked it as stable.A bug in this is that we were not consistent with our capitalizationof the `Android.Ranging.Ble.CS` namespace:Methods were placed in the `Android.Ranging.Ble.CS` namespace butenums 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:#9925Partial backport of:#10050For backporting to .NET 9, we just need to suppress a warning that JDK21 will show when using `javac -source 1.8 -target 1.8`.

Changes:dotnet/sdk@8d515d2...a348b98Updates:* Microsoft.NET.Sdk: from 9.0.105-servicing.25164.42 to 9.0.300-rtm.25252.5* 9.0.100 harcoded version bandSolves 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 wehardcode the version band to 9.0.100.* dotnet/runtime 8.0.16 NuGet feeds* Update IncrementalBuildTest.csThe 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)Infc72bb4, we migrated to a 9.0.300 .NET SDK, which unfortunatelyresulted in an Android workload manifest with a 9.0.300 version band:    Microsoft.NET.Sdk.Android.Manifest-9.0.300.35.0.73.nupkgTo 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#22685Context:dotnet/macios#19370To simplify inclusion of the Mono diagnostics component, theiOS/macOS/etc. workloads are introducing a new `$(EnableProfiler)`MSBuild property.To align with Android, we can add an `$(EnableProfiler)` MSBuildproperty which works the same way as the existing`$(AndroidEnableProfiler)` MSBuild property.I documented `$(AndroidEnableProfiler)` (which was missing!), andalso added an entry about the new, `$(EnableProfiler)` property.

Context:dotnet/macios#22982Context: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=GC0ec8d44d5d90dd2b8ab69cc9791e22da4ff16a52Fixes:#10167FastDev binary utilities are rebuilt with 16k page alignmentfor arm64, which causes them not to segfault on devices oremulators which enabled 16k page support.At the same time, the 16k-aligned binaries work fine on 4k-pagedevices/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-templatesto  *https://devdiv.visualstudio.com/DevDiv/_git/Xamarin.yaml-templates