952188 - Speaker Mode UI should not be present if device hardware doesn't support speaker mode

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::FMRadio, defect)

Description

[Jason Smith [:jsmith]]

In bug 947720, we saw a case where turning on speaker mode failed on a particular device. However, the UX provided no feedback to the user that speaker mode failed to turn on. We should make sure that we fire an error if speaker mode fails to turn on.

Comment 1

[Randy Lin [:rlin] - Be Mozillian on 2015/01/26]

If HW can't support this function, IMHO we may need to disable this button on UI on specific devices.

Comment 2

[Jason Smith [:jsmith]]

(In reply to Randy Lin [:rlin] from comment #1)
> If HW can't support this function, IMHO we may need to disable this button
> on UI on specific devices.

Good point. Actually, that means this is pretty important to do, as testing on Buri already showed that we could have a possibility of vendors not supporting speaker mode on their device. If we don't do this, then device hardware that doesn't support speaker mode will have a broken UI displayed in the FM Radio app.

That makes this worth noming for 1.3.

Comment 3

[Hema Koka [:hema]]

Pin since the gaia work for this feature was done by you, can you please take of fixing this UI issue with speaker mode.

Thanks
Hema

Comment 4

[Pin Zhang [:pzhang] (inactive)]

(In reply to Hema Koka [:hema] from comment #3)
> Pin since the gaia work for this feature was done by you, can you please
> take of fixing this UI issue with speaker mode.
> 
> Thanks
> Hema

OK.

Hi Randy, how can we know if the hw supports or not?

Comment 5

[Randy Lin [:rlin] - Be Mozillian on 2015/01/26]

Hi Macro, 
Do we have any experience for gaia size to do such customize?

Comment 6

[Marco Chen [:mchen]]

(In reply to Randy Lin [:rlin] from comment #5)
> Hi Macro, 
> Do we have any experience for gaia size to do such customize?

As I know that normally we can do feature detection first then decide whether mozSpeakerManager should be returned or not. Then Gaia can base on the returned object to decide the UI.

But the speaker can be used to convey "FMRadio", "Telephony Voice" and "Any Other Audio".
In buri's case now, only FMRadio didn't work well but other's are ok.

1. In current Web API design, Gaia didn't specify which case (FMRadio or ...) it tried to use.
2. Web API can't report which case is not supported from Gecko.
3. Currently Gonk level didn't export such query to Gecko.

--------------

For third point, the easy way is that vendor noted what capability it can't support via Property System (moz.speaker.fmradio = false). But it still need new change from Web API level to report this.

--------------

Finally I do think this is a vencom issue and ask Buri vendor to support it.

Comment 7

[Randy Lin [:rlin] - Be Mozillian on 2015/01/26]

Thanks Macro,
Maybe request partner to have a build script to hide this icon for this kind of customization.

Comment 8

[Jason Smith [:jsmith]]

The vendcom issue is already tracked elsewhere - this bug is dealing with the case when the device does not support speaker mode.

Comment 9

[Jason Smith [:jsmith]]

Marco - Can we safely assume all vendors should be required to support speaker mode for the speaker manager API? Or do we take into account that there could be vendors that could decide to not support speaker mode? That will determine whether we need to pref off the UI or not if speaker mode isn't supported.

Comment 10

[Marco Chen [:mchen]]

(In reply to Jason Smith [:jsmith] from comment #9)
> Marco - Can we safely assume all vendors should be required to support

I think this should be decided by product manager from perspective of FxOS SW/HW spec.

For me, I don't think FxOS should limit such kind of requirement.
So maybe FMRadio app can easily check the settings which is optimized from settings.json to decide the UI of speaker mode. (or Gecko can detect HW features from property system then set values into settings DB.)

Comment 11

[Jason Smith [:jsmith]]

Sri - Can you comment here from the product perspective on whether we need to be ready to handle the case where a FxOS phone we're shipping does not support speaker mode? We're trying to understand if we can enforce speaker mode on all devices or not for the FM Radio.

Comment 12

[Sri Kasetti]

Yeah, we should definitely support the case where the device doesn't have speaker mode.
We shouldn't be enforcing speaker mode on all devices.

Comment 13

[Jason Smith [:jsmith]]

Okay - moving back to 1.3? then - sounds like we do need to block on this.

Comment 14

[Hema Koka [:hema]]

CJ/Marco

Since the speaker mode for FMRadio feature was implemented by Pin and Randy for 1.3. Could one of them please get this issue addressed. 

Thanks
Hema

Comment 15

[u459114]

Randy, please discuss with marco to provide a mechanism for application to determine the visibility of speaker mode UI.

Comment 16

[Randy Lin [:rlin] - Be Mozillian on 2015/01/26]

Hi Macro,
I think we may add new method called getsupportedtype and it would return the constraints that this API supported. like {telephony, fm, media}?
BTW, How can I get this information about this device has supported speaker on feature?

Comment 17

[Marco Chen [:mchen]]

As I know that device/platform didn't provide such kind of query so the easy way is to define the property in full_hamachi.mk (ex: moz.force_speaker.disabled=fm).

Comment 18

[Pin Zhang [:pzhang] (inactive)]

(In reply to Marco Chen [:mchen] [PTO from 2013/12/24 ~ 2014/01/02] from comment #17)
> As I know that device/platform didn't provide such kind of query so the easy
> way is to define the property in full_hamachi.mk (ex:
> moz.force_speaker.disabled=fm).

Maybe we can just simply define a setting, and read it  in fmradio app?

Comment 19

[Randy Lin [:rlin] - Be Mozillian on 2015/01/26]

Hi Pin,
Is it a common way to do the customize in gaia side?

Comment 20

[Pin Zhang [:pzhang] (inactive)]

(In reply to Randy Lin [:rlin] from comment #19)
> Hi Pin,
> Is it a common way to do the customize in gaia side?

I'm sorry i don't know either, let's ask Tim, :)

Hi, Tim, what do you think?

Comment 21

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Gaia apps can be coded so be responsive to Setting database entries.

However, please consider customize these device capabilities on Android ro, just like bug 952043. Thanks!

Comment 22

[Marco Chen [:mchen]]

(In reply to Jason Smith [:jsmith] from comment #13)
> Okay - moving back to 1.3? then - sounds like we do need to block on this.

We need to make sure that there is one of devices shipped with V1.3 don't support FMRadio on speaker or I think we don't need to set it as block

Comment 23

[Marco Chen [:mchen]]

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #21)
> Gaia apps can be coded so be responsive to Setting database entries.
> 
> However, please consider customize these device capabilities on Android ro,
> just like bug 952043. Thanks!

I think let property to show capability is not difficult but we need a new Web API for query this.

Hi Randy,

I am ok for helping update property into full_XXX.mk.
But we still need your help on this new Web API.

Comment 24

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(In reply to Marco Chen [:mchen] from comment #22)
> (In reply to Jason Smith [:jsmith] from comment #13)
> > Okay - moving back to 1.3? then - sounds like we do need to block on this.
> 
> We need to make sure that there is one of devices shipped with V1.3 don't
> support FMRadio on speaker or I think we don't need to set it as block

(In reply to Jason Smith [:jsmith] from comment #8)
> The vendcom issue is already tracked elsewhere - this bug is dealing with
> the case when the device does not support speaker mode.

Where is the vendcom being tracked? Can we confirm Buri does not support FM speaker by design?

I don't think Hema would like to track a blocking bug when it doesn't really need to block.

Comment 25

[Jason Smith [:jsmith]]

It's actually not by design - the Buri guys are working on fixing this in bug 947720.

I guess that makes sense that we don't need to block on this until we hear a vendor requiring this to be implemented.

Comment 26

[BMO Automation]

Firefox OS is not being worked on