4

我修改libusb1.0打开函数如下：

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 errno 9

翻译为“错误的文件号”。我从 Java 得到的文件描述符是一个正整数！

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

我不需要独立于平台，所以任何黑客都可以完成这项工作:)

任何想法将不胜感激！

附加信息！我从lsof得到的输出是（缩短以强调其中最有趣的部分）

my.activity 13374     u0_a62  exe       ???                ???       ???        ??? /system/bin/app_process
my.activity 13374     u0_a62    0       ???                ???       ???        ??? /dev/null
my.activity 13374     u0_a62    1       ???                ???       ???        ??? /dev/null
my.activity 13374     u0_a62    2       ???                ???       ???        ??? /dev/null
my.activity 13374     u0_a62    3       ???                ???       ???        ??? /dev/log/main
my.activity 13374     u0_a62    4       ???                ???       ???        ??? /dev/log/radio
my.activity 13374     u0_a62    5       ???                ???       ???        ??? /dev/log/events
my.activity 13374     u0_a62    6       ???                ???       ???        ??? /dev/log/system
my.activity 13374     u0_a62    7       ???                ???       ???        ??? /system/framework/core.jar
my.activity 13374     u0_a62    8       ???                ???       ???        ??? /system/framework/core-junit.jar
my.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_exe
my_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/main
my_exe   13546     u0_a62    4       ???                ???       ???        ??? /dev/log/radio
my_exe   13546     u0_a62    5       ???                ???       ???        ??? /dev/log/events
my_exe   13546     u0_a62    6       ???                ???       ???        ??? /dev/log/system
my_exe   13546     u0_a62    9       ???                ???       ???        ??? /dev/__properties__ (deleted)
my_exe   13546     u0_a62  mem       ???              b3:09         0     302530 /data/data/my.activity/files/my_exe
my_exe   13546     u0_a62  mem       ???              b3:09     36864     302530 /data/data/my.activity/files/my_exe
my_exe   13546     u0_a62  mem       ???              b3:09     40960     302530 /data/data/my.activity/files/my_exe
my_exe   13546     u0_a62  mem       ???              b3:03         0        200 /system/bin/linker
my_exe   13546     u0_a62  mem       ???              b3:03     57344        200 /system/bin/linker
my_exe   13546     u0_a62  mem       ???              b3:03     61440        200 /system/bin/linker

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

4

2 回答 2

7

原来，文件描述符没有被进程继承。如果使用 JNI 一切都应该没问题，但如果您想与第三方应用程序交互，则需要将文件描述符传输到第三方应用程序。

我的解决方案是使用 UNIX 套接字通过 JNI 传输 fd，它成功了！

附言

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

于 2013-01-04T20:34:58.370 回答
0

文件句柄是进程私有的。保证将它们按原样传递给不同的进程不会在任何风格的 *nix 上工作。

Android 的 Binder/Parcel IPC 接口可以编组文件描述符。

或者您可以继承句柄 - 如果在生成进程时它已经打开，则句柄在生成的进程中也将有效。

于 2013-01-04T03:44:32.573 回答