It looks like I may be able to avoid the LD_LIBRARY_PATH workaround by explicitly loading ``` System.load(dlldir.toString() + get_so_dir(wine_abi) + "/ntdll.so"); System.load(dlldir.toString() + get_so_dir(wine_abi) + "/win32u.so"); System.load(dlldir.toString() + get_so_dir(wine_abi) + "/wineandroid.so"); ``` from Java first. That should let me reach the JNI_OnLoad of wineandroid.so without depending on linker search path hacks. From the JNI entry points, I should then be able to do a fork+execve of the normal wine/wine-preloader process, which would no longer be subject to the same seccomp issues. In that model, this would become a more standard Wine instance that talks to a server, similar in spirit to winex11 or winewayland, except that the server side would now live inside the activity process. Assuming this MR is accepted in principle, that is the direction I intend to continue exploring. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10569#note_135161