Closed knocte closed 4 years ago
I think this might be a Xamarin.Forms issue rather than a Xamarin.Android issue.
Are you sure?
BTW I realised this error seems to pop up to non-xamarin devs too:
Looking at the various stack overflow links this seems like a bug in the java support libraries. I have a feeling this is something that Xamarin.Forms might need to handle.
You mean that XF code should add a catch(RuntimeException)
block?
@Redth based on @dellis1972's suggestion, could you investigate on your side? Thanks!
@grendello my understanding of this is it's either an Android Support library bug (in which case, updating to the latest 28.0.0.3 is worth a try), or it's a bug in how Xamarin.Forms is using that API. If updating to 28.0.0.3 doesn't resolve the issue, I think the Xamarin.Forms team needs to look at this issue and see if they can work around the crash in their usage. Maybe @PureWeen has some thoughts?
Also with the support library update make sure to update the Target Framework to at least 9.0. I pulled down your project and noticed that it's still 8.1 https://github.com/knocte/geewallet/blob/frontend/src/GWallet.Frontend.XF.Android/GWallet.Frontend.XF.Android.fsproj#L13
With how the Support Library packages are put together if you are targeting 8.1 but have support 28 installed you'll still just be getting the bits for support 27
Reading through the reports it seems a lot of people encounter this with ViewPagers but the scenario you are using doesn't seem to involve a ViewPager. It also seems like everyone just kind of fixes this by finding something to override :-/
From the stack it seems like the exception is happening here in your code yes?
currentPage.Navigation.InsertPageBefore(newPage, currentPage)
currentPage.Navigation.PopAsync()
|> DoubleCheckCompletion
A few thoughts I would have on this would be
Also with the support library update make sure to update the Target Framework to at least 9.0
Thanks, in fact with 8.1 we still got the crash again even after upgrading the Support libs, so I'm upgrading TargetFramework now to 9.0 and will release new version of the app. If it keeps happening after this, will report back.
is the page being popped properly disposing of everything?
That pattern you highlight only happens twice in my app, once with the WelcomePage and another one with the LoadingPage. Both of these pages are very lightweight, by a first glance it seems I don't need to dispose anything on them, as they have very basic widgets, no timers, etc. In what cases do I need to dispose things?
Could you change this to doing a PushAsync and then Remove(currentPage) ? I'm just curious if adjusting that behavior a little bit would cause a different outcome?
I seem to recall that I tried this before and was having problems with it. Anyway, if after the upgrade to 9.0 I still get this crash, I'll try changing this and report back.
If you side load the apk you use for the app store or deploy from VS with all the same settings you use to produce the apk for the appstore can you reproduce?
Well this crash is so rare (have had only a single crash since I tried upgraded the Support libraries; but granted, I have just less than 10 installations of my app because it's not officially launched yet*) that I'm very sure I would not be able to reliably reproduce it by testing this.
* It's launched in the appstore in production, but I mean it's not being actively publicised.
Thanks, in fact with 8.1 we still got the crash again even after upgrading the Support libs, so I'm upgrading TargetFramework now to 9.0 and will release new version of the app. If it keeps happening after this, will report back.
BTW, after upgrading the TargetFramework from 8.1 to 9.0, VisualStudioForMac changed all the support libraries lines of packages.config file, like this:
-<package id="Xamarin.Android.Arch.Core.Common" version="1.1.1.3" targetFramework="monoandroid81" />
+<package id="Xamarin.Android.Arch.Core.Common" version="1.1.1.3" targetFramework="monoandroid81" requireReinstallation="true" />
Which makes me wonder:
targetFramework
attribute be monoandroid90
instead of monoandroid81
here? Maybe this is what VisualStudioForMac wanted to perform?Isn't it possible to use PackageReference in a fsharp project? This way you wouldn't have to mess around with tfm in packages.config files.
Isn't it possible to use PackageReference in a fsharp project?
Last time I tried that, ironically the build worked on VS4Mac but not in VSforWindows. There's some github issue about this, don't remember where (but must not be fixed yet if I'm subscribed and didn't get any updates about it).
(PS: not sure if the issue is XamAndroid projects not supporting this yet, or F#.)
Shouldn't the targetFramework attribute be monoandroid90 instead of monoandroid81 here?
In fact, this is what requireReinstallation="true"
is for, but VS4Mac doesn't honor it (filed a different bug about it): https://github.com/mono/monodevelop/issues/9390
So I did a retargetting in VS for Windows, and released new binaries of my app, and it seems that since I use these new versions of the support libraries in the new monoandroid90 framework, this bug hasn't happened yet, so maybe it's already fixed.
If it keeps happening after this, will report back.
It didn't happen again, I'm closing. Thanks everyone.
Steps to Reproduce
(Sorry, I don't have a repro project because this crash is non-deterministic, sometimes it doesn't crash; when it does, I get it reported in my Sentry account.) My project, though, is: https://github.com/knocte/geewallet
Actual Behavior
Crash. Full raw exception logged:
Expected Behavior
Shouldn't crash.
Version Information
More version info from the Sentry report:
Log File
(Only reproduced it in an app installed from the Android AppStore.)