-
Notifications
You must be signed in to change notification settings - Fork 2k
JNI Android Support on Unrooted devices #1164
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
JNI Android Support on Unrooted devices #1164
Conversation
|
Integrated Android support for device relisting xloem#3 |
|
I'm happy to have this replace #874 or merge and rebase it too, whatever works better for maintainers and contributors. |
|
@xloem I'm not sure but one option could be to force push this onto #874 then the conversation history is maintained while adding a cleaner set of commits? I would be happy to have this replace that pull also. Primarily its amazing work you have made and it needs to get merged as has significant value. Also, I would very much be in a position to aid/maintain for testing purposes. Current identified issues(s):
|
|
For people who are interested in better Android support, please come here and post your review or success/fail testing results. Thanks. |
780b024 to
77321cc
Compare
77321cc to
e6d0202
Compare
|
NOTE: |
|
Thanks for the rebasing work! For information, the maintainers typically rebase any PR locally when merging, regardless of Signed-Commits or not, so just ignore the GitHub warning about this (dunno how to turn it off). However, before this PR can be merged it should ideally be worked down to the smallest number of commits that makes sense, so e.g. without fixups commits. If there are multiple authors it can be correct to have their commits separated for credit attribution, but minor fixups of other people's commit can be amended in-place and commented in the commit message. |
- Fix `op_set_option()` Fix applying options to all new contexts
e6d0202 to
4c17b61
Compare
Need more reviews and tests. Another thing, as of now this PR has conflicts with the git repo which needs to be fixed. |
|
hello,I'm new here. Is there any Android demo using this branch? @CraigHutchinson @xloem |
|
Not entirely sure what sort of demo you mean. But the Libusb should work as per any other example as long as you provide the JNI for the context configurable iirc. |
|
@CraigHutchinson Thank you for your answer. I'm new to jni and I think need a sample program like this, where the author gets the file descriptor through usbmanager and passes it to jni, which works. Then I found your branch, and I was very interested in what you said about "to do the sdk calls within libusb itself." r = libusb_init(NULL); cnt = libusb_get_device_list(NULL, &devs); print_devs(devs); libusb_exit(NULL);
|
|
I only rebased @xloem work but yes that is looking nearly there. Check the original PR for details which is linked on this rebase key bit is this (which I hope you gathered)
I'm not at a PC nor working in this area for last year. As far as I recall the PR adds context options for setting these. It's upto your android code to choose where/how you get them but pass them in. |
|
@CraigHutchinson Thank you so much for your answer, I have read this today#874, hard for me to fully understand by now. But finally I found out that @xloem has added an example to his libusb-android codehere, the guy I mentioned last time also wrote ademo program for this example, just I didn't find and understand it yesterday. |
|
I am bringing this topic back to life because I am trying to implement something similar on an Android device but I cannot get it to work. But now I would like to access USB devices using a native C++ project. This project is using libusb to talk to USB devices. I tried to port the code from here. But I get the following errors in my logcat: It seems to be some kind of permission issue from SELinux, but not sure what I can do.... Can someone help? Many thanks in advance |
|
|
@xloem, thanks for your reply. Not sure about the dependencies I added at the end of it, theses were trials to solve the issue I am facing. The issue I get when fetching logs with logcat is that the app shuts down as soon as it starts with following error: The message seems to claim that we have to use FLAG_IMMUTABLE or FLAG_MUTABLE, but these are parameters to be set inside JAVA source code and this project only has a C++ file. Any idea on how to solve this? |
|
ok, so I was able to get one step further. I had to modify the source code of the updated libusb in into this: 33554432 is the value for FLAG_MUTABLE, see here: https://developer.android.com/reference/android/app/PendingIntent#FLAG_MUTABLE Now the problem I have is that the application does not do anything regarding USB devices. If my understanding is correct, when launching the app it should print a list of the USB devices connected but nothing happens. Here is the log, if it can help. any idea @xloem ? |
|
Does anybody have a working example using one of these pull requests? I imagine it would be for an older libusb and an older android sdk. If new to the code, it might probably make sense to forward-port something working one version at a time. I might have time to help iterate issues if tagged elsewhere (maybe drop a link here) to not clog this thread too much. I was excited to do the first coding for this work but am stuck on iOS myself right now. |
I had a working demo application that was connecting to AR glasses by libusb version from exactly this MR. This demo is an android application based on 'NativeActivity' with c++ code and CMake project. This is a link where I saved code changes and description about what were necessary to port the demo application. The description is not fully about libusb usage, though the libusb related parts still could be useful. As I see now, the important steps I did in the code were next:
libusb_context *ctx;
libusb_set_option(ctx, LIBUSB_OPTION_ANDROID_JAVAVM, app->activity->vm);
libusb_init(&ctx);
<uses-permission android:name="android.hardware.usb.host" />
find_package(Libusb1 REQUIRED MODULE)
target_include_directories(xrgears PUBLIC ${LIBUSB1_INCLUDE_DIRS})
target_link_libraries(xrgears ${LIBUSB1_LIBRARIES})Hope this information would be helpful. |
|
more than 3 years, the patch not able to work with |
|
Just wanted to drop by to say that I have used this successfully on Android, when targeting Android API 31. The only real "issue" is that it seems to be unable to compile for armeabi-v7a with the lowest Android API (16) due to the setup missing some timerfd functions, an error which does not happen when compiling regular libusb. Besides that, it really is as simple as giving the JavaVM pointer to libusb when you init the library. And then, it just works. |
|
我倒是有个其他方案,不使用jni反调安卓的方法。
|
|
Just wondering if you can update this PR to resolve the conflicts with master. Thanks. |
…TABLE when creating a PendingIntent - fixed the input flag to #FLAG_MUTABLE - for more information on this pull request, check here: libusb#1164
|
Hi all, Excellent work, we've used libusb as Android USB solution for years now, this could make it even easier! However, it seems that Android 15 breaks the whole game... It seems (from tests and e.g. Gemini) that it introduces stricter SELinux policies that disallow operations on the USB devices from Native libs. ONLY SDK (Java) transfers are allowed. Could somebody confirm this perhaps? |
I have an application (Kotlin (UI) -> golang (high-level driver) -> libusb) which works on my Pixel with Android 16. I open the usb handle through the Kontlin API, perhaps this makes the difference... |
I have an Android 15 phone, and this fork of libusb works on it. |
|
Thanks for confirming! Indeed, it was a USB hub issue, and Gemini was hallucinating the root cause... NICE! |
Rebase of work on #874:
This code implements connection and device listing on unrooted android devices, without requiring any user-provided java.
This PR is usable now 🎉
The java native interface library is used, which is always available when building on android, to do the sdk calls within libusb itself. The approach is modularised to aid expanding if new features are needed.
📓 Dispatching this request involves setting an action string on the intent for permission that the application can optionally subscribe to. The permission intent I dispatch has action string libusb.android.USB_PERMISSION.
The code only takes effect if the user provides their JNIEnv* or JavaVM* pointer via a new libusb option.