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.
I feel certain that this is something Xamarin is aware of, but I couldn't find any existing bug reports, and it keeps coming up on the forums. Xamarin.Forms does not handle activity destruction/recreation properly on Android, and it is causing a great deal of pain for developers. The advice I've seen from Xamarin engineers on the forums is to disable activity destruction on configuration changes (see here: https://forums.xamarin.com/discussion/26873/how-to-restore-the-navigation-stack-after-page-suspend-resume-in-xamarin-forms), but not only is that NOT the recommended approach by Google, but it doesn't help at all for other cases in which an activity is destroyed. For example, if you start a new activity using StartActivity then your current activity may be destroyed and recreated. Or if you just leave the app and come back.
The way this works now is that the Forms application's lifecycle is tied to the main activity. This is wrong. I don't think anything is going to make this better until the application lifecycle is detached form the activity lifecycle.
Google's recommendation for this is to use a retained fragment. The activity looks for the fragment in its fragment manager when it's created, and if it doesn't find one it creates a new one. All important state is kept in the fragment, and the activity does almost nothing. That's what we need here. Instead of FormsApplicationActivity we need FormsApplicationFragment.
I'm honestly not sure how Xamarin.Forms developers have gotten by this far in the state that this is in. I wouldn't even consider shipping an app that doesn't handle this properly, which basically means I wouldn't consider shipping an app on Android with Xamarin.Forms because it doesn't handle it properly.
To see an example, run the attached project in Xamarin, click the button, and then press the back button. Then repeat. Each time you do that, if the activity is destroyed, the MessagingCenter subscription is duplicated, and you get multiple media pickers. You can also set a breakpoint in OnCreate to see it getting called multiple times. You can force this to happen if you enable the developer option "Don't keep activities", but even with that off this issue will reproduce occasionally in real-world scenarios.
Created attachment 10842 [details]
Here's another person running into this issue:
I've seen several others as well, and I still don't understand how anyone is comfortable shipping a Xamarin.Forms app with this behavior. I haven't seen anyone explain how they work around this. It seems like any Forms app will (at best) appear to relaunch itself every time you sneeze at it.
Temp fix for the MessagingCenter is to clear it yourself in the OnCreate function.
//Messagingcenter is not clearing itself so we have to do it...
MethodInfo dynMethod = typeof(MessagingCenter).GetMethod("ClearSubscribers", BindingFlags.NonPublic | BindingFlags.Static);
dynMethod.Invoke (null, null);
Another workaround: I went with the 'nuclear' option of killing the
process in 'MainActivity.OnDestroy()'.
Reason is that I'm afraid that values of static members in libraries I use could be in some undesirable state (similar to situation with 'Resolver'),
so this way I ensure a clean start of app.
protected override void OnDestroy()
Yeah, I'm getting this too, intermittently. Happens when I launch.
Caused by: java.lang.reflect.InvocationTargetException
at java.lang.reflect.Method.invoke(Native Method)
... 1 more
Caused by: md52ce486a14f4bcd95899665e9d932190b.JavaProxyThrowable: System.NullReferenceException: Object reference not set to an instance of an object
at Xamarin.Forms.Platform.Android.FormsApplicationActivity.OnPrepareOptionsMenu (Android.Views.IMenu) <0x00020>
at Android.App.Activity.n_OnPrepareOptionsMenu_Landroid_view_Menu_ (intptr,intptr,intptr) <0x0005b>
at (wrapper dynamic-method) object.385a6ee4-47be-4098-8536-f05276e7c218 (intptr,intptr,intptr) <0x0004b>
at md5530bd51e982e6e7b340b73e88efe666e.FormsApplicationActivity.n_onPrepareOptionsMenu(Native Method)
... 4 more
I have exactly the same problem.
Please do something about this - ASAP./
Also, seeing Xamarin.Forms is supposed to be cross-platform, the details of all this should be hidden from the app developer. because it works differently on each platform, Xamarin should hide the detail of what is happening. at the least it should provide overridable methods or properties or attributes on the Application class that we can use (in a platform independent manner) to react to and control such behaviour.
Thank you for taking the time to submit this feature request. We like this idea and have added it to our internal feature tracking system.
Xamarin Forms Team
I just upgraded to XF 220.127.116.11 and now my Android app won't start unless I remove this line of code (see below). I did some research and according to Adam Kemp, this bug is the reason why.
#region Resolver Init
SimpleContainer container = new SimpleContainer();
container.Register<IDevice>(t => AndroidDevice.CurrentDevice);
container.Register<IDisplay>(t => t.Resolve<IDevice>().Display);
container.Register<INetwork>(t => t.Resolve<IDevice>().Network);
My XLabs Camera feature relies on this line of code, so without it, I can't launch my application.
NOTE: This was not a problem when I was running XF 18.104.22.16846.
I see that this is resolved, but based on Adam Kemp's detailed explanation and my inability to use the XLabs Camera in my Android project, I see this as a show stopper. Are you treating this as a bug that needs to be fixed in a future release of Xamarin.Forms? If not, please explain why. Also, if customers like Adam and I need to escalate this issue, please let us know how to do so. Now that you are part of Microsoft, I would expect to see escalation procedures in place for Microsoft Partners. Thanks for your attention to this matter.
Can someone from Xamarin please provide an update on this? Has this been fixed in the 22.214.171.124 release?
I moved my Solution over to Windows 10 over the weekend to test some new Package builds based on the Android SDK 23 issue and Xamarin.Forms. I am now using both Visual Studio 2013 Prem Update 5 along with Xamarin Studio 6 (build 5174). The XLabs Camera is now working in my Xamarin.Forms Android Project.
I saw another small issue that seem to be fixed, so I just tried to uncomment my Resolver code and it worked. I wonder if this is based on different versions of the software running in both development environments. If so, this is encouraging, but also opens all kinds of questions in terms of development environment integrity. Hope this helps someone else who might run into the issue. This was happening in my Mac environment using Xamarin Studio 5.10.3 (build 51).
I've moved this to a discussion on the Evolution forums for better visibility and feedback from the community. I've only summarized the information from the OP and not any comments. Please weigh in with your comments on any suggestions on how to handle this better in that forum post. Thank you!