Add API-31 to d16-11 #6234
Merged
Add API-31 to d16-11 #6234
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Since 5da92bd, we are seeing the on device tests fail with the following error. error JAVAC0000: java.lang.AssertionError: annotationType() : unrecognized Attribute name MODULE (class com.sun.tools.javac.util.SharedNameTable$NameImpl) This suggests that API 31 requires JDK 11 in order to compile. So lets bump the version which we use for the on device tests for now, until we can figure out what do actually do.
We've been having an issue with Android Designer test dependency
provisioning on macOS:
Xamarin.Provisioning.ProvisioningException: Failed to provision /Applications/Xcode_12.5.0.app
---> Xamarin.Provisioning.ProvisioningException: This Xcode version requires macOS ≥ 11.0 (currently running on 10.15.7)
We should be able to remedy this by moving to the same macOS Big Sur
pool that the Designer build is using.
The Windows tests have also been failing for a while, and this problem
is [not unique to our pipeline][0]. We should disable these tests for
now until the issue is addressed.
[0]: https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=4894821&view=logs&jobId=2f037848-d60e-57a4-8d19-387778a8302c&j=2f037848-d60e-57a4-8d19-387778a8302c&t=fbc84e65-28e6-5146-ccec-20ffda77f75c
Fixes: dotnet/maui#1475 A .NET 6 application project was failing to include C# bindings for `.aar` files, but `.jar` files were working. The workaround was to include: <LibraryProjectZip Include="myjavalibrary.aar" /> We had a test that checked this behavior for `.jar` files, but not `.aar` files. After reproducing the behavior in a test, I found the `_CategorizeAndroidLibraries` MSBuild target did not automatically setup the `@(LibraryProjectZip)` item group in .NET 6 application projects. `@(AndroidAarLibrary)` *was* being setup, which explained why the Java code made it to `classes.dex`, but C# bindings were missing. Updated the `_CategorizeAndroidLibraries` MSBuild target for this case.
Context: https://blog.gradle.org/jcenter-shutdown Context: https://jfrog.com/blog/into-the-sunset-bintray-jcenter-gocenter-and-chartcenter/ Various urls in tests have stopped working such as: System.Net.WebException : The remote server returned an error: (403) Forbidden. Update to new urls that solve this issue.
Context: https://www.1eswiki.com/wiki/1ES_hosted_AzureDevOps_Agents We've been tasked with migrating away from our scale set agent pools to a new 1ES service. There are a couple of benefits to using 1ES agent pools: we should now be able to use customizable versions of the [Microsoft-hosted agent images][0] which come preloaded with some of our dependencies. These images are also updated regularly which should hopefully reduce maintenance costs. Overall, the process for creating, updating, and rolling out image changes to our scale set agent pools should now be dramatically simplified over [the existing workflow][1]. Visual Studio update steps have been removed as these images should stay up to date with the latest stable VS, similar to the Microsoft-hosted images. [0]: https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/hosted?view=azure-devops&tabs=yaml [1]: https://github.com/xamarin/monodroid/wiki/Azure-Pipelines-and-DevOps#windows-scale-set-agent-pool-management
Context: dotnet#6089 We currently have lots of test failures due to the warning: warning XA1008: The TargetFrameworkVersion (Android API level 30) is lower than the targetSdkVersion (31). Please increase the `$(TargetFrameworkVersion)` or decrease the `android:targetSdkVersion` in the `AndroidManifest.xml` so that the API levels match. Looking at `Properties\AndroidManifest.xml`, Xamarin.ProjectTools generated: <uses-sdk android:minSdkVersion="19" android:targetSdkVersion="31" /> This appears to be due to the `GetMaxInstalledPlatform()` method: https://github.com/xamarin/xamarin-android/blob/1b71da0cd3a44861b006ac41c77a24eedf066281/src/Xamarin.Android.Build.Tasks/Tests/Xamarin.ProjectTools/Android/AndroidSdkResolver.cs#L121-L138 I think what happened is: * dotnet#6089 is opened, platform-31 gets installed on many of the CI machines. * Future PRs install `platform-S` side-by-side `platform-31`. And so we ended up with test failures... To fix this for now, manually delete the `sdk/platform-31` folder on test jobs.
…net#6114) Context: dotnet#6112 (review) The .NET Preview 7 bump is failing with: Running: /Users/builder/Library/Android/dotnet/dotnet "workload" "install" "microsoft-net-runtime-android" "--skip-manifest-update" "--verbosity" "diag" stderr | Workload with id microsoft-net-runtime-android is not recognized. However, it was a bug in the `dotnet workload install` command that allowed us to even install this workload in the first place! The concept concept behind "abstract" workloads is they are not user visible in any way; they're meant to be an implementation detail. In commit 0150bbb, I setup `xaprepare` to install the `microsoft-net-runtime-android` workload, but we don't actually even need to do this. We can simply update the `sdk-manifest` for this pack, so that the version matches `$(DotNetRuntimePacksVersion)`. The `microsoft-net-runtime-android` workload will get installed later during the `ExtractWorkloadPacks` target, as part of installing the `android` or `android-aot` workloads: https://github.com/xamarin/xamarin-android/blob/c1a2ee70214e86757541b5759c9ed54941bd4680/build-tools/create-packs/Directory.Build.targets#L119-L122 Since `android` and `android-aot` extend `microsoft-net-runtime-android`, this step will install it.
) Context: dotnet#6112 The .NET 6 Preview 7 bump had a test failure: CleanBasicBindingLibrary("class-parse") obj/Release should have no directories. Expected: <empty> But was: < "/Users/runner/work/1/s/bin/TestRelease/temp/CleanBasicBindingLibraryclass-parse/obj/Release/refint" > `refint` is a new directory, see: * dotnet/sdk@e424c0e * https://github.com/dotnet/msbuild/blob/9e576281e638d60701ca34411e2483bed01e35c7/src/Tasks/Microsoft.Common.CurrentVersion.targets#L397 Clean doesn't actually delete directories, no need to test for this. The test already is checking if any files exist, and that should be sufficient.
API-31 builds fail when using JDK 1.8 and using AndroidX with:
/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Android/Xamarin.Android.Common.targets(1728,3):
error JAVAC0000: java.lang.AssertionError: annotationType() : unrecognized Attribute name MODULE (class com.sun.tools.javac.util.SharedNameTable$NameImpl)
There are two plausible solutions to better handle this:
1. Only require JDK 11 when API-31 and AndroidX are being used, or
2. Always required JDK 11 for API-31+
As we believe *most* apps will be using AndroidX, there is little
point to attempting so support (1); (2) it is!
We must require JDK 11 for API-31+.
There are two code paths here: one for "legacy" Xamarin.Android, and
one for .NET 6.
Legacy is straightforward, as we already had a pattern for this, we
just update the `<ValidateJavaVersion/>` task.
For .NET 6, I checked the `$(TargetPlatformVersion)` property for now
and require JDK 11 in that case. When API-31 is stable, we can
probably remove this code and just set this value by default:
<MinimumSupportedJavaVersion Condition=" '$(MinimumSupportedJavaVersion)' == '' ">11.0</MinimumSupportedJavaVersion>
For our unit tests -- most of which would be solution (1) (API-31
and *no* AndroidX use), but many of which started to fail because we
went with solution (2) -- we did one of two things:
1. Use a different `$(TargetFrameworkVersion)` and/or remove
`$(TargetFrameworkVersion)` entirely, or
2. Use a new `BuildTest.AssertTargetFrameworkVersionSupported()`
method which `Assert.Ignore()`s the test if it would not
pass otherwise.
Some of our `PerformanceTest`'s are currently ignored due to:
Ignored : Xamarin.Android.Build.Tests.PerformanceTest.Build_No_Changes
Test requires an updated MSBuild.StructuredLogger
We ignored these tests in 304e698. This was failing due to changes in
the `.binlog` file format.
I think we can remove this with the latest MSBuild.StructuredLogger.
…t#6089) Context: https://developer.android.com/about/versions/12/overview Context: https://android-developers.googleblog.com/search/label/Android12 Android 12 [Beta 3 has been released][0]. * [API diff vs. Beta 2][1] * [API diff vs. API-30][2] Given that these API's are believed to be final (-ish?), we have performed enumification on this version. We will mark this API level as stable in a future commit, as that generally requires changing quite a few files. There are some methods that are documented as taking constants which we think would ideally be enumified, but the constants are not public. ?,31,android/net/ipsec/ike,TunnelModeChildSessionParams$Builder,addInternalAddressRequest,addressFamily, ?,31,android/net/ipsec/ike,TunnelModeChildSessionParams$Builder,addInternalDhcpServerRequest,addressFamily, ?,31,android/net/ipsec/ike,TunnelModeChildSessionParams$Builder,addInternalDnsServerRequest,addressFamily, `TunnelModeChildSessionParams.Builder.addInternal*Request()` methods like [`TunnelModeChildSessionParams.Builder.addInternalAddressRequest(int)`][3] are documented as taking `AF_INET` or `AF_INET6` values. Perusing the [`TunnelModeChildSessionParams.java`][4] source, we see that `AF_INET` is an [`import static android.system.OsConstants.AF_INET`][5], which is *not* a constant value. As such, it *cannot* be enumified, and thus none of these methods can be enumified. ?,31,android/telephony,[Interface]TelephonyCallback$CallDisconnectCauseListener,onCallDisconnectCauseChanged,preciseDisconnectCause, The `preciseDisconnectCause` parameter of [`TelephonyCallback.CallDisconnectCauseListener.onCallDisconnectCauseChanged()][6] is documented as being a value from `android.telephony.PreciseDisconnectCause`. However, [`PreciseDisconnectCause` is `@hide`][7]; it can't be bound. ?,31,android/telephony,[Interface]TelephonyCallback$DataActivationStateListener,onDataActivationStateChanged,state, Similar to the `PreciseDisconnectCause` scenario, the `state` parameter in [`TelephonyCallback.DataActivationStateListener.onDataActivationStateChanged()`][8] is documented as being a [`android.telephony.TelephonyManager.SIM_ACTIVATION_STATE_*`][9] value, which is `@hide`, and thus cannot be bound. [0]: https://android-developers.googleblog.com/2021/07/android-12-beta-3.html [1]: https://developer.android.com/sdk/api_diff/31-incr/changes [2]: https://developer.android.com/sdk/api_diff/31/changes [3]: https://developer.android.com/reference/android/net/ipsec/ike/TunnelModeChildSessionParams.Builder#addInternalAddressRequest(int) [4]: https://android.googlesource.com/platform/frameworks/opt/net/ike/+/9dbc4348a97db2076e6841669525d733bbacc287/src/java/android/net/ipsec/ike/TunnelModeChildSessionParams.java#19 [5]: https://developer.android.com/reference/android/system/OsConstants#AF_INET [6]: https://developer.android.com/reference/android/telephony/TelephonyCallback.CallDisconnectCauseListener#onCallDisconnectCauseChanged(int,%20int) [7]: https://android.googlesource.com/platform/frameworks/base/+/300c70d67617d01b3b0383742d275ab945a9ed80/telephony/java/android/telephony/PreciseDisconnectCause.java#23 [8]: https://developer.android.com/reference/android/telephony/TelephonyCallback.DataActivationStateListener?hl=en#onDataActivationStateChanged(int) [9]: https://android.googlesource.com/platform/frameworks/base/+/0c13fd19ecbb60c328a95e3c1620e03c7c8826cd/telephony/java/android/telephony/TelephonyManager.java#4921
Context: 8843808 We enumified API-31 constants in commit 8843808. However, some of the namespaces used for these enums did not reflect the changes we apply with `metadata` for capitalization or plurality purposes. A later "verify any new namespaces added" check on @jpobst 's machine revealed these changes. (TODO: Export that tool off his machine.) For example, the following namespaces were renamed: * `Android.App.Appsearch` to `Android.App.AppSearch`. * `Android.Location` to `Android.Locations`.
Fixes: dotnet#5801 Web sockets appear to be working in .NET 6 Preview 5 and higher. I think we can simply enable these tests now.
The `echo.websocket.org` server used by the tests appears to no longer be available. Disable the tests for now until we figure out what service we can use to replace `echo.websocket.org`
…otnet#6212) Fixes: dotnet#6196 Context: https://aster.cloud/2021/02/23/lets-be-explicit-about-our-intent-filters/ > An important change is coming to Android 12 that improves both app > and platform security. This change affects all apps that target > Android 12. > > Activities, services, and broadcast receivers with declared > intent-filters now must explicitly declare whether they should be > exported or not. For example: <activity android:icon="@mipmap/icon" android:label="HelloWorld" android:name="example.MainActivity"> <intent-filter> <action android:name="android.intent.action.MAIN" /> <category android:name="android.intent.category.LAUNCHER" /> </intent-filter> </activity> Should become: <activity android:exported="true" android:icon="@mipmap/icon" android:label="HelloWorld" android:name="example.MainActivity"> <intent-filter> <action android:name="android.intent.action.MAIN" /> <category android:name="android.intent.category.LAUNCHER" /> </intent-filter> </activity> Update our `AndroidManifest.xml` generation & related code so that when `MainLauncher=true`, we also automatically set `exported=true`. I updated a test to verify the contents of the generated `AndroidManifest.xml`.
…otnet#6111) Context: dotnet#6107 (comment) In .NET 6, we are wanting `AndroidManifest.xml` in project templates to no longer contain: <uses-sdk android:minSdkVersion="21" android:targetSdkVersion="30" /> This is because we can define these values such as: <TargetFramework>net6.0-android30</TargetFramework> <SupportedPlatformOSVersion>21.0</SupportedPlatformOSVersion> There is not really a reason to put this information in two places. `$(SupportedPlatformOSVersion)` is also required for enabling C# compiler warnings such as: MainActivity.cs(28,4): warning CA1416: This call site is reachable on: 'Android' 21.0 and later. 'View.AccessibilityTraversalAfter.get' is only supported on: 'android' 22.0 and later. This is an example of calling an API from 22, with a `$(SupportedPlatformOSVersion)` for 21. If `<uses-sdk/>` is still *used* in `AndroidManifest.xml` in a project, it will be preferred as the final source of truth. One other improvement is that `$(SupportedPlatformOSVersion)` is expected to include `.0`, or you get the warning: UnnamedProject.AssemblyInfo.cs(21,12): warning CA1418: Version '21' is not valid for platform 'Android'. Use a version with 2-4 parts for this platform. Android unique in that this value is always an integer. In order for users to be able to specify `21`, I added a check in `Microsoft.Android.Sdk.DefaultProperties.targets` so that we append `.0` when needed. I added some tests around this scenario.
Context: https://developer.android.com/about/versions/12 API-31 has been enumified (8843808, cf2a39b, cf2a39b). Time to declare it stable! Set API-S as API-31, `$(TargetFrameworkVersion)`=v12.0, `$(AndroidPackVersion)`=31.0.100, and declare as stable. Update unit test files so `$(TargetFrameworkVersion)`= v12.0 (API-31) *or* `$(TargetFrameworkVersion)` isn't needed, a'la 8140991. Rename `src/Mono.Android/Profiles/api-S.params.txt` to `api-31.params.txt`, to match the stable API-level ID. Updated `tests/api-compatibility/acceptable-breakages-vReference.txt` because the default API compare will now be against `API-31`, not `API-30`, and we deliberately removed the `[Category]` custom attribute (e5a4bee), remove `[DataContractAttribute]` (101fea2), and fix the value of `Android.OS.BuildVersionCodes.R` (1b1ec09). Support `$(AndroidUseLatestPlatformSdk)` in binding projects: once API-31 is stable, binding projects with `$(TargetFrameworkVersion)`=v11.0 and `$(AndroidUseLatestPlatformSdk)`=true fail to build with: Task ResolveNuGetPackageAssets ... Microsoft.NuGet.targets(198,5): Your project does not reference "MonoAndroid,Version=v12.0" framework. Add a reference to "MonoAndroid,Version=v12.0" in the "TargetFrameworks" property of your project file and then re-run NuGet restore. What happened is that `$(TargetFrameworkVersion)` was changed to 12.0 during `Build`, but not during `Restore`. Thus NuGet restored with `MonoAndroid,Version=v11.0` instead of `MonoAndroid,Version=v12.0`. I found that we have this setup for other project types, but not binding projects: <!-- NOTE: This target runs during Restore, and there is no $(RestoreDependsOn) property. There appears to be no other way to do this other than use BeforeTargets. --> <Target Name="_SetLatestTargetFrameworkVersionForPackageReference" Condition=" '$(AndroidUseLatestPlatformSdk)' == 'True' " BeforeTargets="_GetRestoreTargetFrameworksOutput" DependsOnTargets="_SetLatestTargetFrameworkVersion"> </Target> If we move this target to `Xamarin.Android.Legacy.targets`, it will be imported by binding projects. We also get the added benefit of it not being in .NET 6. `$(AndroidUseLatestPlatformSdk)` is not supported in .NET 6, so we should not have this MSBuild target there. Co-authored-by: Jonathan Peppers <jonathan.peppers@microsoft.com>
Fixes: https://developercommunity2.visualstudio.com/t/xamarin-android-bluetooth-the-advertisin/841102 Fixes: dotnet#2595 Update enumification of various `Android.Bluetooth.LE.AdvertisingSetParameters.Builder` and `Android.Bluetooth.BluetoothDevice` methods to use the `Android.Bluetooth.BluetoothPhy` enum instead of the `Android.Bluetooth.LE.ScanSettingsPhy` enum, introduced in e33eb53. Backwards compatibility is achieved by creating overloads for the existing methods in `Additions`, and marking them as `[Obsolete]`. The API "breakage" is because the `[Register]` attribute has moved from the incorrect methods to the correct methods. As the signature change is an enum, the marshalled type is still an `int`, so moving the `[Register]` should not cause issues. For example: // Current [Register] public void DoSomething (BadEnum value) { ... } // Fixed [Register] public void DoSomething (GoodEnum value) { ... } [Obsolete ("Use DoSomething(GoodEnum)")] public void DoSomething (BadEnum value) => DoSomething ((GoodEnum)value); Note: this is only generally save to do when `DoSomething()` is a *non-`virtual`* method (i.e. Java `final` method). Fortunately, this is the case with the methods involved here.
jonpryor
requested review from
dellis1972,
grendello,
jonathanpeppers and
pjcollins
as code owners
jonpryor
added
the
use-rebase-and-merge
jonpryor
added a commit
that referenced
this pull request
Aug 25, 2021
Context: https://developer.android.com/about/versions/12 Context: #6234 We (try to) base Xamarin.Android product versions on the latest Android versions, and API-31 is "Android 12". With the merging of stable API-31 support (5f408eb, e722825, others), we want our first release with API-30 support to likewise be v12.0. The [d16-11][0] branch is planned on being the first release which will offer stable API-31 support, via PR #6234, and once merged the d16-11 branch will report itself as v12.0. As xamarin-android/main is tracking the *next* Xamarin.Android version, bump `$(ProductVersion)` to v12.0.99 for eventual release as v12.1.0. [0]: https://github.com/xamarin/xamarin-android/commits/d16-11
Context: dotnet#6234 Context: 1e5bfa3 Context: https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=5132407&view=logs&jobId=96fd57f5-f69e-53c7-3d47-f67e6cf9b93e&j=96fd57f5-f69e-53c7-3d47-f67e6cf9b93e&t=65256bb7-a34c-5353-bc4d-c02ee25dc133 Changes: dotnet/java-interop@48766c0...476bb5b * dotnet/java-interop@476bb5b7: [build] .NET 6 P7 Support (dotnet#869) * dotnet/java-interop@0028e32c: [build] set $(DisableImplicitNamespaceImports) by default (dotnet#859) We don't actually *care* about dotnet/installer@9c463710 bump. We care that the attempt to build PR dotnet#6234 fails to build: …/xamarin-android/src/Mono.Android/Mono.Android.targets(247,5): error : CompatApi command: /Users/builder/.nuget/packages/microsoft.dotnet.apicompat/5.0.0-beta.20181.7/tools/net472/Microsoft.DotNet.ApiCompat.exe "/Users/builder/azdo/_work/2/s/xamarin-android/tests/api-compatibility/reference/Mono.Android.dll" -i "/Users/builder/azdo/_work/2/s/xamarin-android/bin/Release/lib/xamarin.android/xbuild-frameworks/Microsoft.Android/net6.0" --allow-default-interface-methods --baseline "/Users/builder/azdo/_work/2/s/xamarin-android/tests/api-compatibility/acceptable-breakages-vReference.txt" --validate-baseline --exclude-attributes "/Users/builder/azdo/_work/2/s/xamarin-android/tests/api-compatibility/api-compat-exclude-attributes.txt" …/xamarin-android/src/Mono.Android/Mono.Android.targets(247,5): error : CheckApiCompatibility found nonacceptable Api breakages for ApiLevel: v12.0. …/xamarin-android/src/Mono.Android/Mono.Android.targets(247,5): error : Compat issues with assembly Mono.Android: …/xamarin-android/src/Mono.Android/Mono.Android.targets(247,5): error : TypesMustExist : Type 'Xamarin.Android.Net.AndroidMessageHandler' does not exist in the implementation but it does exist in the contract. …/xamarin-android/src/Mono.Android/Mono.Android.targets(247,5): error : Total Issues: 1 It fails to build because we `CheckApiCompatibility` expects the `Xamarin.Android.Net.AndroidMessageHandler` type to exist, and it doesn't exist, because it was added until… 1e5bfa3. That's the primary thing we're after. Everything else is fluff, and the dotnet/runtime-related changes are not otherwise needed -- or cared about -- on d16-11. Co-authored-by: Jonathan Peppers <jonathan.peppers@microsoft.com> Co-authored-by: Steve Pfister <steve.pfister@microsoft.com>
jonathanpeppers
approved these changes
Aug 26, 2021
There was a problem hiding this comment.
The two legacy tests that failed are both error XA0010: No available device., so we can ignore those.
There is an apkdiff failure which makes sense because Mono.Android.dll grew:
stdErr: Error: apkdiff: Assembly 'assemblies/Mono.Android.dll' size increase 5,567 is 447 bytes more than the threshold 5,120.
Error: apkdiff: Size regression occured, 1 check(s) failed.
The .NET tests might be just a lot of work to fix, and we probably don't want to backport all of it.
How long lived is the d16-11 branch? Is it worth disabling some tests so this is at least greenish?
It lives until it is replaced by Visual Studio 17, and/or until a "major security issue" pops up which requires servicing during the servicing timeframe (2 years? Not sure.) I don't anticipate any "major security issues" popping up, but who ever does? We probably want it "green-ish" enough that everything Legacy is green. Question is, have we hit that point now? |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Cherry-pick the following commits, newest-to-oldest: