I was able to build a Pulse.abb file
I did not split out the apk file and run it on Nox or anything
But I believe I was able to build in 2019.4.5f1 LTS
As far as I know, the abb file is built and then Unity will generate a temporary apk file. The problem is not that I cannot create the file, the project actually runs and shows the vitals monitor in the device. However, it does not simulate anything and the numbers/waves don’t change as it cannot find PulseC (That’s when the error shows up)
The app does not crash or anything, Unity shows the assets as if they were not connected to Pulse, the simulation part just doesn’t work
I pushed up new Android-ARM and Android-ARM64 PulseC.so files in the respective 3.0.2 folders
https://data.kitware.com/#collection/59849c788d777f7d33e9c084/folder/5da739b0d35580e6dc9e9c79
These are built against the latest NDK (21d)
This is amazing! Will try this right away!
I really don’t know what I’m doing wrong. It does not work
It’s not you Degly, It’s me
Yeah, I am just as confused as you are
I am going to look into the latest magic leap cross compilation process
Since we had luck with that last library, hopefully this will also work and we will understand the process a little better and see if we can’t figure out a more generic docker based solution for future distribution
I have also been trying to figure this out and I can’t make it work either, the .so is being included and the dll reference is done correctly.
I did test using a different plugin that I knew worked just fine on Android. And I put the .so on my project but selected a different architecture (the .so was for ARM64 but I selected ARM7). The result on runtime was the “dll not found”, which can confirm the theory that the problem we are having is that the .so is for a different architecture and that’s why we can’t make it work on Android. The architecture we need is armeabi-v7a.
Yeah, I am sure its probably going to come down to proper configuration of the NDK
I just need to go through all the documentation to figure out what I need to set to get the armeabi-v7a architecture as my target
But abray, we can fix this
I am also looking into how the .so file is loaded by Unity and which scripting back-end I should use. Anything I can help, let me know.
Also vascoptorres, I have tried with the different architectures and even different devices, even changing the scripting back-end but nothing seems to work just yet. If you want to try it by yourself, you can find the .so files we used in
https://data.kitware.com/#collection/59849c788d777f7d33e9c084/folder/5da739b0d35580e6dc9e9c79
Let us know if you find something we haven’t!
Do you think this could help?
There they explain how to target armeabi-v7a
That makes me wonder though, do we have to do the same thing for ARM64 devices?
I am sure I will need to build at least two different PulseC.so files for android support, the v7 (which I believe is 32bit) and the v8 (which is x64 bit)
Yes, I believe so too
And of course the NDK has some very similar instructions for cross compiling
https://developer.android.com/studio/projects/configure-cmake
So is it
DCMAKE_ANDROID_ARCH_ABI // armeabi-v7a
or
-DANDROID_ABI=ABI // For example, arm64-v8a
I am going to roll the dice with : -DANDROID_ABI=armeabi-v7a
Well
https://cmake.org/cmake/help/latest/variable/CMAKE_ANDROID_ARCH_ABI.html
Ok, giving it a whirl…
Ok,
Here is the next iteration for arm v7a (I am just replacing the PulseC.so file until we get one that works…)
https://data.kitware.com/#collection/59849c788d777f7d33e9c084/folder/5f1971aa9014a6d84e34cd44
I will test it right away and tell you if it works!
Bangs head on table
Same.
I will try with another device and a different scripting backend as the error message is different.