Alpha Release: Xamarin.Android 5.1.5, Cycle 5 – Service Release 3

BrendanZagaeskiBrendanZagaeski USForum Administrator, Xamarin Team Xamurai
edited August 2015 in Xamarin.Android

This thread has now been closed to direct all further updates about this service release onto the new Beta release thread:

http://forums.xamarin.com/discussion/47346/beta-release-xamarin-android-5-1-5-cycle-5-service-release-3/p1


Windows

  • Xamarin.VisualStudio_3.11.816.msi (cefca47)

Mac

  • mono-android-5.1.5-3.pkg (f98871a)

Reason for release: Additional bug fixes for the "Cycle 5" Stable Release on April 29 and the previous Cycle 5 Service Releases. (See the release blog for a short description of "Cycles" and "Service Releases.")

Release notes: http://developer.xamarin.com/releases/android/xamarin.android_5/xamarin.android_5.1/#Xamarin.Android_5.1.5

Date published: See https://releases.xamarin.com/.

NOTE: Alpha versions have not yet completed the full suite of tests by the Xamarin QA team. That said, customer reports of any regressions (or bugs that are incorrectly marked fixed) are still much appreciated, even if the problem would have eventually been caught during the full QA testing process.

Previous versions, downgrading

You can downgrade back to the current Stable version by switching updater channels.

Older versions (from before April 29)

If needed, you can downgrade back to older versions (from before April 29) by manually reinstalling each old package. See the "Previous versions, downgrading" section on the April 29 Stable release thread for the older downgrade links.

Guidelines for this thread

  1. This first post will be updated regularly.

  2. Hopefully this thread will help answer "what might break if I update to this release?"

  3. If you find a new problem that is specific to this version, please file a bug report.

  4. Please discuss older bugs that are unchanged in this release compared to the previous Stable version in Bugzilla instead.

  5. Of course for questions and discussions about topics other than bugs, feel free start new forum threads.

Fixes for known issues from recent releases

  • Bug 31527 - [Android] "The following assembly referenced from ... could not be loaded: Assembly: System.Runtime ... Version: 4.0.0.0" when using the "Shared Runtime" with the linker enabled. Workaround: set "Project Options -> Android Build -> Linker [tab] -> Linker behavior" to "Don't link" in Xamarin Studio or "Project Properties -> Android Options -> Linker [tab] -> Linking") to "None" in Visual Studio. Enabling linking when the "Shared Runtime" is enabled is an intentionally untested scenario (partly because the on-device "shared runtime" assemblies will necessarily never be linked).

  • Bug 31597 - [Android] For some projects the generated .mdb files are incorrect, causing breakpoints to be skipped or incorrect line numbers to appear in the call stacks. Possible workaround: add Condition="'$(AndroidLinkMode)' != 'None' AND '$(AndroidUseSharedRuntime)' != 'true'" to the StripEmbeddedLibraries task in C:\Program Files (x86)\MSBuild\Xamarin\Android\Xamarin.Android.Common.targets on Windows or /Library/Frameworks/Xamarin.Android.framework/Versions/Current/lib/xbuild/Xamarin/Android/Xamarin.Android.Common.targets on Mac.

Remaining known issues from the April 29 Stable Channel release, with more common or severe issues near the top

  • Bug 30513 - [Android] The logged stack traces from exceptions thrown within async methods do not include the actual location where the exception was thrown. Partial workaround: switch back to the old Xamarin.Android 4.x exception propagation style by setting the XA_BROKEN_EXCEPTION_TRANSITIONS environment variable to true (see also Bug 30513, Comment 11).

  • Bug 29326 - [Android] String resources defined in NuGet packages overwrite string resources defined in app project, causing the displayed app name to be incorrect for example. Workaround: avoid using the same string key that is used in the NuGet packages.

  • Non-public Bug 30481, Bug 29557 - [Mono] [Android] [iOS] SqlConnection.GetSchema() fails with "SourceTable is required to be a non-empty string". (A fix for this issue is planned for the upcoming "Service Release 3.")

  • Bug 30548 - [Android] Under certain conditions new threads take several seconds to start. This problem seems to be triggered by Xamarin.Insights 1.10. Partial workarounds: upgrade Xamarin.Insights to version 1.10.3, downgrade to version 1.9, or remove it entirely.

  • Bug 30915 - [Xamarin Studio] [Android] Xamarin Studio repeatedly asks for the password for the selected certificate when attempting to sign using SHA1withDSA certificates from keystore files. Xamarin Studio should instead display the error message from jarsigner: "private key algorithm is not compatible with signature algorithm" as it did in Xamarin Studio 5.8. (SHA1withRSA or MD5withRSA certificates do work without error.)

  • Bug 29731 - [Android] Android.Bluetooth.BluetoothAdapter.Enable is incorrectly marked as [Obsolete("deprecated")] for API level 20 and higher.

Remaining known issues from Cycle 5 – Service Release 2

  • Bug 31423 - [XamarinVS] [Android] [iOS] Locked .dll files: "Could not copy "... PortableClassLibrary1.dll" to "bin\Debug\PortableClassLibrary1.dll". Exceeded retry count of 10. Failed." This is a different problem than Bug 26841 because it affects .dll files rather than .dll.mdb files. It appears to be less common than Bug 26841. The results to date suggest that it is a bug in Visual Studio itself rather than in the Xamarin extensions. For example, it appears to be possible to hit the problem using a Windows Phone project, with no Xamarin involvement at all. The recent changes to the Xamarin "Clean project" process to properly remove stale files might have caused this to become easier to hit with Xamarin projects. In any case, it is still under investigation.

EDIT July 21: Add Android bug 30513.
EDIT July 24: Update version numbers for new Alpha builds. Remove now fixed iOS bug 31893. Add Mac-only iOS Bug 32298.

Posts

  • JeremyKolbJeremyKolb USMember ✭✭✭

    @ArturMalendowicz I've been hitting that one too.

  • BrendanZagaeskiBrendanZagaeski USForum Administrator, Xamarin Team Xamurai

    @ArturMalendowicz, thanks for the heads-up on Bug 30513. I tested the regression status of the bug, accordingly updated the target release for the fix to be the next service release (Cycle 5, Service Release 4, tentatively in Alpha around the middle of August), and added the bug to the list of known issues in the first post in the thread along with a partial workaround.

  • JeremyKolbJeremyKolb USMember ✭✭✭

    That bug should probably be slated for a hotfix. It makes Xamarin Insights useless. Just like 31597 which makes it impossible to debug in a lot of situations.

    @BrendanZagaeski what is the hotfix policy? Each stable release introduces more bugs (usually around debugging) and some of them are so bad that we really could use some minor hot fix releases. Waiting multiple stable releases (and thus months) for a usable product is not always practical when waiting for actual bug fixes.

  • ArturMalendowiczArturMalendowicz USMember ✭✭

    @JeremyKolb I messeged you with workaround - did you read it? I will paste it here:

    Okey guys, so I have found workaround for this bug, here is step by step what
    to do to handle it and let Xamarin.Insights work.
    1.Add text file to Android project(name doesn't matter)and set it from
    "Content" in properties to "AndroidEnvironment"

    2.In the text file you created add that flag:
    XA_BROKEN_EXCEPTION_TRANSITIONS=true

    3.Then add android exception global handler in your droid project, it will
    handle Android exceptions which normally crashes application before your
    Xamarin.Insights(or other report tool)would be able to do some work.

    AndroidEnvironment.UnhandledExceptionRaiser += (sender, args) =>
    {
    args.Handled = true;
    }

    And voila, the Xamarin.Insights is ready to work for you :)

  • OtaMaresOtaMares DEMember ✭✭

    Is 30513 only related, as stated by the title of the bug report, to async void methods or is there a general issue with the stacktrace?

  • BrendanZagaeskiBrendanZagaeski USForum Administrator, Xamarin Team Xamurai
    edited July 2015

    Apologies in advance for the wall of text. These release announcements probably aren't the ideal place to discuss release policy, but there isn't a perfect alternative at the moment, so I'll do what I can.

    JeremyKolb, Xamarin Insights is currently a preview product, so the effect of Bug 30513 on that product specifically would not make it eligible for a Stable channel hotfix. On the other hand, it seems likely this bug would also affect Raygun and other crash reporting tools, so at least in theory the bug probably could be eligible for a hotfix if the end-user cost (measured across all Xamarin customers) was estimated to be high enough. (As a side-note, one-off builds for Enterprise customers who might need the fix backported into the current Stable version are a whole different story.)


    I am just a member of the customer support team, not anyone in charge of release policy, so the most helpful additional information I can provide is probably a few additional observations about why Bug 30513 might not be an ideal candidate for a Stable channel hotfix (borrowing some notes from my response to a similar question a little while back).

    • Releasing any fix directly to the Stable channel increases the risk that the fix might introduce a new regression that hasn't yet been discovered. It could possibly even make things worse than the original problem. On top of that, each additional hotfix release extends the timeline for releasing the next "full" bugfix release. (In this particular example, a hotfix release for Bug 30513 would delay Cycle 5 – Service Release 3, delaying the release of the fix for Bug 31597.) Allowing releases to flow through the "normal" Alpha and Beta channel progression allows additional time for QA and customer testing to minimize the risk that the bug fixes will themselves introduce new breakages.

    • To date, Bug 30513 has not been as widely reported as Bug 31597. So if the engineering and release coordination teams were going to work on a Stable channel hotfix build, Bug 31597 would likely take precedence. Because Bug 31597 is itself a "side-effect" of earlier efforts at fixing debugging issues on Android (in particular Bug 30318), the release coordination team has a reason to be especially hesitant about releasing the candidate fix directly to the Stable channel without some time in the Alpha and Beta channels.

    • The proposed fix for Bug 30513 (that currently only exists in Mono 4.2) might not be easy to backport to the current Stable branch of Mono 4.0 on which Xamarin.Android 5.1 is based. I have set the target milestone of Bug 30513 to the next planned release (Service Release 4) to make sure the engineers assess whether this is feasible on that timeline (tentatively released to Alpha around mid-August). Similar to the problem with a hotfix, requiring that the fix be backported into Service Release 3 this late in the release cycle would introduce undesirable delays in getting SR3 to Stable.


    To present an alternate hypothesis, perhaps the bigger problem in this case is that bugs like Bug 30513 (and Bug 31597) should be detectable by the Xamarin Alpha and Beta testing process before they ever hit Stable. See my comment on the Cycle 5 – Baseline release thread from April 29 for the extent of my knowledge about Xamarin's efforts to mitigate the number of similar situations in the future. Part of the story described there is that releasing too quickly is itself part of the problem, so releasing hotfixes is something the release coordination team would like to avoid when possible.

    As a final note, in the particular case of Bug 30513 I would have liked to have seen the Xamarin team check the regression status and assign it to a target milestone shortly after it was filed (around the end of May), rather than just yesterday. The Xamarin support team has in fact just started to help monitor customer-filed bugs for possible regressions, so delays like this should hopefully be minimized moving forward.

  • BrendanZagaeskiBrendanZagaeski USForum Administrator, Xamarin Team Xamurai

    Is 30513 only related, as stated by the title of the bug report, to async void methods or is there a general issue with the stacktrace?

    The problem also affects async Task methods.

    It is probably not a problem for most (or all) non-async methods. For example, if I switch the async Task example from Comment 1 on the bug report to be a non-async method, the stack trace captured by Insights does include the name of the method where the exception was thrown (as desired).

    There might be other edge cases that misbehave in a way similar to async methods. If they exist, hopefully they will also be resolved by the fix for Bug 30513, but feel free to file an additional bug report and let me know if you find one. I can make sure any additional test cases are re-tested once the fix has made its way into a version of Xamarin.Android.

  • JeremyKolbJeremyKolb USMember ✭✭✭

    @BrendanZagaeski
    Thanks for the quick response. I think we all appreciate having you put out these forum posts. We like knowing that we have a voice and that someone is listening (thanks!). My gripe above was more about the fact that stable builds keep breaking things that used to work.

    While I recognize that all software has bugs there are some pretty big ones that keep slipping through that probably should have been caught by the QA team. I don't know how the QA team tests releases (maybe that would be a good topic for a blog post on planet.xamarin.com?) but various debugging scenarios keep breaking.

    Maybe if it was easier to switch between stable/beta/alpha releases users could test more? I know that I rarely switch to beta releases because it's a PITA. Maybe if we could switch easily while within VS or XS (have multiple installs but choose which one to use?) it would be easier... I'm not sure.

  • BrendanZagaeskiBrendanZagaeski USForum Administrator, Xamarin Team Xamurai
    edited July 2015

    there are some pretty big ones that keep slipping through that probably should have been caught

    That sounds like it approximately matches up with my "alternate hypothesis" from earlier. I'll link back once more to my comment on the Cycle 5 – Baseline release thread from April 29 for the extent of my knowledge about Xamarin's efforts to mitigate the number of similar situations in the future.

    On the positive side: The pacing of the release schedule has changed now, partly in response to the number of problems observed with the April 29 "Cycle 5 – Baselines" release (see the release blog for a short description of "Cycles" and "Service Releases"). The objective is that the next major feature release (Cycle 6 – Baseline) will be significantly better thanks to the extended timeline. Having a smoother Baseline release will hopefully also help make the follow-up (bug-fix) "Service Releases" for Cycle 6 stay on a quicker pace than the Service Releases for Cycle 5.

    Maybe if it was easier to switch between stable/beta/alpha releases users could test more?

    There are some medium term intentions to make side-by-side installations possible. That would help with pre-release testing as well as a few other scenarios. But that feature hasn't yet been put onto a roadmap. (Of course it's also a little bit of a "catch-22" since a feature that changes how all the files installed by Xamarin are looked up could have a higher potential to introduce bugs compared to other more incremental changes.)

  • BrendanZagaeskiBrendanZagaeski USForum Administrator, Xamarin Team Xamurai

    @LucasTeixeira, it looks like that is indeed the same underlying issue as Bug 30513, so it should hopefully be resolved once the fix for that bug is released.

  • jamie94bcjamie94bc GBMember

    @BrendanZagaeski is there an ETA for C5SR4 (primarily for Bug 30513)? We have a bunch of exceptions logged that are pretty much useless.

  • OlegIlyinOlegIlyin USMember
    edited August 2015

    Regarding Bug 30513 - it is actually insane, we reported it on 27th May and it was fixed same day and it takes 3 month to make it to stable release. We use HockeyApp and we do not care that Xamarin.Insights is still preview, providing proper stack traces is bug in mono runtime not in Xamarin.Insights. We have a huge user base and therefore a lot of crashes with corrupted stack traces. And we have to spend too much extra effort to fix such bugs. And we are enterprise customer. It's a shame.

  • BrendanZagaeskiBrendanZagaeski USForum Administrator, Xamarin Team Xamurai
    edited August 2015

    @JamieClarke, Cycle 5 – Service Release 4 is tentatively due in Alpha around mid-August and in Stable around the end of August. That said, I am still uncertain of whether the "fix" that is present Mono 4.2 is something that can be backported to Mono 4.0. I have a suspicion the fix might in fact be that an extra few sections of the Microsoft Referencesource have been added to replace some of the original Mono sources. That kind of "large commit" (that just "by luck" also happens to fix Bug 30513 as a side-effect) would probably be difficult to backport to Mono 4.0. "Cycle 6" (that will be based on Mono 4.2) is tentatively due to have Alphas around the beginning of September.


    EDIT: Correct bug number typo.

  • BrendanZagaeskiBrendanZagaeski USForum Administrator, Xamarin Team Xamurai

    @OlegIlyin, as an Enterprise customer you may submit a request for an "Enterprise hotfix" for Bug 30513 via either your account manager or the Support Team. Enterprise hotfixes have more flexibility in how they can be made. For example, it may be possible for the engineers to create a one-off build of Xamarin.Android 5.1.5 that changes the Mono reference from Mono 4.0 to Mono 4.2. This would not be possible for a Stable channel hotfix release because there would be too many unknowns about how Mono 4.2 could break or alter the behavior of Xamarin.Android.

  • BrendanZagaeskiBrendanZagaeski USForum Administrator, Xamarin Team Xamurai

    While we're on Bug 30513, I should perhaps add an extra note that the problem appears to be limited to unhandled exceptions. So in theory one alternate way to work around the problem might be to wrap every awaited async method in a try/catch block and then explicitly log the exception during the catch.

    (This is an alternate to Artur's suggestion from earlier in the thread.)

  • BrendanZagaeskiBrendanZagaeski USForum Administrator, Xamarin Team Xamurai

    This thread has now been closed to direct all further updates about this service release onto the new Beta release thread:

    http://forums.xamarin.com/discussion/47346/beta-release-xamarin-android-5-1-5-cycle-5-service-release-3/p1

This discussion has been closed.