Closed leandroconsiglio closed 2 hours ago
If libtorrent will build in android through vcpkg then I don't see why not, though as this was built primarily for a server environment I won't be working on it.
If you do decide to try this and manage to get everything to work I would be happy to merge a patch adding support.
I managed to create a x64 Android version and testing with a local emulator. Libtorrent alone is loading ok but loading csdl it's throwing "Java.Lang.UnsatisfiedLinkError: 'dlopen failed: library "libtorrent-rasterbar.so.2.0.so" not found".
In Android, the native libraries must ends with .so that's why it's not finding the library even though I have the library added.
So, my question is where its configured that the libtorrent should named libtorrent-rasterbar.so.2.0? It's possible to change that library link name based on OS build?
You could rename the libtorrent file and then relink csdl to use the newly named file but that's a lot of hassle and potentially unstable. Another approach is to disable including versioning info when building the library in the first place (I don't know how it's done in vcpkg but if I had to guess you need to pass some kind of flag to the build via the triplet)
Another solution which would be simpler is to statically link csdl.so against libtorrent, eliminating the issue entirely. It's only dynamically linked because I thought it would help Linux users "bring their own copy of libtorrent" but I found they're not compatible for some reason...
Well, static linking worked! I will continue with the tests for the rest of the android architectures and then I will make a PR when everything seems ok, so you can take a look.
I would also say that the only ABIs that really need to be supported are x86, armeabi-v7a and arm64-v8a as the others are either obsolete or can use other variants (that said arm64-v8a could be skipped unless performance is important).
Also, these would need to be published in a separate NuGet package called csdl.Native.Android
as I suspect these will be large files and should be an optional installation for users (if these are 50mb each, it adds 150mb to a platform-independent project).
Either way, it sounds promising and I look forward to seeing the result
The x64 binary is around 11mb and compressed 4mb. Although I am missing the other architectures, I don't think they weigh much more than that. However, it is totally valid that they go in a separate Nuget.
Is it possible to add compatibility with Android (armeabi-v7a, arm64-v8a, x86, x86_64)?