android – 修改libusb以接受文件描述符

概述我修改了libusb1.0的open函数如下： static int op_open2(struct libusb_device_handle *handle, int fd) { struct linux_device_handle_priv *hpriv = _device_handle_priv(handle); hpriv->fd = fd; return us 我修改了libusb1.0的open函数如下：

static int op_open2(struct libusb_device_handle *handle,int fd) {    struct linux_device_handle_priv *hpriv = _device_handle_priv(handle);    hpriv->fd = fd;    return usbi_add_pollfd(HANDLE_CTX(handle),hpriv->fd,PolLOUT);}

其中fd是通过android.hardware.usb.UsbDeviceConnection.html#getFileDescriptor()获得的

final UsbDeviceConnection connection = manager.openDevice(device); return connection.getfileDescriptor();

不幸的是,当我打电话时,我不断收到错误

static int op_claim_interface(struct libusb_device_handle *handle,int iface){    int fd = _device_handle_priv(handle)->fd;    int r = ioctl(fd,IOCTL_USBFS_CLaimINTF,&iface);    if (r) {        if (errno == ENOENT)            return liBUSB_ERROR_NOT_FOUND;        else if (errno == EBUSY)            return liBUSB_ERROR_BUSY;        else if (errno == ENODEV)            return liBUSB_ERROR_NO_DEVICE;        usbi_err(HANDLE_CTX(handle),"claim interface Failed,error %d errno %d",r,errno);        return liBUSB_ERROR_OTHER;    }    return 0;}

声明接口失败,错误-1错误9

被翻译为“Bad file number”.我从Java得到的文件描述符是一个正整数！

唯一的另一个小细节是我的本机代码作为一个单独的二进制文件运行,该二进制文件是用Java ProcessBuilder生成的.但是它们共享相同的uID,所以我认为我从Java获得的USB权限仍然适用于libusb.

我不需要独立于平台,所以任何黑客都可以做到这一点:)

任何想法将不胜感激！

附加信息！我从lsof得到的输出是(缩短为压力最有趣的部分)

my.activity 13374     u0_a62  exe       ???                ???       ???        ??? /system/bin/app_processmy.activity 13374     u0_a62    0       ???                ???       ???        ??? /dev/nullmy.activity 13374     u0_a62    1       ???                ???       ???        ??? /dev/nullmy.activity 13374     u0_a62    2       ???                ???       ???        ??? /dev/nullmy.activity 13374     u0_a62    3       ???                ???       ???        ??? /dev/log/mainmy.activity 13374     u0_a62    4       ???                ???       ???        ??? /dev/log/radiomy.activity 13374     u0_a62    5       ???                ???       ???        ??? /dev/log/eventsmy.activity 13374     u0_a62    6       ???                ???       ???        ??? /dev/log/systemmy.activity 13374     u0_a62    7       ???                ???       ???        ??? /system/framework/core.jarmy.activity 13374     u0_a62    8       ???                ???       ???        ??? /system/framework/core-junit.jarmy.activity 13374     u0_a62    9       ???                ???       ???        ??? /dev/__propertIEs__ (deleted)...my.activity 13374     u0_a62   44       ???                ???       ???        ??? /dev/bus/usb/002/002...    my.activity 13374     u0_a62   51       ???                ???       ???        ??? pipe:[51015]my.activity 13374     u0_a62   53       ???                ???       ???        ??? pipe:[51016]...my_exe   13546     u0_a62  exe       ???                ???       ???        ??? /data/data/my.activity/files/my_exemy_exe   13546     u0_a62    0       ???                ???       ???        ??? pipe:[51015]my_exe   13546     u0_a62    1       ???                ???       ???        ??? pipe:[51016]my_exe   13546     u0_a62    2       ???                ???       ???        ??? pipe:[51016]my_exe   13546     u0_a62    3       ???                ???       ???        ??? /dev/log/mainmy_exe   13546     u0_a62    4       ???                ???       ???        ??? /dev/log/radiomy_exe   13546     u0_a62    5       ???                ???       ???        ??? /dev/log/eventsmy_exe   13546     u0_a62    6       ???                ???       ???        ??? /dev/log/systemmy_exe   13546     u0_a62    9       ???                ???       ???        ??? /dev/__propertIEs__ (deleted)my_exe   13546     u0_a62  mem       ???              b3:09         0     302530 /data/data/my.activity/files/my_exemy_exe   13546     u0_a62  mem       ???              b3:09     36864     302530 /data/data/my.activity/files/my_exemy_exe   13546     u0_a62  mem       ???              b3:09     40960     302530 /data/data/my.activity/files/my_exemy_exe   13546     u0_a62  mem       ???              b3:03         0        200 /system/bin/linkermy_exe   13546     u0_a62  mem       ???              b3:03     57344        200 /system/bin/linkermy_exe   13546     u0_a62  mem       ???              b3:03     61440        200 /system/bin/linker

这让我觉得我传递给my_exe的文件描述符44实际上没有被继承！

解决方法 事实证明,文件描述符不是由进程继承的.如果使用JNI,一切都应该没问题,但是如果要与第三方应用程序连接,则需要将文件描述符传输到第三方应用程序.

我的解决方案是use UNIX sockets通过JNI传输fd并且它工作了！

附：

我在GNU许可证下发布了该项目 – https://github.com/martinmarinov/rtl_tcp_andro-

总结

以上是内存溢出为你收集整理的android – 修改libusb以接受文件描述符全部内容，希望文章能够帮你解决android – 修改libusb以接受文件描述符所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。