Debug deploy fails if EmbedAssembliesIntoApk=true and AndroidSupportedAbis does not include arm64-v8a

[gkarabin]

Android application type

Classic Xamarin.Android (MonoAndroid12.0, etc.)

Affected platform version

Visual Studio Enterprise 2022 for Mac Version 17.3.8 (build 5) AND Microsoft Visual Studio Enterprise 2022 (64-bit) - Current Version 17.3.6

Description

My team has sample apps for a SDK (set of nugets) for classic Xamarin.Android that we distribute that embed native libraries (.so files) for armeabi-v7a but not arm64-v8a, so we build them with armeabi-v7a;x86;x86_64. We do not include "arm64-v8a" in that set. The apps run on modern ARM64 Android devices just fine.

This combination has worked well in both VS for Windows and Mac 2019 when deploying to a debugger with "fast assembly deployment" disabled. With most versions of VS, fast assembly deployment works, but older versions had issues, so we began disabling fast assembly deployment in the sample apps, leaving it to people who use our nugets to do what they want in their customized apps.

In Visual Studio 2022 (latest releases for Windows and Mac) I see that these apps fail to deploy through the debugger with "fast assembly deployment" disabled. I can replicate this behavior with a simple Xamarin.Android template project where I disable fast assembly deployment and remove "arm64-v8a" from the AndroidSupportedAbis .csproj property.

P.S I could create tickets on developercommunity.visualstudio.com, but given that the issue appears on both Windows and Mac, I expect that tooling in Xamarin.Android is shared and it makes sense to go straight here .

Steps to Reproduce

1. Create a new app in VS for Mac: Android->App->General
2. Remove "arm64-v8a" from AndroidSupportedAbis in the .csproj.
3. See that the app deploys.
4. Disable "fast assembly deployment" (setting EmbedAssembliesIntoApk=true in the .csproj file).
5. See that the app does not deploy.

Did you find any workaround?

Enabling fast deployment is a workaround. But it would be nice to have two working ways to deploy, in case fast assembly deployment breaks.

Relevant log output

Application output window:

Forwarding debugger port 8862
Detecting existing process
> am start -a "android.intent.action.MAIN" -n "com.companyname.abideploytest/crc6478e4fb5c678bec2f.MainActivity"
> Starting: Intent { act=android.intent.action.MAIN cmp=com.companyname.abideploytest/crc6478e4fb5c678bec2f.MainActivity }

[Zygote] Unable to open libbeluga.so: dlopen failed: library "libbeluga.so" not found.
[e.abideploytes] Late-enabling -Xcheck:jni
[e.abideploytes] Unquickening 17 vdex files!
[e.abideploytes] Using default instruction set features for ARM CPU variant (cortex-a9) using conservative defaults
[Perf] Connecting to perf service.
[NetworkSecurityConfig] No Network Security Config specified, using platform default
[NetworkSecurityConfig] No Network Security Config specified, using platform default
[monodroid] Creating public update directory: `/data/user/0/com.companyname.abideploytest/files/.__override__`
[e.abideploytes] Attempt to remove non-JNI local reference, dumping thread
[monodroid-debug] Trying to initialize the debugger with options: --debugger-agent=transport=dt_socket,loglevel=0,address=127.0.0.1:8862,server=y,embedding=1
[monodroid-assembly] Failed to load managed assembly 'mscorlib.dll'. Internal error
[monodroid-assembly] open_from_bundles: failed to load assembly mscorlib.dll
[mono] The assembly mscorlib.dll was not found or could not be loaded.
[mono] It should have been installed in the `/Users/builder/jenkins/workspace/archive-mono/2020-02/android/release/sdks/out/android-armeabi-v7a-release/lib/mono/2.1/mscorlib.dll' directory.

[dellis1972]

@gkarabin

Out of interest what kind of device are you deploying too?

So the way this works is , with Fast Deployment on we ignore the AndroidSupportedAbis and look at the device which is being targeted. We then only include the assemblies for that device.

With Fast Deployment off, you end up with only the ABI's in the AndroidSupportedAbis list. So if you are deploying to a device which does support the abi's you have targeted at all then you should get a deployment error. Not a runtime one.
I tried to repo this using the steps outlined above and it works here some there must be some other different.

Here is the csproj https://gist.github.com/dellis1972/68d33b288753408970cffdda4e978a0e. Can you compare this with your example and see if you can spot the changes? Or upload the example. Also if you can let us know what device you are deploying too that would help us track this down too.

Hi @gkarabin. We have added the "need-info" label to this issue, which indicates that we have an open question for you before we can take further action. This issue will be closed automatically in 7 days if we do not hear back from you by then - please feel free to re-open it if you come back to this issue after that time.

[gkarabin]

Thanks, @dellis1972. I was using a Honeywell CT45. Dumping out some of the properties from the device's BuildInfo, I see:

Supported32BitAbis: [armeabi-v7a,armeabi], Supported64BitAbis: [arm64-v8a], SupportedAbis: [arm64-v8a,armeabi-v7a,armeabi]

Here is a diff using your example.csproj as the base, and the project I ended up with as the destination:
example-diff.txt. The only interesting differences that I notice are that I'm including x86 and x86_64 support. Removing that doesn't change behavior, though.

Here is the test app source that I'm using (a tiny git repo, shows the template-generated solution, followed by the edits):
abideploytest.zip