4

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

これは「不正なファイル番号」に変換されます。Javaから取得したファイル記述子は正の整数です！

他の唯一の小さな詳細は、私のネイティブコードがJavaProcessBuilderで生成された別個のバイナリとして実行されることです。しかし、それらは同じ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を転送することでしたが、それは機能しました。

PS

GNUライセンスの下でプロジェクトをリリースしました-https://github.com/martinmarinov/rtl_tcp_andro-

于 2013-01-04T20:34:58.370 に答える
0

ファイルハンドルはプロセス専用です。それらをそのまま別のプロセスに渡すと、*nixのどのフレーバーでも機能しないことが保証されます。

Androidのバインダー/パーセルIPCイン​​ターフェースは、ファイル記述子をマーシャリングできます。

または、ハンドルを継承することもできます。プロセスが生成されたときにハンドルがすでに開いている場合、ハンドルは生成されたプロセスでも有効になります。

于 2013-01-04T03:44:32.573 に答える