Bug 5091 - Deploy shared runtime for target device architecture (regardless of configuration)
Summary: Deploy shared runtime for target device architecture (regardless of configura...
Status: RESOLVED FIXED
Alias: None
Product: Android
Classification: Xamarin
Component: Tools and Addins ()
Version: 4.1.x
Hardware: PC Mac OS
: Normal normal
Target Milestone: ---
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2012-05-15 11:06 UTC by Joseph Hill
Modified: 2012-05-29 18:00 UTC (History)
4 users (show)

Tags:
Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and 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 Links.

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.

Related Links:
Status:
RESOLVED FIXED

Description Joseph Hill 2012-05-15 11:06:49 UTC
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.)
Comment 1 Jonathan Pobst 2012-05-15 11:16:22 UTC
Visual Studio should already do both of these things.  Are you saying one of them is not working properly?
Comment 2 Joseph Hill 2012-05-15 12:06:22 UTC
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.
Comment 3 Jonathan Pobst 2012-05-15 12:16:41 UTC
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.)
Comment 4 Joseph Hill 2012-05-15 12:23:15 UTC
What would the implications be for building all libmonodroid architectures into the user apk for shared runtime builds?
Comment 5 Jonathan Pobst 2012-05-15 12:27:29 UTC
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.)
Comment 6 Joseph Hill 2012-05-15 13:19:08 UTC
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.
Comment 7 Jonathan Pryor 2012-05-21 22:30:06 UTC
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).
Comment 8 Joseph Hill 2012-05-22 10:20:16 UTC
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.
Comment 9 Jonathan Pobst 2012-05-25 16:04:45 UTC
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.
Comment 10 Jonathan Pobst 2012-05-29 18:00:51 UTC
Dunno why I didn't mark this as fixed.