Изменить 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); 
} 

где FD был получен с помощью android.hardware.usb.UsbDeviceConnection.html#getFileDescriptor()

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

Unfortunatelly я получаю сообщение об ошибке, когда я называю

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

который переводится на «Bad file number». Дескриптор файла, который я получаю из Java, является положительным целым числом!

Единственная небольшая деталь - мой собственный код работает как отдельный двоичный файл, который генерируется с помощью Java ProcessBuilder. Но они имеют один и тот же uid, поэтому я предполагаю, что разрешения USB, которые у меня есть на Java, все равно должны применяться к 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, чтобы передать fd через JNI, и это сработало!

P.S.

Я выпустил проект по лицензии GNU - https://github.com/martinmarinov/rtl_tcp_andro-

Answer 2

Файловые дескрипторы являются частными для процесса. Передача их другому процессу как есть гарантируется, что он не работает ни на какой вкус * nix.

Интерфейс связующего/почтового ящика Android может содержать файловые дескрипторы.

Или вы можете иметь унаследованный дескриптор - если он уже открыт, когда процесс порожден, дескриптор будет действителен и в порожденном процессе.