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 on
Developer Community or GitHub with
your current version information, steps to reproduce, and relevant error
messages or log files if you are hitting an issue that looks similar to
this resolved bug and you do not yet see a matching new report.
Reported on behalf of a user.
## Steps to reproduce
1. Open attached test case.
2. Build the "M2.Mobile.Android" project, and run it on an armeabi-v7a device or emulator.
3. Push the "Entrar" button.
The application throws an error:
Couldn't load clisitef32 from loader dalvik.system.PathClassLoader[DexPathList[[zip file "/data/app/M2.Mobile.Android-1.apk"],nativeLibraryDirectories=[/data/app-lib/M2.Mobile.Android-1, /system/lib]]]: findLibrary returned null
Running `unzip -l M2.Mobile.Android.apk` shows that the library is present in the APK:
... but running `adb shell ls /data/app-lib/M2.Mobile.Android-1` shows only the mono libraries:
1. Disable "Use shared Mono runtime" in "Project Options -> Android Build -> Packaging".
2. Select "armeabi" under "Project Options -> Android Build -> Advanced".
3. Build and run the "M2.Mobile.Android" project.
## Additional information
- Deploying to an armeabi emulator appears to work correctly even when "Use shared Mono runtime" and "Fast assembly deployment" are both enabled.
- With "Fast assembly deployment" disabled and "Use shared Mono runtime" enabled, `libclisitef32.so` installs correctly, but not `libjCliSiTefI.so`. Interestingly, if you rename `libjCliSiTefI.so` (for example to `libjclisitef.so`), the library *does* get installed into `/data/app-lib/M2.Mobile.Android-1/`. If you then rename the library on-device back to `libjCliSiTefI.so` using `adb shell mv`, the application runs without error.
- After nulling-out the .so files, the installation behavior appears to stay the same. So the problem does not seem to depend on the contents of the native libraries.
- Moving the .so files out of the binding project and into the "M2.Mobile.Android" project does not change the installation behavior either.
## Version information
This is an unfortunate Android design decision. Some (slightly outdated) information is at:
The problem is that on a number of Android versions, if your .apk contains _both_ armeabi and armeabi-v7a libraries, _only_ the armeabi-v7a libraries will be extracted onto armeabi-v7a targets.
Furthermore, since Mono for Android 4.4 a libmonodroid.so has been provided in Debug builds, by default, for armeabi, armeabi-v7a, and x86 architectures, and since Xamarin.Android 4.6 the default architecture for Release builds has been armeabi-v7a.
Your project only includes armeabi libraries.
Consequently, on many (most) Android versions, _only_ the armeabi-v7a libraries will be installed, and the armeabi libraries will be IGNORED.
This in turn will result in runtime errors when attempting to load the native library which doesn't exist.
The "fix" is to provide copies of your native libraries for each ABI that you need to support, and you'll need to support _at least_ armeabi-v7a. Your project is only including armeabi.
You can do this via one of three ways:
1. Copy the lib\armeabi\lib*.so into lib\armeabi-v7a\lib*.so, and set the Build action accordingly (EmbeddedNativeLibrary for binding projects, AndroidNativeLibrary for app projects).
2. Use MSBuild properties to add it as an alias, e.g.
3. Set the <Abi/> nested element on <AndroidNativeLibrary/>:
Note: I don't know if the nested <Abi/> element works for <EmbeddedNativeLibrary/>.
Just complementing Jonathan Pryor message. There is a bug report about this issue that can be tracked: