The interface for Bluetooth Sockets is similar to that of TCP sockets:
ServerSocket. On the server
side, use a
BluetoothServerSocket to create a listening server
socket. When a connection is accepted by the
it will return a new
BluetoothSocket to manage the connection.
On the client side, use a single
BluetoothSocket to both initiate
an outgoing connection and to manage the connection.
The most common type of Bluetooth socket is RFCOMM, which is the type supported by the Android APIs. RFCOMM is a connection-oriented, streaming transport over Bluetooth. It is also known as the Serial Port Profile (SPP).
To create a
BluetoothSocket for connecting to a known device, use
connect() to attempt a connection to the remote device.
This call will block until a connection is established or the connection
Once the socket is connected, whether initiated as a client or accepted
as a server, open the IO streams by calling
getOutputStream() in order to retrieve
OutputStream objects, respectively, which are
automatically connected to the socket.
For more information about using Bluetooth, read the Bluetooth developer guide.
|Modifier and Type||Field and Description|
|Modifier and Type||Method and Description|
Closes the object and release any system resources it holds.
Attempt to connect to a remote device.
Invoked when the garbage collector has detected that this instance is no longer reachable.
Get the input stream associated with this socket.
Get the output stream associated with this socket.
Get the remote device this socket is connecting, or connected, to.
Get the connection status of this socket, ie, whether there is an active connection with remote device.
public static final int MAX_RFCOMM_CHANNEL
protected void finalize() throws Throwable
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
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
Uncaught exceptions thrown by finalizers are ignored and do not terminate the finalizer thread. See Effective Java Item 7, "Avoid finalizers" for more.
public BluetoothDevice getRemoteDevice()
public InputStream getInputStream() throws IOException
The input stream will be returned even if the socket is not yet connected, but operations on that stream will throw IOException until the associated socket is connected.
public OutputStream getOutputStream() throws IOException
The output stream will be returned even if the socket is not yet connected, but operations on that stream will throw IOException until the associated socket is connected.
public boolean isConnected()
public void connect() throws IOException
This method will block until a connection is made or the connection fails. If this method returns without an exception then this socket is now connected.
Creating new connections to
remote Bluetooth devices should not be attempted while device discovery
is in progress. Device discovery is a heavyweight procedure on the
Bluetooth adapter and will significantly slow a device connection.
BluetoothAdapter.cancelDiscovery() to cancel an ongoing
discovery. Discovery is not managed by the Activity,
but is run as a system service, so an application should always call
BluetoothAdapter.cancelDiscovery() even if it
did not directly request a discovery, just to be sure.
close() can be used to abort this call from another thread.
IOException- on error, for example connection failure
public void close() throws IOException
Although only the first call has any effect, it is safe to call close
multiple times on the same object. This is more lenient than the
AutoCloseable.close(), which may be called at most