iOS doesn't, and plays sound.
Android (and even iOS) have blocked audio playback without a user gesture event triggering it in their browsers, by default; however, this restriction is being bypassed by Wikitude on iOS, but not Android. As the Wikitude API provides a mechanism to trigger sound, it's reasonable to assume the user has given their consent to have audio played by the application, so this restriction is pointless.
Are there any short-term work arounds to allow HTML pages to play audio without user interaction on Android when using HtmlDrawables?
Good morning David,
I tried the HTML animation you sent with a couple of our iOS devices, but could not get sound out of any of them. The animation was playing perfectly fine, but the audio output simply wasn't there. I tried it with Chrome on my desktop machine and found the audio to be working, so the files you provided seem to work just fine.
I conferred with my colleague responsible for Android development and have been informed that there recently have been changes to the internal web view of the HTML drawable that should enable additional functionality. Maybe audio playback is among them. Since I could not get audio playback to work on either platform, I cannot assess whether that's the case or not.
I prepared a package including this fix for you to try. You may download it here.
Please be aware that this is a nightly build of the most recent state of our repositories. It contains untested code and may be unstable.
Thanks for looking into this.
We did investigate running the sound effects from Wikitude's AR.Sound, but there's a certain amount of complexity and overhead amongst the rest of our animation system that means driving this from the embedded HTML side makes a lot more sense - and iOS is our primary development platform, so we'd not noticed the Android issue around this before. Mainly because the animation timing has to be handled from the embedded HTML page, and there's no way of communicating out from that object to the Wikitude experience that an event has completed or a state has changed - so we have no choice but to keep the sound effects and timing as part of the HTML page.
Good morning David,
In any case, I'm confident to say that we do not take embedded sound into any kind special consideration on either platform.
May I ask what the specific use case is that requires embedded sound? Would not AR.Sound be a viable alternative?