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 for Bug 58594 on
Developer Community or GitHub if you have new
information to add and do not yet see a matching new report.
If the latest results still closely match this report, you can use the
In special cases on GitHub you might also want the comments:
GitHub Markdown with public comments
Open a new Android app
Go to Android Options for the project
Press ADVANCED and ensure 'all' Supported Arch is there
[ ] uncheck the Use Share Runtime
Press ADVANCED again. Poof! all Supported Arch but one is unchecked
This is a problem since UITest requires no Shared Runtime so when you uncheck it, you can no longer deploy to the fast Android emulator if it's x86.
If I simply recheck all the Supported Arch in the ADVANCED, I can use UITest as the app will deploy.,
But a tricky problem to find why I can't deploy when Use Shared Runtime is off. ugh
(In reply to Ian from comment #0)
> VS 2017
> Open a new Android app
> Go to Android Options for the project
> Press ADVANCED and ensure 'all' Supported Arch is there
> [ ] uncheck the Use Share Runtime
> Press ADVANCED again. Poof! all Supported Arch but one is unchecked
> This is a problem since UITest requires no Shared Runtime so when you
> uncheck it, you can no longer deploy to the fast Android emulator if it's
> If I simply recheck all the Supported Arch in the ADVANCED, I can use UITest
> as the app will deploy.,
> But a tricky problem to find why I can't deploy when Use Shared Runtime is
> off. ugh
I believe this behavior is expected based on the following documentation:
> When your app is configured for Debug, the Use Shared Runtime and Use Fast Deployment options are enabled, which disable explicit architecture selection.
(Because they are all selected and included)
This then goes into the same behavior as a RELEASE build:
> Xamarin.Android defaults to armeabi-v7a for Release builds.
Thus you should be able to turn on any other architectures you need at this point.
I'm not so sure this is a bug per-say. Can you elaborate on what you would propose a change would be?
Would you expect turning off shared runtime would result in keeping
all of the supported architectures? Typically this is not the expected behavior because that then bloats the binary for debugging purposes. Rather one should select by hand which architectures they need to support for their use-case.
The issue is that the defaulted architecture, when Shared is off, is not the Emulator's version when you set it to x86, a common choice for running in Windows, so UITesting fails. This will trip up many.
Perhaps what can be taken from this is a "sniffer" feature which will indicate what architectures you currently have attached to "adb".
An example might be:
adb shell getprop ro.product.cpu.abi
Which on a physical nexus 5 would return
and on an emulator would return
Thus if you had both of these devices attached to "adb", your project's supported architectures would be selected to both of these items. I believe this would be possible via a new MSBuild task that can be optionally added to a csproj. To be honest this wouldn't be that difficult to create yourself if you wanted to dive into custom msbuild tasks which would be:
1. Create a Task that returns the results of "adb shell getprop ro.product.cpu.abi" foreach device in "adb devices"
2. Update the <AndroidSupportedAbis> property with the respective values:
I believe there are some existing Xamarin.Android Tasks that do most of this work.
The issue I see is that there is nothing currently that will "know" what architecture you need to deploy to. Android developers use physical devices and emulators interchangeably. I believe another possible fix is to include x86 as a default so both the device and emulator is covered.
There is another property we could get which is the abi list to ensure it will run on that device and provide a warning if there's no abis selected.
adb shell getprop ro.product.cpu.abilist
EX: Running on Google Pixel:
Running on Emulator:
Thus I am marking this as "enhancement" and setting the status to "CONFIRMED" as improvement can happen in this area. Changing to "MSBuild" as "Designer" is not the proper location.