Closed Bug 936995 Opened 9 years ago Closed 9 years ago

[bluedroid] Bluetooth gets stuck at turning-on state if users turns on/off Bluetooth fast

Categories

(Firefox OS Graveyard :: Bluetooth, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
1.3 Sprint 5 - 11/22

People

(Reporter: shawnjohnjr, Assigned: echou)

References

Details

Attachments

(1 file)

Bluetooth gets stuck at turning-on state when fast turning on/off.
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
Steal! :)
Assignee: shuang → echou
OS: Linux → Gonk (Firefox OS)
Hardware: x86_64 → ARM
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)
I've tested my patch on both Nexus 4(bluedroid) and Unagi(blueZ). Both worked fine.
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+
> 
> 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.
followup: bug 940834
blocking-b2g: --- → 1.3?
https://hg.mozilla.org/mozilla-central/rev/a67b11842906
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → 1.3 Sprint 5 - 11/22
Blocks: 941416
already in master 1.3, clear flag
blocking-b2g: 1.3? → ---
You need to log in before you can comment on or make changes to this bug.