Results
Loading...
| java.lang.Object | |
| ↳ | android.hardware.usb.UsbRequest |
A class representing USB request packet.
This can be used for both reading and writing data to or from a
UsbDeviceConnection.
UsbRequests can be used to transfer data on bulk and interrupt endpoints.
Requests on bulk endpoints can be sent synchronously via bulkTransfer(UsbEndpoint, byte[], int, int)
or asynchronously via queue(ByteBuffer, int) and requestWait().
Requests on interrupt endpoints are only send and received asynchronously.
Requests on endpoint zero are not supported by this class;
use controlTransfer(int, int, int, int, byte[], int, int) for endpoint zero requests instead.
| Public Constructors | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Public Methods | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
Cancels a pending queue operation.
| |||||||||||
Releases all resources related to this request.
| |||||||||||
Returns the client data for the request.
| |||||||||||
Returns the endpoint for the request, or null if the request is not opened.
| |||||||||||
Initializes the request so it can read or write data on the given endpoint.
| |||||||||||
Queues the request to send or receive data on its endpoint.
| |||||||||||
Sets the client data for the request.
| |||||||||||
| Protected Methods | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
Invoked when the garbage collector has detected that this instance is no longer reachable.
| |||||||||||
|
[Expand]
Inherited Methods | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
From class
java.lang.Object
| |||||||||||
Cancels a pending queue operation.
Returns the client data for the request.
This can be used in conjunction with setClientData(Object)
to associate another object with this request, which can be useful for
maintaining state between calls to queue(ByteBuffer, int) and
requestWait()
Returns the endpoint for the request, or null if the request is not opened.
Initializes the request so it can read or write data on the given endpoint. Whether the request allows reading or writing depends on the direction of the endpoint.
| endpoint | the endpoint to be used for this request. |
|---|
Queues the request to send or receive data on its endpoint.
For OUT endpoints, the given buffer data will be sent on the endpoint.
For IN endpoints, the endpoint will attempt to read the given number of bytes
into the specified buffer.
If the queueing operation is successful, we return true and the result will be
returned via requestWait()
| buffer | the buffer containing the bytes to write, or location to store the results of a read |
|---|---|
| length | number of bytes to read or write |
Sets the client data for the request.
This can be used in conjunction with getClientData()
to associate another object with this request, which can be useful for
maintaining state between calls to queue(ByteBuffer, int) and
requestWait()
| data | the client data for the request |
|---|
Invoked when the garbage collector has detected that this instance is no longer reachable. The default implementation does nothing, but this method can be overridden to free resources.
Note that objects that override finalize are significantly more expensive than
objects that don't. Finalizers may be run a long time after the object is no longer
reachable, depending on memory pressure, so it's a bad idea to rely on them for cleanup.
Note also that finalizers are run on a single VM-wide finalizer thread,
so doing blocking work in a finalizer is a bad idea. A finalizer is usually only necessary
for a class that has a native peer and needs to call a native method to destroy that peer.
Even then, it's better to provide an explicit close method (and implement
Closeable), and insist that callers manually dispose of instances. This
works well for something like files, but less well for something like a BigInteger
where typical calling code would have to deal with lots of temporaries. Unfortunately,
code that creates lots of temporaries is the worst kind of code from the point of view of
the single finalizer thread.
If you must use finalizers, consider at least providing your own
ReferenceQueue and having your own thread process that queue.
Unlike constructors, finalizers are not automatically chained. You are responsible for
calling super.finalize() yourself.
Uncaught exceptions thrown by finalizers are ignored and do not terminate the finalizer thread. See Effective Java Item 7, "Avoid finalizers" for more.
| Throwable |
|---|