Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
Mono organizations on
GitHub to continue tracking issues. Bugzilla will remain
available for reference in read-only mode. We will continue to work
on open Bugzilla bugs, copy them to the new locations
as needed for follow-up, and add the new items under Related
Our sincere thanks to everyone who has contributed on this bug
tracker over the years. Thanks also for your understanding as we
make these adjustments and improvements for the future.
Please create a new report on
Developer Community or GitHub with
your current version information, steps to reproduce, and relevant error
messages or log files if you are hitting an issue that looks similar to
this resolved bug and you do not yet see a matching new report.
You must be compiling against SDK 26 (aka Android 8.0);
Run this code:
var id = Build.Serial;
It will blow up with Java.Lang.NoSuchMethodError: no static method "Landroid/os/Build;.getSerial()Ljava/lang/String;"
Now, be aware that there is already a Build.Serial:
https://developer.android.com/reference/android/os/Build.html#SERIAL with https://developer.android.com/reference/android/os/Build.html#getSerial()
So the correct thing to do is NOT to re-map it to Serial as we already re-mapped SERIAL with Serial... so it should remain -> GetSerial();
Issue found here:
Likely fallout from this: We need to fixup generator + apimerge behavior so that `Build.getSerial()` (since API-26) doesn't *replace* `Build.SERIAL` (since API-9).
There is no chance that api-merge can handle this.
This rather exposes the problem in the Java.Interop (or Android.Runtime, I don't know exactly which) behavior regarding unified API. What happens if SERIAL is removed at API Level X and there is completely valid getSerial() in API Level X? Java.Interop or Android.Runtime must handle it as if it were a method call in API Level X or later and a field reference in older API Levels.
Rephrase: it is a bug in interop layer.
Adding workaround for this issue is doable, but what really has to be done is above.
jonp told me that there could be more of the same kind of problems, but to verify that (note that it's not ONLY about detecting those) he needs to implement attribute value level API comparison that checks [Register] properties anyways.
I have many changes to "workaround" these kind of field overrides in ALL the API Levels (it is NOT DOABLE to detect "breaking" changes in API Level 26 as generator member comparison does not report the conflict details, only reporting "there is conflict", and making changes to give further details is a LOT of changes), but even if I made those changes there is no way to verify that the changes are valid and sufficient, without implementing attribute properties comparer.
Created attachment 25276 [details]
reference metadata fixup changes
Would be great to ping James with his plugin: https://github.com/jamesmontemagno/DeviceInfoPlugin
Alex should read whole thread with better attention :)
It's based in part on Attachment #25276 [details], but *only* fixes `Build.getSerial()`, so that we can easily merge this into d15-4 for a future service release.
The rest of Attachment #25276 [details] should be applied to xamarin-android separately.
how to get this fix, i installed xamarin with VS2017 on 9 oct and since then I am getting this error, need immediate help
@abgarg: There are two workarounds until an official release containing the fix is available:
1. *Do not* set `$(TargetFrameworkVersion)`=v8.0. Using v7.1 or any earlier version will suffice.
Unfortunately this means you can't easily access the new Oreo APIs. :-(
2. If *you* are accessing the `Android.OS.Build.Serial` property -- and not some 3rd party library -- you can instead use JNI to reimplement the previous behavior:
Alternatively, you can try the *unreleased* installers, available at:
You want the installers from: Commercial Xamarin.Android 8.0 (d15-4)
*** Bug 60197 has been marked as a duplicate of this bug. ***
This bug did not make 15.4 SR1 due to a conflict with insertion. It will be included in 15.4 SR2. Thus I am setting the milestone accordingly.