Closed Bug 1086175 Opened 5 years ago Closed 5 years ago
[Flame][KK]After full flash/reset phone, first time to pair bluetooth with another phone will show notification then pair failed
[Device & Build] Flame KK base image v188 + full flash pvt 2.1 image --------------------------------------------- STR: 1. Full flash/reset phone 2. Settings app -> Bluetooth -> Enable both Bluetooth and Visible to all 3. Pair with another phone Actual Result: Notification will show "Bluetooth pairing request" but cannot pair successfully After reboot, it can be paired and doesn't show any notification Only the first time after full flash or reset phone will encounter this problem Reproduce rate: 5/5
Problematic log W/bt-l2cap( 211): L2CA_SetDesireRole() new:x0, disallow_switch:0 W/AudioFlinger( 201): Thread AudioOut_2 cannot connect to the power manager service E/AudioFlinger( 201): no wake lock to update! W/AudioFlinger( 201): Thread AudioOut_2 cannot connect to the power manager service E/AudioFlinger( 201): no wake lock to update! D/btif_config_util( 211): btif_config_save_file(L188): in file name:/data/misc/bluedroid/bt_config.new E/bt-btif ( 211): check_cod: remote_cod = 0x5a020c E/bt-btm ( 211): btm_sec_disconnected - Clearing Pending flag W/bt-l2cap( 211): L2CA_SetDesireRole() new:x0, disallow_switch:0
blocking-b2g: --- → 2.1?
Build Information: Gaia-Rev db34a4b7edc0e08ede425f21f8a5b5e161e7dda8 Gecko-Rev https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/65fe0274b476 Build-ID 20141020161201 Version 34.0 Device-Name flame FW-Release 4.4.2 FW-Incremental eng.cltbld.20141020.194750 FW-Date Mon Oct 20 19:48:03 EDT 2014 Bootloader L1TC00011880
I'm able to reproduce the issue. After turned screen on/off, the issue is disappeared. It means we get a wrong value of req.result['lockscreen.locked']. If lockscreen.locked is true, we will fire notification instead of showing pairing dialog immediately.
Per comment 3, I would like to grep some info. from Greg.:-/ Have you ever seen the wrong value of lockscreen.locked before turn screen on/off? Thanks.
Pretty sure this is a regression. Adding qawanted for branch checks. If not a regression, please re-nominate.
I suspect this is a dupe of bug 1069690, which was marked as worksforme because nobody else could repro it except me (including Ian Liu). Inheriting branch check results from bug 1069690 comment 20. If a regression window is ever needed then it is in bug 1069690 comment 6 as well.
Assignee: nobody → iliu
Component: Bluetooth → Gaia::System::Lockscreen
I'm able to reproduce the issue on v2.2. And I add some log for checking value of settings key 'lockscreen.locked'. ================================================================================================ I/Bluetooth Manager( 7543): Content JS LOG: PairManager(): onRequestPairing(): pairingInfo = [object Object] I/Bluetooth Manager( 7543): at PairManager.debug (app://bluetooth.gaiamobile.org/js/pair_manager.js:278:8) I/Bluetooth Manager( 7543): Content JS LOG: ---> onRequestPairing coming... I/Bluetooth Manager( 7543): at PairManager.onRequestPairing (app://bluetooth.gaiamobile.org/js/pair_manager.js:55:6) I/Bluetooth Manager( 7543): Content JS LOG: ---> req.result["lockscreen.locked"] = true I/Bluetooth Manager( 7543): at bt_onGetLocksuccess (app://bluetooth.gaiamobile.org/js/pair_manager.js:60:0) ================================================================================================ The key is wrong since I'm still operating the pairing process in screen on. So, the key value of 'lockscreen.locked' should be false. Per this comment and comment 6, needInfo from Greg. PS: I reproduced the issue after full flashed device from TBPL build without trigger screen on/off. In other words, if we turn the screen on/off, the issue is not able to be reproduced.(Because 'lockscreen.locked' key value should be updated correctly.)
(In reply to Ian Liu [:ianliu] from comment #7) > So, the key value of 'lockscreen.locked' should be false. Per this comment *wording--> should be true as above console log
Per offline discussion with Greg, looks like some regression is needed to fix. And Greg already gave a fixing patch for manual test with me. It is working fine.:) Thanks for Greg's response quickly.
Assignee: iliu → gweng
I'll submit v2.1 patch ASAP.
Attachment #8510134 - Flags: review?(alive)
Attachment #8510134 - Flags: review?(alive) → review+
As stated this is a regression and a 2.1 blocker. Adding verifyme for QA verification after the patch has landed.
QA Whiteboard: [COM=Bluetooth][QAnalyst-Triage?] → [COM=Bluetooth][QAnalyst-Triage+]
It only failed at one intermittent keyboard test: https://treeherder.mozilla.org/ui/#/jobs?repo=gaia-try&revision=261e2e6e35b2 So I would land this patch and submit the approval for v2.1.
Comment on attachment 8510138 [details] [review] Patch v2.1 [Approval Request Comment] [Bug caused by] (feature/regressing bug #): In the progress of decoupling LockScreen, I missed to move the mozSettings logic from the legacy lockscreen.js to new LWM [User impact] if declined: Error occurs [Testing completed]: Gaia-Try on v2.1 failed only with intermittent errors and one serious error caused by Bug 1082071, which I've confirmed the root cause and NI the author. [Risk to taking this patch] (and alternatives if risky): No [String changes made]: No
Attachment #8510138 - Flags: approval-gaia-v2.1?(fabrice)
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Attachment #8510138 - Flags: approval-gaia-v2.1?(fabrice) → approval-gaia-v2.1+
Verified on [2.1] Gaia-Rev eb0aab0f13c78c7ac378ad860e865c4b6eaf669f Gecko-Rev https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/318019f80a8e Build-ID 20141029001202 Version 34.0 [2.2] Gaia-Rev b48f66220dff75f767eddf28a1d58192fc811410 Gecko-Rev https://hg.mozilla.org/mozilla-central/rev/53d84829b2b8 Build-ID 20141028160206 Version 36.0a1
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.