[Resolved] Android & onWindowFocusChanged -- required for proper audio handling

Audio and Graphics
#1

I’m required to follow the proper audio handling as described in the following blog post:

http://android-developers.blogspot.com/2011/11/making-android-games-that-play-nice.html

For my app, I will need to take the approach described at the bottom of the above blog post:

1. Pause playback when you receive onPause().

2. When you receive onResume():

2.1  If you have previously received an onFocusChanged(false) message, wait for an onFocusChanged(true) message to arrive before resuming playback.

2.2 If you have not previously received an onFocusChanged(false) message, then resume audio immediately.

So… I will need to be able to access onWindowFocusChanged.  I found it mentioned in native android CoronaActivity related doc page:

http://docs.coronalabs.com/native/android/html/index.html?com/ansca/corona/CoronaActivity.html

I’m not entirely sure for what or for whom this doc page is intended, and unfortunately, I am unable to find any mention of onWindowFocusChanged in the API pages.

I’d appreciate hearing any thoughts on this, as well as suggestions for how we may go about handling audio in a manner that would meet Google Play’s requirement.

Naomi

#2

Actually, onWindowsFocusChanged() will *not* give you the proper audio handling that you are looking for.  This is because it gets called for native alerts dialogs.  That is, the focus switches to the alert when it is displayed.  Most Corona developers would not want audio to pause when displaying an alert dialog.

What we’ve implemented in Corona is much smarter.  We do not pause and resume audio when the activity’s onPause() and onResume() methods are called for the exact same reasons that blog post has mentioned.  We have a broadcast receiver set up to detect when the screen is off/on and if the screen lock is displayed or not.  So, Corona does not have the issue mentioned in that blog post.  Corona will *not* resume audio while the screen lock is displayed.  Corona will correctly resume audio after the screen lock has been cleared.

So, I’m confused why you are raising this issue at all.  What problems are you seeing?  Because so far, everyone has been happy with our suspend/resume handling of audio and it’s been passing app reviews on Google Play and Amazon.

Side Note:  The only audio handling issue that I’m aware of is with the Samsung app store.  They want audio to be muted when the ringer has been put into silent or vibrate mode.  But… Google Play app reviewer disagree with this and think a game’s audio should not be affected by the ringer state.  There is no one solution to make both app stores happy on this one unfortunately.

#3

Thank you so much, Joshua, for the detailed explanation.  I really appreciate it, and it sounds great.

The thing is, I’m currently in talks with Google Play review team who states that the following must be resolved before feature consideration:

- Audio from the app resumes behind the device’s lock screen. Please refer to this page for details:

http://android-developers.blogspot.com/2011/11/making-android-games-that-play-nice.html

So, I must assume my app isn’t handling audio the way they see fit.

For a stop gap measure, I added audio.stop upon both applicationSuspend and applicationResume, which should stop any sound from continue playing upon applicationResume.  

For this particular app, I’m okay with it – but I have another, new app that has background audio that loops throughout, and I would want it to resume playing upon applicationResume.   From what you noted, I don’t even need to add audio.stop upon applicationSuspend…  But if I must, I will add it, but if I do, I will also add a code that will trigger background music upon applicationResume.  Would it cause an issue?

As for the current app under review, what you say leaves me wondering what they are seeing as an issue…

Only audio I cannot stop playing immediately after applicationResume is some sound effects that are triggered by ongoing actions.  In other words, if someone suspends the app right in the middle of some series of actions, upon applicationResume, remaining action will resume, triggering sound effects.  So, if that’s the problem, then I guess I just have to add flags which would disallow any sound from playing after the applicationResume until the user touches the screen…  (and if I’m adding such flag, I guess I’ll use it for resuming background sound too…)

I’d rather not go that route, but do you think that’s the only option I have at this point?

Naomi

#4

Did Google provide any step-by-step instructions on how to reproduce this issue?

Because, I don’t understand what the issue is.  If you press the power button, the audio stops.  When you press the power button again and show the screen lock window, audio does *not* resume.  Corona only resumes audio after you clear the screen lock.  So, we’re already doing exactly what Google wants.  That is, we’re already doing what that blog article suggest.  So, this begs the question, what exactly is Google seeing?  Or perhaps they made a mistake and giving you the results from a different app?

#5

Joshua, thank you so much for spending the time to think about this and sharing your thoughts.  

