Closed Bug 889730 Opened 11 years ago Closed 11 years ago

[AudioChannelManager] GetHeadphones API should return true when state is headphone or headset.

Categories

(Firefox OS Graveyard :: General, defect)

Product:
Firefox OS Graveyard
Component:
General
Platform:
ARM
Gonk (Firefox OS)
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(blocking-b2g:leo+, firefox23 wontfix, firefox24 wontfix, firefox25 fixed, b2g18 fixed, b2g18-v1.0.0 wontfix, b2g18-v1.0.1 wontfix, b2g-v1.1hd fixed)

Status:
RESOLVED FIXED
Milestone:
1.1 QE4 (15jul)
Project Flags:
blocking-b2g leo+
Tracking Flags:
Tracking Status
firefox23 --- wontfix
firefox24 --- wontfix
firefox25 --- fixed
b2g18 --- fixed
b2g18-v1.0.0 --- wontfix
b2g18-v1.0.1 --- wontfix
b2g-v1.1hd --- fixed

People

(Reporter: mchen, Assigned: mchen)

Details

(Whiteboard: [LeoVB+] )

Attachments

(2 files, 2 obsolete files)

Patch Checkin-Version v2
(deleted), patch
mchen
: review+
Details | Diff | Splinter Review
Patch Checkin-Version for b2g18 branch
(deleted), patch
Details | Diff | Splinter Review
In AudioChannelManager::Notify(), the true of headset state will depend on ON/HEADPHONE/HEADSET and this is correct. But in AudioChannelManager::GetHeadphones(), it just judged the state by "ON" only. The real case is that GonkSwitch will notify event with off/headset/headphone values.
Attached patch Patch v1 (obsolete) (deleted) — — Splinter Review
The issue in this bug is that the headphone status is judged by statement as below. "return mState == hal::SWITCH_STATE_ON;" But actually the switch states for headphone would be SWITCH_STATE_OFF, SWITCH_STATE_HEADSET, // Headphone with microphone SWITCH_STATE_HEADPHONE, // without microphone So the return value will always be false.
Attachment #770707 - Flags: review?(amarchesini)
This will effect the engineering mode test on helix project.
blocking-b2g: --- → hd?
Comment on attachment 770707 [details] [diff] [review] Patch v1 Review of attachment 770707 [details] [diff] [review]: ----------------------------------------------------------------- lgtm
Attachment #770707 - Flags: review?(amarchesini) → review+
bumping to leo? for Mozilla triage - as a discussion with Marco indicates this is generic, although found while assessing helix's needs but it impacts the correctness of a WebAPI.
blocking-b2g: hd? → leo?
Whiteboard: [mozilla-triage]
Triage - partners will take this for leo.
blocking-b2g: leo? → leo+
Whiteboard: [mozilla-triage]
Attached patch Patch Checkin-Version (obsolete) (deleted) — — Splinter Review
To add reviewer name and leo+ approval.
Attachment #770707 - Attachment is obsolete: true
Attachment #776238 - Flags: review+
Keywords: checkin-needed
Attached patch Patch Checkin-Version v2 (deleted) — — Splinter Review
To fix the compile error on B2G debug mode. Sorry to make this trouble.
Attachment #776238 - Attachment is obsolete: true
Attachment #776948 - Flags: review+
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/48abd48a9017
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Needs a branch-specific patch for uplift.
status-b2g18: --- → affected
status-b2g18-v1.0.0: --- → wontfix
status-b2g18-v1.0.1: --- → wontfix
status-b2g-v1.1hd: --- → affected
status-firefox23: --- → wontfix
status-firefox24: --- → wontfix
status-firefox25: --- → fixed
Flags: needinfo?(mchen)
Keywords: branch-patch-needed
Target Milestone: --- → 1.1 QE4 (15jul)
Flags: needinfo?(mchen)
Keywords: checkin-needed
Whiteboard: [LeoVB+]
Can you please provide steps to verify this fix - as we can perform blackbox testing from the UI?
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: