Confirmed users
716
edits
WebAPI/AudioChannels: Difference between revisions
no edit summary
No edit summary |
No edit summary |
||
| Line 53: | Line 53: | ||
For apps that want to keep being able to play audio when the user leaves the app, the app can call requestWakeLock("audio") to grab an "audio" wakelock. As long as the app holds the "audio" wakelock its mutedChannels property won't change due to the user leaving the app. The mutedChannels property can of course still change if another app calls muteBelow("..."). | For apps that want to keep being able to play audio when the user leaves the app, the app can call requestWakeLock("audio") to grab an "audio" wakelock. As long as the app holds the "audio" wakelock its mutedChannels property won't change due to the user leaving the app. The mutedChannels property can of course still change if another app calls muteBelow("..."). | ||
== System | == System and Browser API changes == | ||
We | We need to enable the system app to know any time an app sets the volumeControlChannel property. A simple solution would be to fire a mozChromeEvent which indicates which app set the property and what it set the property to. That way the system app can track what value the property has in all apps and so when the volume buttons are used, the system app can know which is the visible app and what the property is set to in that app. | ||
In order to support a "audio" wakelock we should extend the browser API with two things. First off, we should add the ability to enumerate the set of locks that are being held by any page inside the <iframe mozbrowser>. As well as an event that is fired whenever that list changes. | |||
Second, we should add an API to mute/unmute the contents of the <iframe mozbrowser>. When a <iframe mozbrowser> is muted or unmuted, we'd change the mutedChannels property on all channel managers inside the browser, and fire "mutedchange" event as needed. | |||
== Security model == | |||
In order to get access to anything more than the "normal" channel, the application needs to enumerate these channels in the permissions property in the app manifest. So something like: | |||
permissions: { | |||
... | |||
audio: { | |||
channels: ["notification", "alarm"] | |||
}, | |||
... | |||
} | |||
This would enable the app to play sound through both the "notification" channel and the "alarm" channel. As well as call muteBelow("notification") and muteBelow("alarm"). | |||