termux-usb -l now returns something like:

[
  {
    "device_name": "/dev/bus/usb/001/004",
    "device_id": 1004,
    "vendor_id": "0x0a12",
    "product_id": "0x0001",
    "device_class": "224 - Wireless controller device",
    "device_sub_class": 1,
    "manufacturer_name": null,
    "device_protocol": 1,
    "product_name": "CSR8510 A10",
    "serial_number": null,
    "configurations": 1,
    "descriptor_type": 0,
    "access_granted": false
  },
  {
    "device_name": "/dev/bus/usb/001/003",
    "device_id": 1003,
    "vendor_id": "0x0bda",
    "product_id": "0x8153",
    "device_class": "0 - Usb class is determined on a per-interface basis",
    "device_sub_class": 0,
    "manufacturer_name": "Realtek",
    "device_protocol": 0,
    "product_name": "USB 10/100/1000 LAN",
    "serial_number": "000000100000",
    "configurations": 2,
    "descriptor_type": 0,
    "access_granted": false
  }
]

So we can either pass `--es device /dev/bus/usb/001/003`, or `--es
vendorId 0x0403 --es productId 0x6001`. `--es device` is used if all
three are passed.

And ensure they are not empty.

Apparently some devices have fixed length fields, with extra nulls at
the end. This makes parsing the output slightly more annoying in
termux so strip them on the java side.

Before termux-usb -l could return something like:

[
  {
    "device_name": "/dev/bus/usb/002/006",
    "device_id": 2006,
    "vendor_id": "0x316d",
    "product_id": "0x4c4b",
    "device_class": "0 - Usb class is determined on a per-interface basis",
    "device_subclass": 0,
    "manufacturer_name": "Purism, SPC\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000",
    "device_protocol": 0,
    "product_name": "Librem Key\u0000\u0000\u0000\u0000\u0000\u0000\u0000",
    "serial_number": "00000000000000000000D6G9",
    "configurations": 1,
    "descriptor_type": 0,
    "access_granted": false
  }
]

and now we remove all \u0000.

The information received from android's usbmanager is returned to
termux's userspace as a serialised protobuf message, giving something
that is quite easy to parse and extend.

The returned info is loosely modelled after libusb's internal struct
libusb_device, and userspace programs can parse the info as a
replacement for libusb_get_device_list and
libusb_get_device_descriptor.

A config descriptor can contain several interfaces, and each interface
can in turn contain several endpoints, so building and parsing the
messages is a bit complicated.