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 51422 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
By default, the only ABI set in release mode is armeabi-v7a
While this may be appropriate for devices (perhaps arm64 should be included also) this causes a deployment failure when deploying to the x86 emulator
I suggest that we either include the appropriate ABIs for emulator testing, or provide a more appropriate error message when the incorrect ABI is set for the chosen deployment target
Microsoft Visual Studio Enterprise 2017 RC
Version 15.0.26020.0 D15REL
Microsoft .NET Framework
Installed Version: Enterprise
Architecture Diagrams and Analysis Tools 00369-50000-00000-AA345
Microsoft Architecture Diagrams and Analysis Tools
Visual Basic 2017 RC 00369-50000-00000-AA345
Microsoft Visual Basic 2017 RC
Visual C# 2017 RC 00369-50000-00000-AA345
Microsoft Visual C# 2017 RC
Visual C++ 2017 RC 00369-50000-00000-AA345
Microsoft Visual C++ 2017 RC
Visual F# 4.1 00369-50000-00000-AA345
Microsoft Visual F# 4.1
Application Insights Tools for Visual Studio Package 8.4.01118.2
Application Insights Tools for Visual Studio
ASP.NET and Web Tools 2016 15.0.21206.0
ASP.NET and Web Tools 2016
Command Bus, Event Stream and Async Manager Merq
Provides ICommandBus, IEventStream and IAsyncManager MEF services for loosely coupled Visual Studio extension components communication and integration.
Common Azure Tools 1.8
Provides common services for use by Azure Mobile Services and Microsoft Azure Tools.
Microsoft Visual Studio VC Package 1.0
Microsoft Visual Studio VC Package
Mono Debugging for Visual Studio Mono.Debugging.VisualStudio
Support for debugging Mono processes with Visual Studio.
NuGet Package Manager 4.0.0
NuGet Package Manager in Visual Studio. For more information about NuGet, visit http://docs.nuget.org/.
TypeScript tools for Visual Studio
Visual Studio Tools for Universal Windows Apps 15.0.26009.00
The Visual Studio Tools for Universal Windows apps allow you to build a single universal app experience that can reach every device running Windows 10: phone, tablet, PC, and more. It includes the Microsoft Windows 10 Software Development Kit.
Xamarin 220.127.116.119 (7c3dcf2)
Visual Studio extension to enable development for Xamarin.iOS and Xamarin.Android.
Xamarin.Android 18.104.22.168 (72366f7)
Visual Studio extension to enable development for Xamarin.Android.
Xamarin.iOS 10.4.0.33 (d93ae7e)
Visual Studio extension to enable development for Xamarin.iOS.
This is now fixed in the property pages. All the ABIs are selected by default (and there are other options, like fastdev or not and such).
My bad. I checked debug. It makes sense that release will only be arm, though, but I'm reopening while we decide.
> By default, the only ABI set in release mode is armeabi-v7a
> While this may be appropriate for devices (perhaps arm64 should be included also)
> this causes a deployment failure when deploying to the x86 emulator.
We're trying to "thread" between two subjective requirements:
1. We don't want the default app size to be "too big", and
2. We want the default Release app to be "useful"
Each ABI requires 1.3-2MB in native libraries be added to the .apk, depending on whether `libmono-btls-shared.so` is required (required to support TLS 1.2 with WebRequest), so we want to choose only *one* ABI *by default*.
Additionally, we want the default Release .apk to be able to be meaningfully useful on the Google Play Store.
x86 would not be "meaningfully useful"; very few Android devices support x86.
The last time we updated the default, armeabi-v7a was the ABI that best fit these requirements: it is supported on a majority of Android devices, so making it the default single ABI made the most sense.
x86 doesn't make sense, and *still* doesn't make sense. If we were to update today, *arguably* arm64-v8a should be made the default, but I see no reason for x86 to be made the default.
If you need x86 support, enable x86 support in the Project Properties dialog.
> or provide a more appropriate error message when the incorrect ABI is
> set for the chosen deployment target
This is something we should do.