Until now, we had corner cases in Bluetooth where DBus messages might
have been received on connections that are shutting down. This can't
happen any longer and this patch replaces the respective tests with
assertions.
With this patch, the start code of Bluetooth's BlueZ back mostly
runs on the I/O thread. Only the loading of the BT firmware and
the blocking connection setup is done on the BT thread.
The stop code has been moved to the I/O thread, except for some
initial waiting and the final cleanup of the firmware. The code
doesn't wait for errors anymore when cleaning up the connection
to DBus. This makes it run completely non-blocking. The initial
waiting may later be replaced by something more sophisticated.
This is caused by bug 967364. We need to hand over data structures
to DBus operations and forget about them if the operation returned
success. Until now, we could just tell their nsRefPtrs to |forget|
about them, but with bug 967364 applied we need to swap an empty
value into the pointer.
|ToggleBtTask| runs on the same thread as the start and stop methods
of |BluetoothService|. This patch merges the code of |ToggleBtTask|
into the start and stop methods and removes the class.
The Bluetooth thread is only necessary for starting and stopping
Bluetooth with the BlueZ backend. Bluedroid implements its multi-
threading internally.
This patch moves the Bluetooth thread into the BlueZ backend. Two
runnables implement the starting and stopping code. The methods
|StartInternal| and |StopInternal| of |BluetoothDBusService| each
create an instance of the respective runnable and send it to the
internal BT thread. The code in |BluetoothService| runs completely
on the main thread.
For the Bluedroid back end, the patch changes a number of thread
assertions.
When enabling or disabling Bluetooth, the Bluedroid backend waits
on sToggleBtMonitor until a BT adapter has been activated. Once
the monitor gets notified, the backend sends a ToggleBtAck runnable
to the main thread.
This patch removes sToggleBtMonitor from the Bluetooth Bluedroid
backend. Instead of signalling the monitor's notification, the
Bluedroid handler function sends the ToggleBtAck directly.
In BluetoothProfileController, it's meaningless to separate OnConnect
and OnDisconnect since the following steps would be the same for both
cases. Therefore I introduced a function called NotifyCompletion() for
each profile manager to report the completion of connecting/disconnecting
operations.
The current Bluetooth API can't allow user to disable BT before the BT
adapter is initialized.
In practice, We block the clicking event in gaia layer to prevent user
to turn off BT before BT enable procedure complete.
If we use marionette test to force emulator turn on and turn off BT in
a short period of time, it may crash emulator.
Listen to 'adapteradded' event rather than 'enabled' as the end of
BT enable to make sure we wouldn't disable BT when it's not ready.
The methods {Start|Stop}Internal for BlueZ and Bluedroid now send
ToggleBtAck to signal completeness of the operation.
The current patch allows for further cleanups in the BlueZ code. It
does not change the semantics or code flow.
PROP_BLUETOOTH_ENABLED signals the Bluetooth state to other
components in the system. Setting its value in ToggleBtAck
on the main thread avoids duplicated code in the upcoming
patches.
This patch cleans up the code for starting and stopping DBus
connections in the BlueZ backend of Bluetooth. It also fixes
a bug were the initial 'adapteradded' reply might have been
missed.
This patch removes all unnecessary code when starting and stopping
Gonk in BluetoothDBusService. The change simplifies the respective
methods considerably.
This patch cleans up the handling of libbluedroid.so and its
interfaces. Open and closing the library is now handled internally
and contained functions are wrapped in class methods.
Currently, the DBus connection for Bluetooth is shared between the
main thread and the I/O thread. This causes race conditions when
starting or stopping Bluetooth.
This patch moves all occurences of main-thread-invoked DBus send
operations to the I/O thread. This is mostly refactoring. Internally,
send operations are already executed on the main thread, so there is
no change in the over all logic of these methods.
