Several syntax errors when building binding library for Android 11. #5027
Comments
|
I'm not sure how it could try to bind to an Can you provide the |
|
Will do today or tomorrow. |
|
Part of the api.xml with broken items |
|
For some reason in Android 11 it seems to generate SetNotificationUris with IList`1 of uris instead of SetNotificationUri with one uri. |
|
I don't see any issues with the |
|
OK. I could try but it is rather big and won't fit standard email size. Could you look at my last comment - it seems that the binding generator is trying to create list so there is plural ”s” at the generated method name and the parameter uris is also prualar but it should be singular. |
|
The reason is that in API 29+ Maybe the But when you change to API 29+ the base method can be found and it tries to generate the method. I suspect in API 29+ it is generating both methods, not just the plural version. So the issue probably isn't anything "weird", it's just a problem understanding generics which is a common issue. |
|
I'll check the jar later. Does 29+ means 29 and above? It was working for Android 10 - 29 but it doesn't work for Android 11 - 30. Could you elaborate ”it's just a problem understanding generics which is a common issue”? Can I do anything about it? |
|
Isn't it reintroduced by this change ? |
|
It's possible, but I'm not sure how. That code still exists and hasn't been touched in this release to my knowledge. I am hoping once I have the .jar file I can step through the debugger and find why this is happening. |
|
@jpobst I've sent you an email with jar file. Please let me know if it will help you investigate the issue. |
|
Simplified test case, running against API-30 fails, while API-29 succeeds: |
|
Does it mean that the issue is in the generator? I was also trying to remove the error causing method by the transform but without luck it must be on the other phase of the generation process. |
|
Yeah, the issue is in Given this: Changing it to this doesn't work: It won't be a syntax error anymore, but it doesn't match the required type, so it still errors. It has to be changed to: Unfortunately this isn't something that can be worked around with The only workarounds I am currently aware of are:
|
|
OK. We can wait with changing the target framework for some time. I'm hoping it can be fixed internally in the generator soon. Any ETA? |
|
I filed a cleaned up version of this issue in Java.Interop for The deadline for 16.8/8.8 is pretty much passed, so likely 16.9/8.9 is the earliest. |
|
Thanks. |
jonpryor
pushed a commit
that referenced
this issue
Sep 17, 2020
Fixes: #5027 Context: dotnet/java-interop#699 The [`Cursor.setnotificationUris(ContentResolver, List<Uri>)`][0] interface default method was added in API-29. This introduces an issue when implementing `Android.Database.ICursor` in API-30+: when binding a Java class that implements `Cursor`: // Java public class MyCursor implements android.database.Cursor { // … } In the binding `generator` emits for `MyCursor`, the Java-to-managed marshal method to support `Cursor.setNotificationUris()` does not compile, as it tries to use a generic type -- `IList<T>` -- without providing any generic type parameters: // C# binding public partial class MyCursor : Java.Lang.Object, ICursor { static void n_SetNotificationUris_1 (IntPtr jnienv, IntPtr native__this, IntPtr native_cr, IntPtr native_uris) { var __this = Java.Lang.Object.GetObject<MyCursor> (jnienv, native__this, JniHandleOwnership.DoNotTransfer); var cr = Java.Lang.Object.GetObject<ContentResolver> (native_cr, JniHandleOwnership.DoNotTransfer); var uris = (System.Collections.Generic.IList`1) Java.Lang.Object.GetObject<System.Collections.Generic.IList`1> (native_uris, JniHandleOwnership.DoNotTransfer); __this.SetNotificationUris (cr, uris); } } We had thought that dotnet/java-interop@262743b47 addressed this issue, but we were mistaken. The `generator` fix for this scenario seems tricky, so as a workaround for now we can simply remove the `Cursor.setNotificationUris()` default method so users can implement the interface. (Although the method was added in API-29, we don't support Default Interface Members in API-29, so it was ignored. Thus, this problem doesn't show up until API-30+ is used.) [0]: https://developer.android.com/reference/android/database/Cursor#setNotificationUris(android.content.ContentResolver,%20java.util.List%3Candroid.net.Uri%3E)
jonpryor
pushed a commit
that referenced
this issue
Sep 17, 2020
Fixes: #5027 Context: dotnet/java-interop#699 The [`Cursor.setnotificationUris(ContentResolver, List<Uri>)`][0] interface default method was added in API-29. This introduces an issue when implementing `Android.Database.ICursor` in API-30+: when binding a Java class that implements `Cursor`: // Java public class MyCursor implements android.database.Cursor { // … } In the binding `generator` emits for `MyCursor`, the Java-to-managed marshal method to support `Cursor.setNotificationUris()` does not compile, as it tries to use a generic type -- `IList<T>` -- without providing any generic type parameters: // C# binding public partial class MyCursor : Java.Lang.Object, ICursor { static void n_SetNotificationUris_1 (IntPtr jnienv, IntPtr native__this, IntPtr native_cr, IntPtr native_uris) { var __this = Java.Lang.Object.GetObject<MyCursor> (jnienv, native__this, JniHandleOwnership.DoNotTransfer); var cr = Java.Lang.Object.GetObject<ContentResolver> (native_cr, JniHandleOwnership.DoNotTransfer); var uris = (System.Collections.Generic.IList`1) Java.Lang.Object.GetObject<System.Collections.Generic.IList`1> (native_uris, JniHandleOwnership.DoNotTransfer); __this.SetNotificationUris (cr, uris); } } We had thought that dotnet/java-interop@262743b47 addressed this issue, but we were mistaken. The `generator` fix for this scenario seems tricky, so as a workaround for now we can simply remove the `Cursor.setNotificationUris()` default method so users can implement the interface. (Although the method was added in API-29, we don't support Default Interface Members in API-29, so it was ignored. Thus, this problem doesn't show up until API-30+ is used.) [0]: https://developer.android.com/reference/android/database/Cursor#setNotificationUris(android.content.ContentResolver,%20java.util.List%3Candroid.net.Uri%3E)
|
While we can't get the real fix into 16.8, I did manage to simply remove the offending method for 16.8 Preview 4, which should allow implementing this interface: #5124. |
|
Thanks! I’ll check that once 16.8 Preview 4 will land in the preview channel. |
jonpryor
pushed a commit
that referenced
this issue
Sep 28, 2020
Fixes: #5027 Context: dotnet/java-interop#699 Context: dotnet/java-interop#699 (comment) Context: eadd3bd The [`Cursor.getNotificationUris()`][0] interface default method was added in API-29. Much as with `Cursor.setNotificationUris()` and commit eadd3bd, this introduces an issue when implementing `Android.Database.ICursor` in API-30+: when binding a Java class that implements `Cursor`: // Java public class MyCursor implements android.database.Cursor { // … } In the binding `generator` emits for `MyCursor`, the Java-to-managed marshal method to support `Cursor.getNotificationUris()` does not compile, as it tries to use a generic type -- `IList<T>` -- without providing any generic type parameters: // C# binding public partial class MyCursor : Java.Lang.Object, ICursor { static IntPtr n_GetNotificationUris (IntPtr jnienv, IntPtr native__this) { var __this = Java.Lang.Object.GetObject<MyCursor> (jnienv, native__this, JniHandleOwnership.DoNotTransfer); return global::Android.Runtime.JavaList.ToLocalJniHandle (__this.NotificationUris);; // ^^ error CS1503: Argument 1: cannot convert from 'System.Collections.Generic.IList<Android.Net.Uri>' to 'System.Collections.IList?' } } We had thought that dotnet/java-interop@262743b47 addressed this issue, but we were mistaken. The `generator` fix for this scenario seems tricky, so as a workaround for now we can simply remove the `Cursor.getNotificationUris()` default method so users can implement the interface. (Although the method was added in API-29, we don't support Default Interface Members in API-29, so it was ignored. Thus, this problem doesn't show up until API-30+ is used.) [0]: https://developer.android.com/reference/android/database/Cursor#getNotificationUris()
jonpryor
pushed a commit
that referenced
this issue
Oct 12, 2020
Fixes: #5027 Context: dotnet/java-interop#699 Context: dotnet/java-interop#699 (comment) Context: eadd3bd The [`Cursor.getNotificationUris()`][0] interface default method was added in API-29. Much as with `Cursor.setNotificationUris()` and commit eadd3bd, this introduces an issue when implementing `Android.Database.ICursor` in API-30+: when binding a Java class that implements `Cursor`: // Java public class MyCursor implements android.database.Cursor { // … } In the binding `generator` emits for `MyCursor`, the Java-to-managed marshal method to support `Cursor.getNotificationUris()` does not compile, as it tries to use a generic type -- `IList<T>` -- without providing any generic type parameters: // C# binding public partial class MyCursor : Java.Lang.Object, ICursor { static IntPtr n_GetNotificationUris (IntPtr jnienv, IntPtr native__this) { var __this = Java.Lang.Object.GetObject<MyCursor> (jnienv, native__this, JniHandleOwnership.DoNotTransfer); return global::Android.Runtime.JavaList.ToLocalJniHandle (__this.NotificationUris);; // ^^ error CS1503: Argument 1: cannot convert from 'System.Collections.Generic.IList<Android.Net.Uri>' to 'System.Collections.IList?' } } We had thought that dotnet/java-interop@262743b47 addressed this issue, but we were mistaken. The `generator` fix for this scenario seems tricky, so as a workaround for now we can simply remove the `Cursor.getNotificationUris()` default method so users can implement the interface. (Although the method was added in API-29, we don't support Default Interface Members in API-29, so it was ignored. Thus, this problem doesn't show up until API-30+ is used.) [0]: https://developer.android.com/reference/android/database/Cursor#getNotificationUris()
This comment has been minimized.
This comment has been minimized.
|
Thanks @brendanzagaeski for the update but the fix doesn't work as there was another update for this fix. Currently, it removes set methods https://github.com/xamarin/xamarin-android/pull/5124/commits but does not fix the issue as there was a second part with removed get methods https://github.com/xamarin/xamarin-android/pull/5161/commits that was not merged yet. Any chances for the update anytime soon? |
|
Thanks for the heads-up and the question! It looks like that second part of the fix is under consideration for inclusion in a future Visual Studio 2019 version 16.8 Preview (and Visual Studio 2019 for Mac version 8.8 Preview). I'll plan to update this issue again when a Preview version containing that second part of the fix is available. |
|
Thanks @brendanzagaeski. Please note that the one fix does not work without the other. |
|
Release status update A new Preview version of Xamarin.Android has now been published that includes both the first part of the fix from #5124 and the second part of the fix from #5161. The fix is not yet included in a Release version. I will update this item again when a Release version is available that includes the fix. Fix included in Xamarin.Android SDK version 11.1.0.17. Fix included on Windows in Visual Studio 2019 version 16.8 Preview 5. To try the Preview version that includes the fix, check for the latest updates in Visual Studio Preview. Fix included on macOS in Visual Studio 2019 for Mac version 8.8 Preview 5. To try the Preview version that includes the fix, check for the latest updates on the Preview updater channel. |
|
@brendanzagaeski Thanks, will be testing now. |
|
@brendanzagaeski @jpobst @jonathanpeppers Unfortunately during tests we are getting "random" errors - random because it occurs on 2 from 5 test machines with identical software configuration. or
Are you aware of anything changed lately in the preview release that could induce this issue? |
|
It seems to be related to the latest stable packages for GooglePlayServices when combined with bindings library build with P5 VS: When downgrading those packages to the previous stable it works fine: So there is obviously something with manifest merger shipped with Xamarin or other intermediate XML manifests/resource reader. |
|
@awattar I think there was a particular version of Xamarin.Build.Download that caused Can you use the latest Xamarin.Build.Download? |
|
@jonathanpeppers we were facing "error XA0000: Unhandled exception: System.IO.IOException: Sharing violation on path" - https://stackoverflow.com/questions/60184516/how-to-avoid-exception-sharing-violation-on-path-android-gms-r-java-and-andro - when using 0.7.0 some time ago and after switching to 0.8.0 it was gone. Now 0.10.0 is required by some of the recent other NuGets including GooglePlayServices so there is no way to use something different. The issue happens only on some machines and only when new binding build with fixed preview is combined with the 117 (stable) GooglePlayServices. It doesn't occur with downgraded GooglePlayServices or when binding library is not built with the latest preview. Perhaps more log should be added around
execution that could print |
|
@jonathanpeppers we were able to solve it - it was not strictly related to the Xamarin.Build.Download but rather its cache /Users/USER/Library/Caches/XamarinBuildDownload. After clearing the cache everything went smooth. So thanks for pointing this out. |
|
Release status update A new Release version of Xamarin.Android has now been published that includes both the first part of the fix from #5124 and the second part of the fix from #5161, as previously published in the Preview versions. Fix included in Xamarin.Android SDK version 11.1.0.17. Fix included on Windows in Visual Studio 2019 version 16.8. To get the new version that includes the fix, check for the latest updates or install the most recent release from https://visualstudio.microsoft.com/downloads/. Fix included on macOS in Visual Studio 2019 for Mac version 8.8. To get the new version that includes the fix, check for the latest updates on the Stable updater channel. |
|
Thank you all for the fix. @brendanzagaeski thanks for the info. |
|
I was having a similar issue, after a month without using my Mac I upgraded to latest stable Xamarin tooling(Xamarin.Android Version: 11.1.0.26) but I was still having the issue and I solved by removing the cache folder as @awattar indicates in a previous comment
|
ghost
locked as resolved and limited conversation to collaborators
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Steps to Reproduce
Expected Behavior
Builds fine.
Actual Behavior
Syntax errors on lines containing generic IList with an apostrophe -
global::System.Collections.Generic.IList`1
Version Information
Version 8.7.2 (build 4)
Installation UUID: 8e69c049-a293-460a-a5b8-d3f9e691c930
GTK+ 2.24.23 (Raleigh theme)
Xamarin.Mac 6.18.0.23 (d16-6 / 088c73638)
=== Mono Framework MDK ===
Runtime:
Mono 6.12.0.90 (2020-02/d3daacdaa80) (64-bit)
Package version: 612000090
=== Roslyn (Language Service) ===
3.7.0-6.20371.12+917b9dfae12e3b6cb266a3c062fb20a1e9d5fb06
=== NuGet ===
Version: 5.7.0.6702
=== .NET Core SDK ===
SDK: /usr/local/share/dotnet/sdk/3.1.401/Sdks
SDK Versions:
3.1.401
3.1.302
3.1.301
3.1.300
3.1.200
3.1.102
3.1.101
3.1.100
3.1.100-preview3-014645
3.0.100
MSBuild SDKs: /Library/Frameworks/Mono.framework/Versions/6.12.0/lib/mono/msbuild/Current/bin/Sdks
=== .NET Core Runtime ===
Runtime: /usr/local/share/dotnet/dotnet
Runtime Versions:
3.1.7
3.1.6
3.1.5
3.1.4
3.1.2
3.1.1
3.1.0
3.1.0-preview3.19553.2
3.0.0
2.1.21
2.1.20
2.1.19
2.1.18
2.1.16
2.1.15
2.1.14
2.1.13
=== Xamarin.Profiler ===
Version: 1.6.12.29
Location: /Applications/Xamarin Profiler.app/Contents/MacOS/Xamarin Profiler
=== Updater ===
Version: 11
=== Xamarin.Android ===
Version: 11.0.0.3 (Visual Studio Enterprise)
Commit: xamarin-android/d16-7/aca845b
Android SDK: /Users/mwesolowski/Library/Developer/Xamarin/android-sdk-macosx
Supported Android versions:
7.0 (API level 24)
8.0 (API level 26)
SDK Tools Version: 26.1.1
SDK Platform Tools Version: 30.0.4
SDK Build Tools Version: 29.0.3
Build Information:
Mono: 83105ba
Java.Interop: xamarin/java.interop/d16-7@1f3388a
ProGuard: Guardsquare/proguard@ebe9000
SQLite: xamarin/sqlite@1a3276b
Xamarin.Android Tools: xamarin/xamarin-android-tools/d16-7@017078f
=== Microsoft OpenJDK for Mobile ===
Java SDK: /Users/mwesolowski/Library/Developer/Xamarin/jdk/microsoft_dist_openjdk_1.8.0.25
1.8.0-25
Android Designer EPL code available here:
https://github.com/xamarin/AndroidDesigner.EPL
=== Android SDK Manager ===
Version: 16.7.0.13
Hash: 8380518
Branch: remotes/origin/dev/jmt/d16-7readconfig~2
Build date: 2020-07-23 22:38:02 UTC
=== Android Device Manager ===
Version: 16.7.0.18
Hash: 4b44bc1
Branch: remotes/origin/d16-7
Build date: 2020-07-23 22:38:26 UTC
=== Apple Developer Tools ===
Xcode 11.4.1 (16137)
Build 11E503a
=== Xamarin.Mac ===
Xamarin.Mac not installed. Can't find /Library/Frameworks/Xamarin.Mac.framework/Versions/Current/Version.
=== Xamarin.iOS ===
Version: 13.20.2.2 (Visual Studio Enterprise)
Hash: 817b6f72a
Branch: d16-7
Build date: 2020-07-18 18:45:00-0400
=== Xamarin Designer ===
Version: 16.7.0.492
Hash: f5afe667d
Branch: remotes/origin/d16-7-vsmac
Build date: 2020-07-10 18:42:54 UTC
=== Build Information ===
Release ID: 807020004
Git revision: 6b86e771c92aa2615d2c2a09919bb3d4ccb69a5a
Build date: 2020-08-12 07:16:26-04
Build branch: release-8.7
Xamarin extensions: 6b86e771c92aa2615d2c2a09919bb3d4ccb69a5a
=== Operating System ===
Mac OS X 10.15.5
Darwin 19.5.0 Darwin Kernel Version 19.5.0
Tue May 26 20:41:44 PDT 2020
root:xnu-6153.121.2~2/RELEASE_X86_64 x86_64
Log File
The text was updated successfully, but these errors were encountered: