aspriddell / csdl

A server-focused libtorrent wrapper for C#
Other
2 stars 1 forks source link

Android support #2

Closed leandroconsiglio closed 2 hours ago

leandroconsiglio commented 1 week ago

Is it possible to add compatibility with Android (armeabi-v7a, arm64-v8a, x86, x86_64)?

aspriddell commented 1 week 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.

leandroconsiglio commented 1 week ago

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?

aspriddell commented 1 week ago

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...

leandroconsiglio commented 1 week ago

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.

aspriddell commented 1 week ago

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

leandroconsiglio commented 1 week ago

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.