Closed
Bug 936995
Opened 11 years ago
Closed 11 years ago
[bluedroid] Bluetooth gets stuck at turning-on state if users turns on/off Bluetooth fast
Categories
(Firefox OS Graveyard :: Bluetooth, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
1.3 Sprint 5 - 11/22
People
(Reporter: shawnjohnjr, Assigned: echou)
References
Details
Attachments
(1 file)
5.67 KB,
patch
|
gyeh
:
review+
|
Details | Diff | Splinter Review |
Bluetooth gets stuck at turning-on state when fast turning on/off.
Reporter | ||
Updated•11 years ago
|
Summary: [bluedroid] Bluetooth gets stuck at turning-on state when Fast turning on/off Bluetooth → [bluedroid] Bluetooth gets stuck at turning-on state if users turns on/off Bluetooth fast
Assignee | ||
Comment 1•11 years ago
|
||
Steal! :)
Assignee: shuang → echou
OS: Linux → Gonk (Firefox OS)
Hardware: x86_64 → ARM
Assignee | ||
Comment 2•11 years ago
|
||
The root cause of this issue is that, when Bluedroid is our BT backend, turning on/off Bluetooth becomes an async call, which means that event 'Disable' would be fired earlier than the adapter state actually changed to BT_STATE_OFF. I used a lock to wait for AdapterStateChangeCallback being invoked, so that both StopInternal() in BluetoothDBusService and BluetoothServiceBludroid would be sync call.
Attachment #832857 -
Flags: review?(gyeh)
Assignee | ||
Comment 3•11 years ago
|
||
I've tested my patch on both Nexus 4(bluedroid) and Unagi(blueZ). Both worked fine.
Comment 4•11 years ago
|
||
Comment on attachment 832857 [details] [diff] [review] patch 1: v1: fire event 'Disable' after Bluetooth is really disabled Review of attachment 832857 [details] [diff] [review]: ----------------------------------------------------------------- This patch reminds me that we couldn't guarantee event |onenabled| is always dispatched before event |onadapteradded|. Please file a follow-up. Thanks. ::: dom/bluetooth/bluedroid/gonk/BluetoothServiceBluedroid.cpp @@ +180,5 @@ > + NS_LITERAL_STRING(KEY_MANAGER), true); > + nsRefPtr<DistributeBluetoothSignalTask> > + t = new DistributeBluetoothSignalTask(signal); > + if (NS_FAILED(NS_DispatchToMainThread(t))) { > + NS_WARNING("Failed to dispatch to main thread!"); nit: BT_WARNING @@ +649,3 @@ > int ret = aShouldEnable ? sBtInterface->enable() : sBtInterface->disable(); > + if (ret == BT_STATUS_SUCCESS) { > + lock.Wait(); We could just return NS_OK inside the if-statement, and, in the following statement, return NS_ERROR_FAILURE directly.
Attachment #832857 -
Flags: review?(gyeh) → review+
Assignee | ||
Comment 5•11 years ago
|
||
>
> This patch reminds me that we couldn't guarantee event |onenabled| is always
> dispatched before event |onadapteradded|. Please file a follow-up. Thanks.
>
Hm, good point. Just checked the mechanism and found out that this could happen on both BlueZ and Bluedroid implementation. Although it shouldn't be a problem for now, still worth to improve it. I'll file a followup, thanks.
Assignee | ||
Comment 6•11 years ago
|
||
followup: bug 940834
Assignee | ||
Comment 7•11 years ago
|
||
https://hg.mozilla.org/integration/b2g-inbound/rev/40ecdab580b3
Assignee | ||
Updated•11 years ago
|
blocking-b2g: --- → 1.3?
Assignee | ||
Comment 8•11 years ago
|
||
Backed out: https://hg.mozilla.org/integration/b2g-inbound/rev/20bd40612db5
Assignee | ||
Comment 9•11 years ago
|
||
b2g-inbound again: https://hg.mozilla.org/integration/b2g-inbound/rev/a67b11842906
Comment 10•11 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/a67b11842906
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → 1.3 Sprint 5 - 11/22
You need to log in
before you can comment on or make changes to this bug.
Description
•