I am puzzled.  The thing is, I couldn’t reproduce it (and now you’ve confirmed it can’t be reproduced) – I just thought, perhaps, my test device isn’t set up the way people in the real world do.  Hearing your thoughts, I’m convinced that the issue isn’t what they’ve noted.  Or perhaps they have not tested it correctly.  Regardless, I may still add the flag just for a good measure…

Edit:  BTW, what Google told me is exactly what I quoted above.  They have not supplied any step-by-step instructions on how to reproduce what they see as an issue…

Edit 2:  I also rule out that they gave me a result from another app, because there are only two items they want me to fix (one about back key handling and another about this audio) and they were very specific about where back key wasn’t behaving.  Back key issue they raised matches with how my app currently behaves (that is, it ignores back key during specific events in specific scenes – which is in the process of being rectified.)

#6

It’s possible the Google app reviewer just made a mistake.

Or… it’s also possible that it might have been a bug in Corona if you’ve built your app with the last release version, build #1137.  There was a rare issue that we can only reproduce on a Nook Color where Corona would not suspend and audio would not pause when pressing the power button.  Trouble was, the Samsung app store reviewers frequently ran into this issue.  We’ve fixed this issue in a later daily build.  The fix is definitely available in the current release version, build #1202.

My advise is to increment the version code, rebuild with the newest release version of Corona, and resubmit the APK.  I don’t think you need to make any code changes.

In any case, I hope I didn’t come across as argumentative up above.  Wasn’t trying to.  Just a bit confused since we’re already doing what they requested.  Anyways, I hope this helps!

#7

Thank you, Joshua.  Not at all (about being argumentative.)  I’m only thankful that you confirmed my suspicion about audio issue.

The version of the app that Google Play team reviewed is the one with Google Play Game Services multiplayer feature implemented, and it’s either the version built with 1179 or 1192 (depending on when they actually picked it up to review it.)

Thanks again.

Naomi

#8

Oh and here is something off-topic that I’m sure you’ll appreciate.

Remember sending us a bug report with a test project that looked something like the images below?  I think it was about 1 or 2 years ago about text and images coming out darker than they should on Nook and Kindle.  Well, it turns out that is one of our favorite apps to test with!  In fact, we’ve even used it for some of our Graphics 2.0 testing.  We use it to make sure that our rendering code changes still work correctly with semi-transparent vector objects, images, and text.  It’s proven itself quite handy. I’ve named it the “Fish Twister” app, because it kind of reminds me of that old Twister game mat.   :slight_smile:

#9

Oh, cool.  I do remember that simple test project I submitted (and I was very happy you fixed it soon after as well.)  Great to hear that it has become useful in more ways than I ever imagined.

Naomi

#10

Actually, onWindowsFocusChanged() will *not* give you the proper audio handling that you are looking for.  This is because it gets called for native alerts dialogs.  That is, the focus switches to the alert when it is displayed.  Most Corona developers would not want audio to pause when displaying an alert dialog.

What we’ve implemented in Corona is much smarter.  We do not pause and resume audio when the activity’s onPause() and onResume() methods are called for the exact same reasons that blog post has mentioned.  We have a broadcast receiver set up to detect when the screen is off/on and if the screen lock is displayed or not.  So, Corona does not have the issue mentioned in that blog post.  Corona will *not* resume audio while the screen lock is displayed.  Corona will correctly resume audio after the screen lock has been cleared.

So, I’m confused why you are raising this issue at all.  What problems are you seeing?  Because so far, everyone has been happy with our suspend/resume handling of audio and it’s been passing app reviews on Google Play and Amazon.

Side Note:  The only audio handling issue that I’m aware of is with the Samsung app store.  They want audio to be muted when the ringer has been put into silent or vibrate mode.  But… Google Play app reviewer disagree with this and think a game’s audio should not be affected by the ringer state.  There is no one solution to make both app stores happy on this one unfortunately.

#11

Thank you so much, Joshua, for the detailed explanation.  I really appreciate it, and it sounds great.

The thing is, I’m currently in talks with Google Play review team who states that the following must be resolved before feature consideration:

- Audio from the app resumes behind the device’s lock screen. Please refer to this page for details:

http://android-developers.blogspot.com/2011/11/making-android-games-that-play-nice.html

So, I must assume my app isn’t handling audio the way they see fit.

