6

Aren't there any system calls or OS specific functions that can be called by Java to get just the names of the USB devices attached?

I've seen probably 6-7 questions here only, but everyone mentions the C++ functions GetRawInputDeviceList() etc, and they are not cross-platform compliant. Either for Windows in C# or C++ or for Linux only.

But I'm working in Java. Also, this needs to be cross platform. Atleast, it needs to be working for Windows,Linux and Mac. I can work with terminal/shell/command-prompt commands also. I guess I can run them with Java.

I've tried getFileSystemView and listRoots. But they give out names of all drives [dvd, hdd partitions,floppy etc].

I need to get only USB devices.

Please don't mention jUSB or JSR080. Why:

jUSB: access to USB devices currently requires that they be connected to a GNU/Linux host system

javax.usb: pre-alpha Windows implementation is not certified and requires a kernel driver.

usb4java: basically, it just implements JSR80 with little more abstraction, perhaps

Although to be honest I haven't tried libusb since it is in C++.

If you are going to mention APIs, mention completely tested and tried ones, that work across Linux,Windows and Mac. If that wasn't the case, I wouldn't have put this question up. I've seen the mention of jUSB, javax.usb, etc on many other posts.

bad_keypoints
  • 1,382
  • 2
  • 23
  • 45
  • 1
    does it suit http://www.ibm.com/developerworks/library/j-usb/index.html? – user1516873 Dec 24 '12 at 08:02
  • have you tried it yourself? cross-platform ever? if you guys are pressing so hard, heck i'll try it by today then. – bad_keypoints Dec 24 '12 at 12:15
  • Just to clarify one thing: javax.usb (JSR80) is just a standard API (Like the Servlet API which is implemented by Tomcat). usb4java has nothing to do with the very very old reference implementation you mentioned as the "pre-alpha Windows implementation". usb4java just implements the javax.usb API and uses libusb as backend. But it isn't interesting for you anyway because even without Java the libusb library can't give you the USB device names because on Windows it also needs a special driver for all devices you want to communicate with. – kayahr May 07 '13 at 21:30

3 Answers3

4

You can use the jUsb API, for Linux.

Or you could launch the terminal in Linux using the Process class, and run ls -la /dev/disk/by-id/usb-* and catch the stdout to know the results.

For Windows, you can try this : How to find my USB flash drive's path with PowerShell

EDIT:

For Windows, another helpful utility is the devcon.exe.

For more info, check this.

EDIT 2: For Mac, you could launch the terminal using the Process class, and run system_profiler SPUSBDataType

Community
  • 1
  • 1
Kazekage Gaara
  • 14,972
  • 14
  • 61
  • 108
2

Yoy can try javahidapi. I think it some c/c++ code and JNI. Declarated linux, mac and windows support. I have tried it with linux (ok), with clean windows in virtual box (not ok, UnsatisfiedLinkError, i think some MSVS libs was missed). If you'll compile it from source, it should work, i belive.

here is example:

import com.codeminders.hidapi.HIDDeviceInfo;
import com.codeminders.hidapi.HIDManager;

public class TestHid {

    public static void main(String[] args) throws Exception {
        try {
            com.codeminders.hidapi.ClassPathLibraryLoader.loadNativeHIDLibrary();
            HIDManager hidManager = HIDManager.getInstance();
            HIDDeviceInfo[] infos = hidManager.listDevices();
            for (HIDDeviceInfo info : infos) {
                System.out.println("info: " + info.toString());
            }
        } catch (Exception ex) {
            ex.printStackTrace();
        }
    }
}

EDIT output shows only one plugged in usb device, genius laser mouse.

[grigory@gr testRSA]$ pwd
/home/grigory/testRSA/out/production/testRSA
[grigory@gr testRSA]$ whoami 
grigory
[grigory@gr testRSA]$ java -cp ".:hidapi-1.1.jar" Test
libusb couldn't open USB device /dev/bus/usb/003/002: Permission denied.
libusb requires write access to USB device nodes.
info:HIDDeviceInfo [path=0003:0002:00, vendor_id=1112, product_id=58, serial_number=null, release_number=0, manufacturer_string=null, product_string=null, usage_page=0, usage=0, interface_number=0]
[grigory@gr testRSA]$ sudo java -cp ".:hidapi-1.1.jar" Test
[sudo] password for grigory: 
info:HIDDeviceInfo [path=0003:0002:00, vendor_id=1112, product_id=58, serial_number=null, release_number=0, manufacturer_string=Genius, product_string=Laser Mouse, usage_page=0, usage=0, interface_number=0]
[grigory@gr testRSA]$

and for fresh Windows XP it isn't work (only one windows i can find. I haven't Visual Studio for compile lib from source):

E:\testRSA\out\production\testRSA>java -cp ".;hidapi-1.1.jar" -Djava.library.pat
h="e:\testRSA\out\production\testRSA" Test
Exception in thread "main" java.lang.UnsatisfiedLinkError: com.codeminders.hidap
i.HIDManager.init()V
        at com.codeminders.hidapi.HIDManager.init(Native Method)
        at com.codeminders.hidapi.HIDManager.<init>(HIDManager.java:53)
        at com.codeminders.hidapi.HIDManager.getInstance(HIDManager.java:121)
        at Test.main(Test.java:14)
user1516873
  • 5,060
  • 2
  • 37
  • 56
0

Maybe things have improved since you first asked this question. I recently began exploring usb4java on the Mac, and it seems to work. There is example code available, both for the low-level (libusb-like) API, and the high-level (javax) API.

To list all USB-devices, look the examples.

I downloaded all libraries directly from usb4java.org and the examples from github. I did not manage to get the maven build working, but I could import the libraries and examples in Eclipse and run them all.

There are same native code included in usb4java, but the library wraps them all quite beautifully and hides all the messy details, only extracting and deploying the native code at demand.

lenborje
  • 181
  • 1
  • 4
  • In my own explorations, I found my Mac automatically claimed the device I was trying to communicate with. Luckily, I found solution [here](http://www.proxmark.org/forum/viewtopic.php?id=986). Basically, you create a "dummy driver" as a text plist file, which prevents OSX from assigning its own driver at boot. – lenborje May 05 '14 at 10:04