Android does not have udev; Do not link to udev on Android

[dgramop]

Android does not have udev; cross-compiling on a Linux host with udev results in a link to the same.

This patch refuses to enable udev if building for an android target.

[a1ien]

Hmm... Interesting.
It seems that this situation can only occur if you are building from a host with an AArch64 architecture or if you are building for x86 Android.
If you are building on an x86 host for Android ARM, pkg-config should not find libudev.

[dgramop]

Sounds right... Definitely an esoteric bug

[wuwbobo2021]

I wonder how you made rusb working on Android without adding Java code.

It seems like libusb's usage on Android is based on the file descriptor got from Android SDK Java API (NDK isn't a complete API of Android). https://github.com/libusb/libusb/blob/master/android/examples/unrooted_android.c

Reference: the cross-platform btleplug crate supports Bluetooth BLE operations on Android by bundling with some Java code.

Maybe a possible rust USB-CDC serial library for Android (which probably doesn't exist for now) will depend on this crate.

[dgramop]

• You're absolutely correct about passing down a file descriptor. All the permissions have to be banged out in Java/Kotlin land with the android SDKs. maybe there's some way through the NDK to do this, but getting the file descriptor does make sense to do up in UI land
• I am interested in a userspace Rust USB-CDC serial library and would happily contribute to one if this project is started. I needed one for a work project to hook up a UBLOX receiver to an Android phone, and had to use an android Kotlin userspace implementation. I did briefly try writing one myself but quickly pivoted, since there are so many different USB Serial dongles out there (with proprietary alternatives to CDC ACM), it wasn't worth my time at work just for that one project.

@wuwbobo2021 Are you interested in building such a library with me?

[wuwbobo2021]

Probably yes, because sooner or later I’ll make use of such a library: a device of my own is an USB CDC implementation, and currently the host program doesn’t support Android phones.

Will you publish the initial code in your repository? Or, should I write it from scratch?

[dgramop]

I had deleted the project since there was very little of value. Since I develop on MacOS, the method to detach the kernel driver didn't work out of the box. in order to test any implementation of userspace serial, we would have to detach the kernel driver. in any case, there is probably some command or MacOS-specific call to achieve this. I can create a repo and we can move discussion there (or I can email you)

@a1ien are there any changes you would like to request for this PR? I don't want to clutter your repository with too many unmerged PRs; I won't be offended if you decide to close this if you believe it is an unnecessary change.

[wuwbobo2021]

To compare the maximum speed of the OS’s CDC COM driver with operating with libusb, I’ve managed to communicate with the USB (full-speed) CDC device with rusb a few months ago. I tested it on Windows 10 and Ubuntu 22.04 successfully: The speed is a bit slower, though.

Last year, I had written my first Android application in Java communicating with a Bluetooth SPP device (ESP32 Wifi module of an Philips air conditioner, which didn’t function originally because of some problems of the vendor’s Internet server). I did it based on some leaked source code and a few open-source project about Hisense. (I didn’t make it open-source, but haven’t made a cent from it up to now). I got a pair of java.io.InputStream and java.io.OutputStream from the “Rfcomm socket” on bluetooth connection. I think it’s good to have Android SPP functions available as well in the new Rust library, because it’s not supported by btleplug.

[a1ien]

Hi. Sorry for delay. PR itself looks good. Thank you.

[wuwbobo2021]

@dgramop If there weren't any progress (I think you are busy) in your Android USB CDC project, I should create a simple wrapper (probably unoptimized) for myself in the next month.

[dgramop]

Ok so the big problem here (and the final reason I didn't get far on the first cut) was because I haven't actually been able to run real world tests "easily". Ideally I'd unload my USB serial kernel driver on MacOS so I can iterate directly on my MacBook instead of having some huge pile of hardware to lug with me to every coffee shop.

If I can't figure out a solution on my existing setup, I dig up an old laptop