Skip to content
This repository has been archived by the owner on Mar 11, 2021. It is now read-only.

Missing library and crash when using 64-bit architecture. #424

Open
ShICO opened this issue May 28, 2019 · 2 comments
Open

Missing library and crash when using 64-bit architecture. #424

ShICO opened this issue May 28, 2019 · 2 comments

Comments

@ShICO
Copy link

ShICO commented May 28, 2019

I am using Xamarin Android with Cocossharp with Visual Studio 2017(15.9.12) on Windows 10.

When building the project with 64-bit architecture (arm64-v8a, x86_64) and run on devices with 64-bit Android OS, sounds(sfx) do not play and the application crashes after a while.

The debug log shows that OpenAL library(libopenal32.dll) for 64-bit architecture is missing. Debug log file is attached.
debug_log.txt

When built into release apk with 64-bit architecture (arm64-v8a, x86_64), apk's sturcture shows that the library is missing from 64-bit lib path. Images showing lib folder's contents between 32-bit(armeabi-v7a, x86) and 64-bit(arm64-v8a, x86_64) are attached.
32bit
64 bit

This is a serious issue since Google Play Store will stop accepting release without 64-bit support on Aug-1-2019 and with this issue, 64-bit support cannot be added to release file.

@bramborman
Copy link

We had the exact same issue with our project. We found a workaround I believe on some forum (would link, but don't know the exact location):

  1. Download the lib for your required ABIs from the MonoGame/MonoGame.Dependencies repo.

  2. Add them to your project to folder lib to folders named by the particular ABI.

Image 1

  1. Set the Build Action of those downloaded libs to AndroidNativeLibrary.

Image 2

  1. It should work now, if it doesn't, try cleaning and rebuilding the solution or if even that doesn't help, close VS, delete bin and obj folders and try rebuilding again in VS.

Hope this helps, good luck!

@ShICO
Copy link
Author

ShICO commented Aug 8, 2019

@bramborman
Thank you very much for sharing.
Your method was exactly what we ended up doing as a workaround for the problem after posting the issue here.
It seemed to be working ok.
But since we did not have the time to test it thoroughly, we did not post the method here.
We are still hoping to get an answer from the dev team.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants