|MainThreadTask| performs different operations on the main thread,
depending on a given command flag. There is only one command, CLOSE_SCO,
in use.
This patch removes the command infrastructure and replaces |MainThreadTask|
by |CloseScoRunnable|, which implements only this single operation.
A number of notifications dispatch runnables to the main thread for
invoking actions. This is not requireed, as notifications already
run on the main thread. This patch merges the runnable's code into
the respective notifications.
This patch replaces Handsfree callbacks by notifications. One
important change is that the first call to |BluetoothHandsfreeManager::Get|
now happens during initialization. Hence the Handsfree manager is now setup
immediately, instead of later at use.
The patch adds notifications support to the Handsfree manager. Each
notification's method is taken from the respective callback code, with
changes to the arguments' data types.
The notification interface consists of virtual methods that are
invoked form the Bluetooth backend on certain events. The Handsfree
manager can implement the methods to handle these events.
This patch removes unsued code from |BluetoothServiceBluedroid|, related
functions, and cleans up the file. It
* removes callbacks,
* removes callback helper tasks,
* removes helper functions, and
* cleans up global variables.
Bluedroid callbacks were usually called on a separate thread that
was specific to this task. So Gecko's Bluetooth Core contained a
number of runnables for executing callback operations on the main
thread.
Since all notifications always run on the main thread, the extra
runnables are not required any longer. This patch integrates them
into the notification methods where possible.
This patch adds the Gecko-side of the Core notifications. The current
implementation of the notification methods has been copied from the
repsective Bluedroid callback methods, with only minor changes to adapt
them to Gecko data types.
A notification is a callback from the Bluetooth backend to inform
Gecko about a event. Bluedroid uses function pointers for this, but
in Gecko we use method calls instead.
Gecko implements notification handlers for the Bluetooth backend. The
backend converts incomming events to Gecko types and forwards them to
the registered notification handler.
This patch adds some runnable classes for running class methods on
the main thread. This is the base of the upcomming notification
mechanism for Bluetooth.
This patch fixes array initialization in the |Convert| functions of
|BluetoothInterface|. Designated initializers are not supported by
all compilers, so we wrap them into a macro and only used them when
possible.
This patch cleans up the interface of Bluedroid's |BluetoothScoket|
to look more similar the interface of |UnixSocketConsumer|, from
which it descends.
This patch converts Bluedroid status codes in Gecko to the
backend-neutral data type |BluetoothStatus|. All error handlers
have been adapted. The Bluedroid type |bt_status_t| only remains
in |BluetoothInterface|.
With this patch |BluetoothHandsfreeInterface| is responsible for converting all
Bluetooth data types to Bluedroid types. All callers have been adapted.
The linker mixes up |ConnectResultHandler| from BluetoothSocket.cpp
and BluetoothHfpManager.cpp. Consequently one of them gets removed
when linking libxul.so.
This patch works around the problem by renaming |ConnectResultHandler|
in BluetoothSocket.cpp to |ConnectSocketResultHandler|.
When sending a |BluetoothInterfaceRunnable3<>| to the main thread,
in the case of BluetoothSocketResultHandler, the connect and accept
operations transfer string objects by reference from the I/O thread.
When the reference is accessed, the actual string might be removed
already.
The patch fixes the problem by storing the strings as value in the
runnable object.
The Bluedroid code uses indices into global arrays while pairing
with devices. These arrays might get changed in between and the
indices become incorrect. The result is undefined.
The patch fixes the problem by using the value, a reply runnable,
directly for array lookups. No indices are required.
This bug was fixed in bluetooth2/ already, but not yet backported.
Recent patches to Bluetooth introduced asynchronous initialization of
profile manager. The code in hfp-fallback was not adapted then. This
patch updates the broken code.
Profile managers use the new class |BluetoothProfileResultHandler|
to signal the result of initializing of cleaning up operations to
|BluetoothServiceBluedroid|. |BluetoothServiceBluedroid| proceeds
once all profile handlers have finished.
Future patches will build upon this patch to create completely
asynchronous profile managers.
This patch adds a missing include statement for <errno.h> to
BluetoothInterface.cpp. This fixes the build for flatfish
devices. For safety, the patch also adds an include statement
for <unistd.h>, which might be necessary for several functions.
Currently, BluetoothSocket leaks its file descriptor on close
operations. With this patch when Gecko closes an instance of
BluetoothSocket, the file descriptor is now closed as well.
This patch removes all code related to socket setup from Bluedroid's
BluetoothSocket. The socket setup is handled by BluetoothInterface;
transparantly to its users.
Since most of the socket setup is now hidden, a comment was added to
DroidSocketImpl that explains the connection phases in server and
client.
This patch moves the accept phase of Bluedroid's |Listen| to the
implementation of BluetoothInterface. |BluetoothInterface::Accept|
handles Bluedroid's socket-setup messages and executes the result
handler with the received file descriptor and data.
Bluedroid's internal socket setup transfers 2 messages and possibly
a file descriptor as the first data of a socket connection.
This patch moves the socket-setup code for the |Connect| call to
the implementation of BluetoothInterface. BluetoothSocket only
handles the socket setup of |Listen|, and general socket state.
In preparaton of moving the Bluedroid socket setup to BluetoothInterface,
this patch introduces connection states for Bluetooth sockets. There are
4 states,
- Disconnected,
- Listening,
- Connecting, and
- Connected.
All sockets start in Disconnected and transition to Connected via one
of the other states. Server socket transition through Listening, Client
sockets transition through Connecting. There is currently a lot of code
duplication in read and write methods. This will be cleaned up when the
connection setup is handled by BluetoothInterface.
The result-handler class contains a method for each interface
in the Core profile and a method for failed calls. The patch
also adds runnable classes that execute a result handler's
method on the main thread.
This patch adds classes around all Bluedroid interfaces that are
currently used by Gecko. These are Core, Socket, Handsfree, A2DP,
and AVRCP.
All arguments and return values are still Bluedroid types and
constants. Future patches will convert them to interface-neutral
artifacts.
Few marionette tests in unit-test set may navigate to specific URL and
wouldn't restore the URL of marionette client when the tests end.
Navigate the URL to default value before running Bluetooth test to make
sure the correctness of test.
Ensures that we can always receive that "enabled"/"disabled" event by
installing the event handler *before* we ever enable/disable Bluetooth. Or
we might just miss those events and get a timeout error.
Use BlueZ API 'CreateDevice' to update the SDP records of those
unknown devices. On the other hand, still use 'DiscoverServices'
to update SDP records of paired devices.
Few marionette tests in unit-test set may navigate to specific URL and
wouldn't restore the URL of marionette client when the tests end.
Navigate the URL to default value before running Bluetooth test to make
sure the correctness of test.
Please note that sSetPropertyRunnableArray[0] should be fired after
firing "PropertyChanged" to BluetoothAdapter, however this is not
guaranteed in current implementation. This patch also fixed this
potential problem.
Current Bluetooth related webidl implementation would make interfaces
such as BluetoothAdapter exposed to all web pages, and obviously we
don't want to see that.
If user tries to send a file to a device which just completes the pairing
process, the OPP manager may update SDP records when it's not ready.
It's especially likely to occur in BT file transfer with inline pairing
since OPP manager would request for a service channel to send the file when
device is just paired.
This patch converts |DroidSocketImpl| to inherit from |UnixFdWatcher|.
|UnixFdWatcher| maintains a Unix file descriptor on the I/O loop, and
replaces similar functionality in |DroidSocketImpl|.
As a side effect, all file descriptors in |DroidSocketImpl| are now
non-blocking. This does change the way how the code works, but ensures
that it doesn't block on the I/O thread.
Consent pairing event raises under the following conditions:
1. Local IO capabilities are DisplayYesNo and remote IO capabiltiies are DisplayOnly or NoInputNoOutput.
2. Call PairingConsent callback for "incoming" request.
This patch is try to directly reply pairing confirmation for consent cases.
How to test:
1. Initialize pairing request with IO capabilities-NoInputNoOutput as
headset role to b2g phone
2. Check pairing status of bluetooth headset
This patch removes the constant BLUEZ_DBUS_BASE_IFC from the file
RawDBusconnection.cpp. The constant is specific to BlueZ, and that's
where it's located now.
With this patch, the listen operation for Bluedroid sockets
runs on the I/O thread. The related interface is identical to
the one of |UnixSocketConsumer|.
With this patch, the connect operation for Bluedroid sockets
runs on the I/O thread. The related interface is identical to
the one of |UnixSocketConsumer|.
|sControllerArray| is only being used on the main thread, but
cleared on the I/O thread. During the BlueZ shutdown, we go
through the main thread, where we can clear |sControllerArray|;
moving the variable to main thread exclusively.
|sAdapterPath| is being accessed from within the main and the
I/O thread in a possible non-thread-safe way. This patch moves
all access to the I/O thread.
This patch prepares moving |sAdapterAdded| to the I/O thread. For
|GetServiceChannel| it gets pushed into task classes on the I/O
thread and the interface of these classes is cleaned up.
|sAuthorizedServiceClass| is being set on the main thread, but read
from within the I/O thread. Making the variable a static constant
array and moving all access to the I/O thread fixes potential race
conditions.
This patch was mostly generated with the following command:
find . -name "*.h" -o -name "*.cpp" | xargs sed -e '/WrapObject(JSContext/ {; N; s/\(WrapObject(JSContext *\* *a\{0,1\}[Cc]x\),\n\{0,1\} *JS::Handle<JSObject\*> a\{0,1\}[sS]cope/\1/ ; }' -i ""
and then reverting the changes that made to
dom/bindings/BindingUtils.h, since those WrapObject methods are not
the ones we're trying to change here, plus a bunch of manual fixups
for cases that this command did not catch (including all the callsites
of WrapObject()).
This patch was mostly generated with this command:
find . -name "*.h" -o -name "*.cpp" | xargs sed -e 's/Binding::Wrap(aCx, aScope, this/Binding::Wrap(aCx, this/' -e 's/Binding_workers::Wrap(aCx, aScope, this/Binding_workers::Wrap(aCx, this/' -e 's/Binding::Wrap(cx, scope, this/Binding::Wrap(cx, this/' -i ""
plus a few manual fixes to dom/bindings/Codegen.py, js/xpconnect/src/event_impl_gen.py, and a few C++ files that were not caught in the search-and-replace above.
This patch adds an annotation to each assertion for non-main threads in
the BlueZ backend of Bluetooth. This should make is easy and obvious to
see in which context a method or function is expected to run.
The global variables in BluetoothDBusService.cpp are now annotated
for their multi-threading access. Some code still seems to access
some of these variables in an unprotected manner. Follow-up patches
should clean this up.
As a side effect, this patch makes several variables as constant,
which improves correctness of the code.
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.
