Android support

[MyelinsheathXD]

Hello everybody!
Is there any future plans to support android support for mujoco engine?
I have tried locally, yet stuck at c++ native function “qsortr “array sorting function conversion.
It seems android do not have native c++ library function for “qsortr” function.

[yuvaltassa]

Ah this is interesting. There are other reasons to stop using these library sorting functions, so it's good you brought this up.

That said, I'm very surprised this basic function is unavailable. Surely you can find a relevant discussion on stackexchange or similar?

[yuvaltassa]

Actually hold on, are you trying to run the compiler or just the engine? I don't think the engine calls this function.

[MyelinsheathXD]

I was trying to compile the engine as dynamic library using Android Studio's Cmake .
So far I have successfully port all 3rd party libraries(qhulstatic_r, ccd,tinyxml2,tinyobjectloader,pngloader) into static android library(.a).
Yet, the qsort funtion from macro mjQUICKSORT and other bugs were stopping me to build the engine for android.
Thank you clarifiing the this bug. it seems very few engine functions use this function.
I will update if solution for for this bug solves the main build issue.

[jaraujo98]

@MyelinsheathXD @yuvaltassa @Balint-H I was able to compile MuJoCo for Android. From my research, qsort_r is a non-standard function so it is up to the standard library implementation to provide it (which the Android developers do not do). I borrowed the implementation from GNU (LGPL 2.1 or later), fixed an extra preprocessor directive, provided the appropriate arguments to CMake, and from there it was smooth sailing to having a Unity app running MuJoCo natively on Quest 2. I'm happy to contribute the fixes and the documentation, but I wanted to hear your thoughts on my approach before doing so.

[jaraujo98]

No changes to the Unity plugin (thankfully...!). Just move the new so library file to the plugin folder after import, rename it from libmujoco.so to mujoco.so, and use the editor to specify that it was for Android. This even allows it to coexist with the Mac dylib file (which I also marked as Mac only), so I get to test on my Mac using native binaries, and deploy to Android using native binaries. Hard to beat! :-D

It would require a separate Android library file to be released, but that is easy to do (I have a build script I can share). The only pain point I see is that the Android API, architecture, and ABI are locked at compile time, and I can't tell what are sensible defaults (besides the ones I used for the Quest 2 build).

[yuvaltassa]

This sounds great but to clarify, are these just changes to the cmake, or do you propose to add this function to the codebase? We cannot redistribute LGPL code.

[jaraujo98]

The function needs to be added to the code base. On the other hand, it should be somewhat straightforward to write a wrapper around the normal qsort function (which should be available on all platforms as it is part of the standard) that does away with qsort_r and qsort_s (unfortunately I don't have the bandwidth to help with this right now). Or, if you have a plan to replace library sorting functions, implementing it should also solve it.

[yuvaltassa]

I think the right thing is to write a C wrapper with the same API for std::sort since qsort is not thread safe (which is why qsort_r exists). Would that approach work for you?

[jaraujo98]

I think I understand the general idea of your approach, and I agree with it. However, I'm not sure if I would be able to implement it without either re-implementing qsort_r from scratch, or using a custom struct to pass the elements together with the context to the comparison function so that it becomes compatible with qsort and sidesteps the thread safety issue (which I'm afraid I do not fully understand). How were you thinking of going about it?

Either way, the only thing preventing MuJoCo from running natively on Android is an implementation of quicksortfunc and mjQUICKSORT that does not depend on qsort_r, but as I mentioned previously I currently lack the time to help with this...

[thowell]

mjQUICKSORT now wraps std::sort when compiling MuJoCo as C++ code. Please see engine_sort.h.

[kbayes]

There's now a native sorting function that replaces qsort_r and std::sort. This should give a nice performance improvement as well.