The class |DaemonSocket| and its helpers implement a service-
neutral connection to a HAL daemon. This patch moves the code
to an appropriate directory and breaks up the code into smaller
pieces.
This patch integrates the functionality of |BluetoothDaemonChannel|
into |BluetoothDaemonConnection|. All users are adapted, the former
class is removed.
This patch converts |ListenSocket| to forward events to an instance
of |ListenSocketConsumer|. All users are converted and the related
listener and consumer classes are removed.
With this patch, stream and listening sockets handle the setup of
accepted sockets internally. Sub-classes of |StreamSocket| don't
have to overload StreamSocket's |GetIO| any longer.
This patch moves |BluetoothDaemonSocketConnector| into its own file,
renames it to |BluetoothDaemonConnector| and implements the new socket-
connector interface.
This patch moves |BluetoothDaemonSocketConnector| into its own file,
renames it to |BluetoothDaemonConnector| and implements the new socket-
connector interface.
During restarts of the Bluetooth daemon, it can occur that Gecko tries
to send without having a connection to bluetoothd opened. This patch adds
a check to prevent this.
During restarts of the Bluetooth daemon, it can occur that Gecko tries
to send without having a connection to bluetoothd opened. This patch adds
a check to prevent this.
With the current code, the Bluetooth result runnable is saved for
receiving before a command has been sent successfully. If sending
fails afterwards, the saved result runnable will still sit in the
result queue, and interfere with later, successful commands.
With this patch, the result runnable is saved only if the sending
was successful.
With this patch, Bluetooth v1 and v2 share the same interfaces classes
for their backend code. Bluetooth v1 doesn't yet support GATT, so the
GATT interfaces are still not implemented.
The patch also fixes the GATT-specific classes to compile under recent GCC
versions 4.8 and later, which are used with Android L.
The patch also preserves the prefered backend for each version. Bluetooth
v1 defaults to 'bluetoothd,' v2 defaults to 'bluedroid.'
Bluetooth use different types for the second argument of their variant
of |BluetoothInterface::SspReply|. This patch standardizes them on the
v2 version.
With this patch, Bluetooth v1 and v2 share the same interfaces classes
for their backend code. Bluetooth v1 doesn't yet support GATT, so the
GATT interfaces are still not implemented.
The patch also fixes the GATT-specific classes to compile under recent GCC
versions 4.8 and later, which are used with Android L.
The patch also preserves the prefered backend for each version. Bluetooth
v1 defaults to 'bluetoothd,' v2 defaults to 'bluedroid.'
Bluetooth use different types for the second argument of their variant
of |BluetoothInterface::SspReply|. This patch standardizes them on the
v2 version.
There are some minor differences between backends in Bluetooth v1 and
v2. Some of the types have been added, removed or renamed. This patch
prepares the HAL and daemon backend interfaces to support both variants.
With this patch, Gecko will handle crashes of bluetoothd by clearing its
internal state. Switching Bluetooth off and on restarts the daemon and
the Bluetooth sub-system.
This patch adds error handling to all interface methods of Bluedroid's
daemon backend. If an error occures while sending a command to the daemon,
the methods dispatch an error.
This patch adds support for a random postfix for bluetoothd's socket
name. The postfix is re-generated for every instance of the daemon.
This prevents name collisions between mutliple sessions and malicious
programs from taking over the connection easily.
Currently, Gecko connects to a running instance of bluetoothd when
it starts the daemon backend. This contains a race condition between
the startup of the daemon and the startup of Gecko.
This patch changes the initialization and cleanup of Bluetooth's
daemon backend so that the Bluetooth daemon connects to Gecko. The
daemon process is now started as part of the initialization and
quits during shutdown. The steps are strictly ordered, so no race
condition exists.
The initialization and cleanup procedures should now be compatible
with BlueZ 5.
