Bug 58594 - Unchecking [x] Use Shared Runtime removes "Supported Arch"
Summary: Unchecking [x] Use Shared Runtime removes "Supported Arch"
Status: CONFIRMED
Alias: None
Product: Android
Classification: Xamarin
Component: MSBuild ()
Version: unspecified
Hardware: PC Windows
: --- enhancement
Target Milestone: ---
Assignee: dean.ellis
URL:
Depends on:
Blocks:
 
Reported: 2017-08-04 17:45 UTC by Ian
Modified: 2017-08-04 18:56 UTC (History)
2 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 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 original description:

  • Export the original title and description: Developer Community HTML or GitHub Markdown
  • Copy the title and description into the new report. Adjust them to be up-to-date if needed.
  • Add your new information.

In special cases on GitHub you might also want the comments: GitHub Markdown with public comments

Related Links:
Status:
CONFIRMED

Description Ian 2017-08-04 17:45:17 UTC
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 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
Comment 1 Jon Douglas [MSFT] 2017-08-04 17:53:50 UTC
(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
> 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

I believe this behavior is expected based on the following documentation:

https://developer.xamarin.com/guides/android/application_fundamentals/cpu_architectures/#How_to_Specify_Supported_Architectures

> 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.
Comment 2 Ian 2017-08-04 18:31:10 UTC
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.
Comment 3 Jon Douglas [MSFT] 2017-08-04 18:56:13 UTC
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

armeabi-v7a

and on an emulator would return

x86

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.e.
    <AndroidSupportedAbis>armeabi-v7a;x86</AndroidSupportedAbis>

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:

arm64-v8a,armeabi-v7a,armeabi

Running on Emulator:

x86

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.