Closed leandroconsiglio closed 2 weeks ago
Thanks for your contribution, before I take a deeper look it would be a good idea to take the contents of this branch and either squash the commits or copy-paste contents into new commits a ~100 commits seems a bit excessive.
That said I'll give it a full review anyway so if there's anything that needs sorting out it can be done at the same time.
Yes, sorry, I realized after creating the PR. Would you prefer that I close this PR and create a new one with a single commit?
It doesn't need to be a single commit, but I'm currently looking through the changes and getting an idea what's going on.
I've got a couple of discussion points that I'd like your opinion on so I'd wait until then.
I've had a go at building the libraries using the NDK r26d and all seems to work, though I had to set ANDROID_NDK
and ANDROID_NDK_HOME
to get it to work properly.
I'll have a go at actually testing it on a device tomorrow sometime as I need to find a one that works. If you want the packages and don't want to wait you can merge this branch into yours and that should let you build all the packages without any failures/needing to reconfigure urls
I've had a go at taking the built binaries from your last successful build run and tried to parse a .torrent file but on an old samsung sm-t580 tablet running using var torrentClient = new TorrentClient()
would fail (the pointer returned would be negative) and trying to load the torrent file in by passing in raw bytes would completely crash the app and produce little debugging information to go off.
How did you test these libraries worked on a device and did you test the native files alone or with the C# library? It might be that one device is the culprit and to eliminate that I'll test it on a Nexus 5X tomorrow.
Sorry, I've had a busy few days. I have created a proof of concept in the following branch with an Android project. android_poc One important thing, I had to comment out the packagerefence to csdl.native in the csdl project because it conflicted with the Android project's lib folder. But when the binaries are in the new nuget package that problem should not occur I think.
Thanks for that, I've taken a quick look and will have a go at embedding a torrent file in the program and attempt to parse it within the app. It's most likely the device I'm using has some strange configuration (I've had issues with MAUI Blazor projects before with it) so will use the 5X as mentioned above.
One other thing that will need to be sorted with the android nuget project is how the libs are copied. It'll need to go in a format the same as the fork you linked with AndroidNativeLibrary
but don't worry about that (I'll do it once everything else is sorted)
You can also use an emulator. Regarding the nuget, when you place the binaries within the corresponding folders (android-x86, android-arm, etc.) inside "runtimes" it should automatically put the libraries as native. But it's something I haven't tried, I'm talking about assumptions.
You can also use an emulator
I want to use physical devices because emulating an x86_64 device and then deploying to find it doesn't work on any "real" device isn't something I want to deal with. I only have access to those two devices (and potentially a samsung phone).
The main reason I'm not going all in and fixing issues later is when support is added (via merging this) there will be an additional maintenance burden on a platform that I can't easily test, hence I want everything rock solid beforehand.
As for the platforms package, they probably do the same thing, I will double check that setting them as special compile-time types doesn't add any special targets to the built library and adjust as needed.
I have a question that I wanted to ask you, but it has nothing to do with Android support. I was reviewing the native code, especially the library.h and library.cpp files. Have you created them with any automated tool? Or you have created them manually? I would like to add other functions that libtorrent provides.
It's all written without any automated tooling.
As an update on my testing progress, I've had a go at merging my edits that fix some configuration-related issues but as a result of changing the alignment of all structs to 8 the x86 copy won't build (but the armv7 one does).
As i've now got some binaries, I'll take your test library and give it a go and get back to you soon.
I've tested on the Nexus 5X and it works. I've got a quick checklist of tasks that need to happen for merging (though this is for me and I'll finish the rest):
android
folder to csdl.Native
with the blank _._
file (to prevent android builds using linux libs then excluding them)csdl.Native.android
with the libraries copied into libs/x86_64
, libs/armeabi-v7a
, libs/arm64-v8a
I think the samsung tablet is armeabi-v7a and might be failing due to the pointer being negative (but still valid). I'll also give that another check and alter the managed-side as needed.
Everything looks fine!
(packages are now available via GitHub NuGet and actual NuGet)
Closes #2
Published Android native binaries to a new package
csdl.Native.android