For a stop gap measure, I added audio.stop upon both applicationSuspend and applicationResume, which should stop any sound from continue playing upon applicationResume.  

For this particular app, I’m okay with it – but I have another, new app that has background audio that loops throughout, and I would want it to resume playing upon applicationResume.   From what you noted, I don’t even need to add audio.stop upon applicationSuspend…  But if I must, I will add it, but if I do, I will also add a code that will trigger background music upon applicationResume.  Would it cause an issue?

As for the current app under review, what you say leaves me wondering what they are seeing as an issue…

Only audio I cannot stop playing immediately after applicationResume is some sound effects that are triggered by ongoing actions.  In other words, if someone suspends the app right in the middle of some series of actions, upon applicationResume, remaining action will resume, triggering sound effects.  So, if that’s the problem, then I guess I just have to add flags which would disallow any sound from playing after the applicationResume until the user touches the screen…  (and if I’m adding such flag, I guess I’ll use it for resuming background sound too…)

I’d rather not go that route, but do you think that’s the only option I have at this point?

Naomi

#12

Did Google provide any step-by-step instructions on how to reproduce this issue?

Because, I don’t understand what the issue is.  If you press the power button, the audio stops.  When you press the power button again and show the screen lock window, audio does *not* resume.  Corona only resumes audio after you clear the screen lock.  So, we’re already doing exactly what Google wants.  That is, we’re already doing what that blog article suggest.  So, this begs the question, what exactly is Google seeing?  Or perhaps they made a mistake and giving you the results from a different app?

#13

Joshua, thank you so much for spending the time to think about this and sharing your thoughts.  

I am puzzled.  The thing is, I couldn’t reproduce it (and now you’ve confirmed it can’t be reproduced) – I just thought, perhaps, my test device isn’t set up the way people in the real world do.  Hearing your thoughts, I’m convinced that the issue isn’t what they’ve noted.  Or perhaps they have not tested it correctly.  Regardless, I may still add the flag just for a good measure…

Edit:  BTW, what Google told me is exactly what I quoted above.  They have not supplied any step-by-step instructions on how to reproduce what they see as an issue…

Edit 2:  I also rule out that they gave me a result from another app, because there are only two items they want me to fix (one about back key handling and another about this audio) and they were very specific about where back key wasn’t behaving.  Back key issue they raised matches with how my app currently behaves (that is, it ignores back key during specific events in specific scenes – which is in the process of being rectified.)

#14

It’s possible the Google app reviewer just made a mistake.

Or… it’s also possible that it might have been a bug in Corona if you’ve built your app with the last release version, build #1137.  There was a rare issue that we can only reproduce on a Nook Color where Corona would not suspend and audio would not pause when pressing the power button.  Trouble was, the Samsung app store reviewers frequently ran into this issue.  We’ve fixed this issue in a later daily build.  The fix is definitely available in the current release version, build #1202.

My advise is to increment the version code, rebuild with the newest release version of Corona, and resubmit the APK.  I don’t think you need to make any code changes.

In any case, I hope I didn’t come across as argumentative up above.  Wasn’t trying to.  Just a bit confused since we’re already doing what they requested.  Anyways, I hope this helps!

#15

Thank you, Joshua.  Not at all (about being argumentative.)  I’m only thankful that you confirmed my suspicion about audio issue.

The version of the app that Google Play team reviewed is the one with Google Play Game Services multiplayer feature implemented, and it’s either the version built with 1179 or 1192 (depending on when they actually picked it up to review it.)

Thanks again.

Naomi

#16

Oh and here is something off-topic that I’m sure you’ll appreciate.

Remember sending us a bug report with a test project that looked something like the images below?  I think it was about 1 or 2 years ago about text and images coming out darker than they should on Nook and Kindle.  Well, it turns out that is one of our favorite apps to test with!  In fact, we’ve even used it for some of our Graphics 2.0 testing.  We use it to make sure that our rendering code changes still work correctly with semi-transparent vector objects, images, and text.  It’s proven itself quite handy. I’ve named it the “Fish Twister” app, because it kind of reminds me of that old Twister game mat.   :slight_smile:

#17

Oh, cool.  I do remember that simple test project I submitted (and I was very happy you fixed it soon after as well.)  Great to hear that it has become useful in more ways than I ever imagined.

Naomi