hackrf
hackrf copied to clipboard
greatscottgadgets
Non-root android support
This PR contains the following modifications:
- Fixed the cmake to allow compilation with the Android NDK
- Disabled libusb enumeration when compiling on android since it is not supported (As explained in the libusb documentation line 92)
- Add the
hackrf_open_by_fdfunction that allows to open a hackrf device using a file descriptor. This is the only possible way to open a usb device on a non-rooted android device.
This code has been tested and confirmed working on my serveral android device but I still recommend testing it further.
It should not impact any other operating system.
Hi @AlexandreRouma, thanks for the PR!
The changes look straightforward, but as you may have seen there's a build failure on the CI - this is on Appveyor, which runs a Windows build. Since Windows doesn't provide an fd for USB devices I suggest we just wrap hackrf_open_by_fd with #ifndef _WIN32.
My other thought is about the use of LIBUSB_OPTION_NO_DEVICE_DISCOVERY due to discovery not currently working on Android. There's a libusb branch aiming to fix that problem which has been getting a lot of traction: https://github.com/libusb/libusb/pull/874, later updated at https://github.com/libusb/libusb/pull/1164. It would be good to avoid making changes in libhackrf that would prevent discovery from working if the libusb issue is fixed. Can we make this conditional somehow?
Finally, what is the Android app in your screenshot? Could you point us to some instructions for building this with libhackrf so that we can test it?
Hi,
I'll add the windows ifdef in a sec, didn't realize that libusb completely removes the function instead of simply returning LIBUSB_ERROR_NOSUPPORTED like basically all other functions. I should bring this up to the libusb team for more consistency.
The branches that aim to fix the enumeration support do exists but I have very high doubts that they will ever work. Still, it can indeed be made conditional.
The app in the screenshot is an android build of my SDR++ project. It is currently very hard to build for android and still a bit buggy (not the fault of libhackrf). So I don't think it's an ideal way to test libhackrf on android.
not exactly sure why the CI's complaining about code style when it perfectly matches the rest of the file
Did you start your work on this PR from the latest version in the repository?
Thank you for the update. I'll check this again next week when I'm back in the office (if no one else gets to you before then).
We have a clang-format config in the repository which is checked on the CI. If you have clang-format installed, you can run ./tools/reformat-source.sh to make the code match.
Do you have any recommended process for building and testing libhackrf on android? I've done a little work with the NDK and Android dev tools in the past but it was some years ago.
Building for the NDK is quite involved because the dependencies must be compiles as well, so, so I'd suggest following the scripts I wrote for my android-sdr-kit project that builds all of these libraries for android (or just run the container).
Then, to test, you need to write an NDK app and link as usual. All you have to do is, in the java part, enumerate devices and locate the hackrf using its vid/pid combo, then request permission, and when you've got permission, send the file descriptor android gives you. After using the new hackrf_open_by_fd function, you can use everything as normal.
Hi, Is there any update on this?
We've been very busy preparing for a release for Opera Cake support which will be out very soon. We will give this a proper review after the release and hope to incorporate it into the next release. Thank you for your patience!
@AlexandreRouma I'm checking in to see if you've seen the requested changes. Please let me know!
Hi,
Sorry, had some stuff come up IRL, didn't have as much time for coding and completely forgot about the PR. Will try to implement this weekend if I get the time.
