修改的libusb接受文件描述符

Question

我修改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); 
} 

其中經android.hardware.usb.UsbDeviceConnection.html#getFileDescriptor()

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

獲得當我打電話

可惜的是我一直收到錯誤的fd

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 

這讓我覺得，文件描述符44，我傳遞給my_exe實際上沒有繼承！

Answer 1

事實證明文件描述符沒有被進程繼承。如果使用JNI，一切都應該沒問題，但是如果你想與第三方應用程序接口，你需要將文件描述符傳送給第三方應用程序。

我的解決方案是通過use UNIX sockets通過JNI傳輸fd，它的工作原理！

P.S.

我發佈的項目下的GNU許可證 - https://github.com/martinmarinov/rtl_tcp_andro-

Answer 2

文件句柄對於進程是私有的。將它們傳遞給不同的進程是不會影響* nix的任何風格的。

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

或者您可以繼承該句柄 - 如果在進程生成時它已經打開，那麼該句柄也將在衍生進程中有效。