Non-root android support #1150
Non-root android support #1150
Conversation
|
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 My other thought is about the use of 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 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? |
|
yes, it was pulled yesterday a few hours before the PR |
|
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 |
|
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 |
|
Hi, |
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! |
There was a problem hiding this comment.
This generally looks good to me, thanks!
I haven't tested on Android, but I tried it out on Linux with a quick patch to hackrf_transfer:
$ git diff
diff --git a/host/hackrf-tools/src/hackrf_transfer.c b/host/hackrf-tools/src/hackrf_transfer.c
index a2ad9ccc..d6261295 100644
--- a/host/hackrf-tools/src/hackrf_transfer.c
+++ b/host/hackrf-tools/src/hackrf_transfer.c
@@ -1123,7 +1123,8 @@ int main(int argc, char** argv)
return EXIT_FAILURE;
}
- result = hackrf_open_by_serial(serial_number, &device);
+ int fd = open(serial_number, 'r');
+ result = hackrf_open_by_fd(fd, &device);
if (result != HACKRF_SUCCESS) {
fprintf(stderr,
"hackrf_open() failed: %s (%d)\n",
$ hackrf-tools/src/hackrf_transfer -r /dev/null -d /dev/bus/usb/003/010
call hackrf_set_sample_rate(10000000 Hz/10.000 MHz)
call hackrf_set_hw_sync_mode(0)
call hackrf_set_freq(900000000 Hz/900.000 MHz)
Stop with Ctrl-C
^CCaught signal 2
17.3 MiB / 0.875 sec = 19.8 MiB/second, average power -32.5 dBfs
Exiting...
Total time: 0.87522 s
hackrf_stop_rx() done
hackrf_close() done
hackrf_exit() done
fclose() done
exit
I've added some comments for minor changes inline.
Also, the bugfix commits should be squashed down into a set of descriptive commits and any clang-format issues should be fixed before merging. I've done that here if you want to use that: https://github.com/miek/hackrf/commits/android
| @@ -754,6 +759,36 @@ int ADDCALL hackrf_open_by_serial( | |||
| return hackrf_open_setup(usb_device, device); | |||
| } | |||
|
|
|||
| int ADDCALL hackrf_open_by_fd( | |||
| int fd, | |||
There was a problem hiding this comment.
I think we should take intptr_t sys_dev here instead and pass it straight through to libusb. Looking back at at the PR for the libusb function (libusb/libusb#242 (comment)), they made that choice to make it more general across different platforms so I think we should do the same and leave it up to the user to do any platform-specific conversion/checking.
| return HACKRF_ERROR_INVALID_PARAM; | ||
| } | ||
|
|
||
| int err = libusb_wrap_sys_device(g_libusb_context, (intptr_t)fd, &usb_device); |
There was a problem hiding this comment.
This function was added fairly recently (in libusb 1.0.23) so I think we should add an ifdef on LIBUSB_API_VERSION and return unsupported otherwise, to allow for building with older versions.
|
@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. |
|
Hope you are doing ok! I'll watch out for an update. |
|
@AlexandreRouma Any plans to complete this? |
This PR contains the following modifications:
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.