@Rob - if you can point me to some information about the bug, then I can point that out to Google and push back on them on their requirement and see how far that gets us.
@kenny - yeah, we thought about it. Something like do audio.stop() on suspend. But it doesn’t work because when the app resumes, we would need to restart the music where we left off. And there is simply no way for us to do that recovery properly given the complexity of our app.
many thx!
@akao Have you considered audio.pause and audio.resume? Also did you tinker with system.setidletimer to prevent the screen from timing out in the first place? I’ve played plenty of games that won’t let the screen timeout; Candy Crush is an example.
Of course these would only be temporary solutions until this bug gets fixed.
Good question, is preventing the screen from timing out an acceptable solution from Google’s perspective?
Also, can you swap this “no screen time outs” flag on the go, ie never allow timeouts when a game level is being played but allow it on the menus? Then only music could be played during an actual play session. I’m guessing no.
@akao - Even if using a system event for suspend to stop the audio was suitable, suspend will not work. Tried it already.
If I where in your shoes, I might consider removing music entirely from my game. It’s only a polish thing for my game anyway.
It’s not a “bug” exactly. In 5.1 Google changed how the Android lifecycle works and it’s works differently than it’s documented. In the pre-release of 6.0, they’ve gone back to the 5.0 way of doing things. Corona uses it the way it’s documented. Engineering is working on a work around. I doubt Google would go back in to the 5.1 branch and change how it works. They fix things like this in 6.0
@Rob Got it. Please do keep us posted on the progress on this issue then, it is something that we would need to rely on Corona for a fix.
@gullie667 @Vince_ Negative on keeping the app awake. While I don’t have Google’s developer guideline in front of me, I am pretty sure it’s something that won’t pass muster - even if not Google, then Apple/Amazon/Samsung for sure. We’ve accidentally done something like this in the past due to bugs in our code, and have had our app rejected. Plus it creates a horrible user experience that could cause our app to be uninstalled (which is another big problem on Google).
And our app does use a ton of SFXs (100+), making work-arounds that would involve us keeping track of what audio is playing where not very practical.
Thanks! We’ll let you know once we have a chance to test it out.
@MichaelW @RobMiracle
I downloaded Corona #2015.2705 and was able to give it a test. Unfortunately, I ran into a bug. Basically, if there is a transition that hasn’t finished when the device goes to sleep, then the music won’t stop playing. I was able to create a simple test case to duplicate the issue.
local backgroundMusic = audio.loadStream( "Ambience\_ThemeMusic.mp3"); local backgroundMusicChannel = audio.play (backgroundMusic, {loops = -1}); local txt = display.newText ({text = "Playing music"}); txt.x = 240; txt.y = 160; local testTransition = transition.to (txt, {xScale = 5, yScale = 5, time = 50000}); -- bug -- local testTransition = transition.to (txt, {xScale = 5, yScale = 5, time = 5000}); -- works
Can you please look into this?
Thanks!
Andrew
@RobMiracle @MichaelW I’ve just resubmitted a new Bug to track this issue. Can you please take a look and let me know?
http://developer.coronalabs.com/node/843/done?sid=17997
Case # 42653
Hi everyone,
We have a work-around to this available in daily build 2015.2718+.
The problem here actually stems from the Android 5.1.X OS misfiring events to OpenGL, not Corona’s code. That being said, there’s only so much we could do to work around it. We’ve disabled the idle timer just for apps running on Android 5.1.X to work-around this issue.
From testing on the hardware system images currently available for Android 6.0, this issue doesn’t occur, so this work around will only need to be applied to Android 5.1.X.
@Ajay - Thank you so much for putting in the effort on this! I am sure it was very frustrating and time consuming.
We’ll give it a try and report back how it works.
Hey Guys, I just have a couple of questions.
The problem here actually stems from the Android 5.1.X OS misfiring events to OpenGL, not Corona’s code.
Wouldn’t this affect every other app on the market then? Why is it that some apps don’t have a problem stopping the music when the screen sleeps?
We’ve disabled the idle timer just for apps running on Android 5.1.X to work-around this issue.
When you say disabled the idle timer do you mean you’re preventing the screen from sleeping? That’s the workaround that I proposed above, which @akao was opposed to.
@Vince_ from my perspective, the key is that Corona is only disabling the timer for Android 5.1.X as oppose to all versions of Android.
Unfortunately, if Google were to raise issue on this behavior, all I can say is “look, Google’s SDK is causing this, both us and Corona Labs have already expanded considerable effort trying to meet this edge case. And this is the best solution we can come up with.”
The issue here (just to reiterate for everyone else) is that there is a bug in the OS that only happens on 5.1 when the device puts itself to sleep. 5.0 does not have this problem. Nor does the upcoming 6.0 that we’ve been testing with. There are 2 naughty things that the OS is doing on 5.1 when the screen goes to sleep…
1) The Android activity doesn’t follow the documented lifecycle. It transitions from running->onStop->onPause which is wrong (pause always comes before stop). This was preventing us from suspending Corona reliably. For this, we’ve added some safeguards to help protect against this in the future to guarantee that you’ll always get an “applicationSuspend” event in Corona; even on 5.1.
http://developer.android.com/reference/android/app/Activity.html#activitylifecycle
2) The ugliest issue only affects OpenGL based Android apps. Google’s GLSurfaceView was wrongly being detached from the activity’s window, which stopped the OpenGL thread that the Corona runtime and its Lua scripts run on, and it also caused the OpenGL context to become invalid. The destruction of the OpenGL context proved to be the final nail in the coffin because it made using OpenGL at that point dangerous and cause crashes in the OpenGL driver on some 5.1 devices. The issue is that we don’t know to suspend Corona until the OS destroys the OpenGL context on us, but that also prevents us from delivering an “applicationSuspend” to Corona reliably since anything you do with the display in Lua has suddenly become dangerous (ie: can cause crashes). So, our final course of action was to avoid the situation all together by preventing the screen from going to sleep.
Now, I’m not particularly happy about this work-around either, but our reasoning here is that this issue only happens on Android 5.1 which, according to Google Play at the time of this posting, is only 5% of the market. It didn’t seem to make sense to put anymore time and resources into this for an OS version that is really just a stepping stone to 6.0, which Google will be pushing hard in the near future. We’d rather put our resources back into proper 6.0 support and dynamic permission handling, which I’m sure Google will demand once 6.0 gets released.
https://developer.android.com/about/dashboards/index.html
Final Note:
Corona’s system.setIdleTimer() will always be false on Android 5.1 You cannot set it true. That’s our work-around.
@Joshua Quick
I see, thanks for the thorough explanation! You should probably add this as a Gotcha on the system.setIdleTimer documentation page.
I know you tried the “system” event (type == “applicationSuspend”), but do you get any “system” event at all when the screen ‘times out’?
BTW, when you say ‘times out’ you mean it automatically sleeps right?
My hope here is that there is another “system” event coming in that you can use as a trigger.
Yeah… The system event suspend works fine in the sense that once the device is awoken via the power button it calls both suspend and resume at that time.
If you manually push the power button suspend is immediately called. Once the device is awoken via the power button it calls resume.
But I digress, all this is known and noted the in the documents.
“BTW, when you say ‘times out’ you mean it automatically sleeps right?”
–The sound is continuing to play when my app / device automatically sleeps via time out.
To the TOP!
Still hoping for a response.
Hi, I’m experiencing this issue too. Did you ever figure out how to fix it?