We submitted a playable for ironsource and it got rejected. Below is the video of the problem
How to solve this problem? The critical bug says “Any device, any OS version: Creative is playing sound even though the player is in a muted state.”
We are currently dealing with this directly with IS, because we cannot identify the problem. Playables work in ironsource preview mode, but manual QA is rejecting them, while IS is not enclosing with us how they replicate this issue.
If possible, ask them in support ticket, how exactly are their manual testers triggering this issue, since in their own validator this issue is not present.
We have raised this issue with IronSource team. Waiting for their reply.this is what they have suggested Please make sure you have added an “audioVolumeChange” listener. For fix,
**read more on MRAID specificationshttps://www.iab.com/wp-content/uploads/2017/07/MRAID_3.0_FINAL.pdf under section 7.6.
Hey guys, our playables are made according to the documentation. The event they are reffering to is already implemented so again, this seems like IS testing problem - they dont want to communicate with us and are refusinmg to tell us how they are doing the manual test.
mraid.addEventListener(“audioVolumeChange”, (volume) => {
** console.log("MRAID audioVolumeChange: " + volume);**
** this.globalVolume = volume / 100;**
** if (this.onAudioVolumeChanged) {**
** this.onAudioVolumeChanged();**
** }**
** });**
IronSource is doing manual QA testing in a way that is unclear, since again, their own validator is passing all our playables.
Another proof for IS support, since Unity uses same MRAID v3 as Ironsource and have a testing tool that is logging events, you can cleary see the event is in your playable and is working properly
MRAID audioVolumeChange is called by our event
resetAudioVolume is internal code for volume
Thank you for your prompt response IS is looking into the matter with their inhouse developers lets see what they have to say.
1 Like