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.
When deploying an application that uses the shared runtime, deploy the correct runtime for the target architecture of the device we're deploying to, regardless of the project configuration.
Non-shared runtime builds should detect the target devices architecture and give the user an error instead of deploying.
This needs to be done for Visual Studio and MonoDevelop. (Visual Studio already presents the error correctly, but for both runtime configurations.)
Visual Studio should already do both of these things. Are you saying one of them is not working properly?
In Visual Studio on 32-bit Windows 7, Mono for Android 4.2.1 presents the "Incompatible Architecture" dialog, regardless of whether or not it is a shared runtime.
In MonoDevelop 3.0, Mono for Android 4.2.1 just deploys and crashes on device.
That is correct (for VS), as their are 2 native pieces required to run an app. One is libmono in the shared runtime, the other is libmonodroid in the user apk.
We always install the proper shared runtime for the device, regardless of the app architecture.
However, if the user's app does not support the device's architecture, we have little choice other than to give a dialog. (Or deploy it anyways and crash.)
What would the implications be for building all libmonodroid architectures into the user apk for shared runtime builds?
Technically, it should be fine.
However, it does create another instance of "why does my app work in Debug but not Release?"
We could also turn on all arch's in the default template. It would work correctly in Debug and Release, but would add ~2 MB to the user's Release package. (Which they could turn off in Project Properties.)
I would prefer to take chances with having to deal with the "app works in debug but not release" disconnect, since the IDE does prompt correctly before deploying. The only risk would be if people try to manually push release builds outside of the IDE without ever having tested on emulator or device. Or are you concerned about a different scenario?
I'm not sure it is worth defaulting everyone to a 2MB increase in app size runtime, but it might be worth considering. This really comes down to whether or not other android becomes widely adopted on other architectures. The risk is that lots of unnecessarily large apps would ship to the app store from people that never check that kind of thing, or people would just complain about size of the hello world.
Another $0.02 on the "which runtime to include" question.
There's no point in including x86 by default, unless doing Debug builds to an x86 "emulator". The only widespread x86 hardware is Google TV, which doesn't support the NDK, and thus can't be targeted by Mono for Android anyway. In this case the "Debug only" scenario set forth in comments 5-6 is fine.
ARMv5 (armeabi) is dying, and really shouldn't be present on any new devices (except maybe _really_ low end devices). ARMv5 also lacks support for SMP/multi-core machines and hardware FPU, so we run slowly on it. Unfortunately, ARMv5 is the only supported hardware for the emulators < API14, but emulators fall under the "Debug only" scenario.
Which leaves ARMv7 (armeabi-v7a), which is SMP-compatible and provides a hardware FPU. We should make this the default Release target in the 4.4 release, and have devs opt-in to ARMv5 & x86 (instead of the current situation of ARMv5 being the default and opting into ARMv7 & x86).
Thanks for the additional information. That definitely helps, particularly regarding x86.
I'd like to see us fix this bug as I've proposed, and perhaps the discussion regarding defaulting to ARMv7 should be a new bug.
In f5e6d2adc533000a31f704f377f4a4da54ee0137, we now include all libmonodroid.so's in the user's apk if they are using the shared runtime.
This means deploying to an x86 emulator should now work out of the box, but we don't bloat their release apk with it (by default), since there are ~no x86 supported devices out there.
Dunno why I didn't mark this as fixed.