Forum Xamarin.Forms

Strange behavior on Android with native libs and .Net Standard

Hello everyone,

I have a strange behavior in my Xamarin.Forms app on Android.
Some months ago, I created an app with Xamarin.Forms and added an Android-Binding project to this solution. Besides the jar files, this binding project includes some native libraries for armeabi-v7a (only for this). The classes from this binding project are used from the Xamarin.Forms assembly using an interface and dependency-services. Everything is working fine this way.

For some external reasons I now need to create a new app, that uses (nearly) the same jars, native libs and so on. So, I created a new app (with a new solution) using the .Net Standard 2.0 Template. (the before mentioned app used the “old” PCL). I added a new binding project and copied the files from the “old” app, first without any adjustments.

At the moment I have nearly the same app (files, settings, …) only this time using .Net Standard 2.0.
Now, when I start the app, it throws an error the first time it tries to access one of the native libs, saying, that this lib is not found. After some tests, I discovered that the app is searching for native libs for arm64-v8a. So the app is right, there are no such files, but why is this app searching for arm64, when the other (old) app is searching for armeabi. When I change the supported architectures to only support armeabi-v7a, the app doesn’t even start. In Logcat I’m getting a “shared runtime error” saying:

shared runtime initialization error: dlopen failed: "/data/app/Mono.Android.DebugRuntime-1/lib/arm64/" is 64-bit instead of 32-bit

I tried to remove and reinstall the shared runtime app, but with no success.
The only thing working is to uncheck the “Use Shared Runtime” option in the android options. With this, the app is working as expected, but I would like to use shared runtime

Is there anything I’m doing wrong? Is there an option to choose between 32 and 64 bit? (the “normal” Platform target in Build settings doesn’t seem to have any effect)
As far as I can see the only difference between these two apps are the used project templates (the old PCL vs. .Net Standard 2.0)

Any help would be appreciated.

Best regards


  • ShantimohanElchuriShantimohanElchuri USMember ✭✭✭✭✭

    @DannyKnoch Try adding the NuGet package Microsoft.NETCore.Portable.Compatibility to your .NetStandard project.

  • DannyKnochDannyKnoch USMember ✭✭

    Hello ShantimohanElchuri,
    thank you, for your reply. Unfortunatly this doesn't work.

    I also think it is not caused by NetStandard itself. Without "shared runtime" the app runs fine, just having perfomance issues with deploying and debugging.

    I thought more of something like the NetStandard is setting some (hidden?) options to use 64 bit instead of 32 bit. This wouldn't be bad at all, unless you have to use a 32 bit only native lib.

    Has someone seen something like this before?

Sign In or Register to comment.