1181190 - (Gaia-BT-v2-API) [v2 API] When bluetooth.enabled setting is to false, all bluetooth adapters states should be set to disabled

Status: RESOLVED INVALID

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

Description

[Martijn Wargers (dead)]

This is the new API for bluetooth:
https://wiki.mozilla.org/B2G/Bluetooth/WebBluetooth-v2

In Gaia we have the bluetooth.enabled setting. 
If that setting is set to false, the defaultAdapter.state can still be 'enabled'.
I would think that all adapter states would be set to 'disabled' when this setting is set to false.

Comment 1

[[e-mail], [e-mail]]

Hi Martijn,

As far as I know for the API design of Bluetooth v2, Gecko won't reference the mozSettings key 'bluetooth.enabled' anymore. If we want to turn Bluetooth off, we have to figure out which adapter is needed to be turned off. 


In the near future, our platform has one adapter only. In the other words, we can just use default adapter to turn Bluetooth on/off on the platform. So that I don't think that is a problem here.

Feel free to figure your problem. I think Gecko::Bluetooth devs will help to let us know the instructions.

Comment 2

[[e-mail], [e-mail]]

Per comment 1, resolved with INVALID.

Comment 3

[Martijn Wargers (dead)]

Ian, I'm surprised by this. 
A lot of these features like geolocation or wifi can be turned off by a setting or pref, see:
http://mxr.mozilla.org/gaia/source/build/config/common-settings.json#263
http://mxr.mozilla.org/gaia/source/build/config/common-settings.json#97

So with bluetooth, this won't be possible then. My question is more, shouldn't this be made possible in Gaia? If you think it shouldn't then this is a WONTFIX.
Is there a mailing list perhaps where I also could ask this question?

Comment 4

[[e-mail], [e-mail]]

Martijn,

From B2G project starting, mozSettings key is a very important role to be a communicator for Gaia/Gecko. Both Gaia/Gecko have to access/monitor the key value changed for turning hardware component on/off. For apps(3rd-app), they will need to have read/write permission via mozSettings. It's a dangerous way to expose permission.

Therefore, mozAPI will expose specific module(like "bluetooth") for its permission only in the future. It's no longer to depend on mozSettings permission. AFAIK, this is a goal to make dependency lower, to make security stranger.

If we want to control Bluetooth on/off, we can

* Request "bluetooth" permission
* Try to access default adapter via mozBluetooth
* Once an instance of default adapter is ready, do |adapter.enable()| and |adapter.disable()|

Ben,

Could you bring the mailing list for the design of Bluetooth API v2? Martijn would like to follow up for asking this question. Thanks.