Thanks for the explanation Joshua.
For what it’s worth, I noticed the volume buttons work correctly when there is a native.showAlert box being shown, also during a native.setActivityIndicator is true.
JonPM,
I work on the Android code here. Yes, what you’ve stated is true. Holding down the volume key does not continuously lower/raise the volume. It only steps the volume up/down 1 level. There is no work-around. It’s been like this for 2 years. You’re actually the 1st Corona developer to notice it.
There is actually a technical reason involving multithreading as to why this behavior exists. But that said, nobody has ever had their apps rejected by reviewers or received bad reviews on the app store regarding this behavioral difference. So, we stuck with this behavior. We don’t consider it a bug since the volume controls still work. Changing it to match would require significant effort on our part. So, we’ve left it the way it is.
Thanks for the response Joshua. When you say there is no work-around do you mean the methods advised above (i.e. using a timer) won’t work either?
I wasn’t really concerned about the app getting rejected, but more concerned with user experience. I must admit my rant was out of frustration, as I am spoiled by Corona because it usually makes everything much more simpler and “automated”. To see a “basic” function out of order is a little disheartening. In the end it isn’t that big of a deal. I just prefer things to work as they should, as I’m sure you do too.
You definitely need to return false for the volume keys. That allows the operating system to handle the change of volume, which you can see when the Android volume control popup show onscreen. However, it still won’t allow the volume to increase/decrease continuously. In fact, I highly recommend that you return true *only* for the keys which you are handling and return false by default. Otherwise, you might encounter other unexpected behaviors.
If you want to know the nitty gritty details, then here is the reason why the volume does not get raised/decreased continuously. In Corona, the Lua runtime does not run on the main UI thread, but on a separate thread. Android key events are raised on the main UI thread. So, what we have to do is handle *all* key events received by the main UI, queue the events to be raised on the Lua thread, call the Lua listener for each queued key event, queue key events back onto the main UI thread that were not handled in Lua (ie: returned false), and finally re-dispatch the key events back to the activity/window to be handled by Android. We can’t call Lua listener directly from another thread, because this would cause race conditions and possibly crashes, making the above process necessary. The unfortunate side effect is that we lose Android default volume handling by handling all key events in native code and then re-dispatching them back to the window. Instead, the behavior we get is the volume being raised/lowered by a single step.
In the future, it would be much more worth it to have the Lua running on the main UI thread, because that would vastly simplify the above process, simplify enterprise/plugin development, and help us introduce other features that require main UI thread access. But there are other technical details, namely OpenGL not running on the main UI thread by default on Android, that’s holding us back on that at the moment. However, that’s something I want to experiment with later this year.
in any case, I hope the above helps explain this.
I was just doing some debugging and noticed this myself… it’s really annoying to me as a user because I often turn my volume all the way down at night… and then all the way up when testing certain apps. I hope you guys figure out a better way to deal with this in the near future.
I have a related follow up question though… while doing this debugging… I’ve noticed that I’m not seeing an event.phase=“up” for the “back” nor volume keys. I read through some android developer info and can see that they changed the behavior if the target SDK is version 5 and beyond so the back key is detected on the “up” instead of the “down” depending on the target SDK. I didn’t see anything like that documented for the volume keys though.
The reason I’m asking is because I want to be clear on the “Corona endorsed” way of dealing with the “back” key… some code I’ve seen skips the event.phase check… which could be dangerous if this is ever “fixed” and we start seeing a “down/up” sequence. Then some code checks for “down” and some code checks for “up” and that can also be dangerous if the event.phase ever changes for special keys such as the android “back” key. In that case, for special keys, I would think a more relevant event phase indicator would either be (nil) or “pressed” in my opinion.
At any rate, coming full circle back to the “volume” key issue… I was originally thinking of implementing my own timer based work-around for the volume key problem… but I cannot do that if I don’t see both an “down” and “up” event.phase for the volume key. If I did see those events, then I can devise an incrementally increasing volume up timer event after I see the “volumeUp”/“down” event/phase and stop it when I see the “volumeUp”/“up” event/phase… and the same for “volumeDown” keys.
So I’m wondering if all of this is related… why I’m not seeing “down”/“up” for these special keys… and what the “official” Corona response is on how to code up these types of event listeners… so at the very least… I can understand how it’s supposed to work in Corona… and try to future proof myself.
The “up” and “down” phases definitely work in Corona. However, there are some rogue devices that do not provide an “up” phase for the back key. For example, the GalaxyTab does not provide an “up” phase for the back key if you hold it down for a half second or longer. This is because the Android OS (likely a forked version of the OS) steals this key event. It does this because the GalaxyTab has a secret feature where holding down the back key and pressing the power button causes it to take a screenshot. This is not a Corona bug. The device is literally not providing the up event to native code, meaning there is no possible way to work-around this behavior. I suspect you are running into something like this with your device. Because of this, I highly recommend that you use the “down” phase instead which has been proven to be reliable on all devices we’ve tested with so far.
Thanks for the explanation Joshua.
For what it’s worth, I noticed the volume buttons work correctly when there is a native.showAlert box being shown, also during a native.setActivityIndicator is true.
I was just doing some debugging and noticed this myself… it’s really annoying to me as a user because I often turn my volume all the way down at night… and then all the way up when testing certain apps. I hope you guys figure out a better way to deal with this in the near future.
I have a related follow up question though… while doing this debugging… I’ve noticed that I’m not seeing an event.phase=“up” for the “back” nor volume keys. I read through some android developer info and can see that they changed the behavior if the target SDK is version 5 and beyond so the back key is detected on the “up” instead of the “down” depending on the target SDK. I didn’t see anything like that documented for the volume keys though.
The reason I’m asking is because I want to be clear on the “Corona endorsed” way of dealing with the “back” key… some code I’ve seen skips the event.phase check… which could be dangerous if this is ever “fixed” and we start seeing a “down/up” sequence. Then some code checks for “down” and some code checks for “up” and that can also be dangerous if the event.phase ever changes for special keys such as the android “back” key. In that case, for special keys, I would think a more relevant event phase indicator would either be (nil) or “pressed” in my opinion.
At any rate, coming full circle back to the “volume” key issue… I was originally thinking of implementing my own timer based work-around for the volume key problem… but I cannot do that if I don’t see both an “down” and “up” event.phase for the volume key. If I did see those events, then I can devise an incrementally increasing volume up timer event after I see the “volumeUp”/“down” event/phase and stop it when I see the “volumeUp”/“up” event/phase… and the same for “volumeDown” keys.
So I’m wondering if all of this is related… why I’m not seeing “down”/“up” for these special keys… and what the “official” Corona response is on how to code up these types of event listeners… so at the very least… I can understand how it’s supposed to work in Corona… and try to future proof myself.
The “up” and “down” phases definitely work in Corona. However, there are some rogue devices that do not provide an “up” phase for the back key. For example, the GalaxyTab does not provide an “up” phase for the back key if you hold it down for a half second or longer. This is because the Android OS (likely a forked version of the OS) steals this key event. It does this because the GalaxyTab has a secret feature where holding down the back key and pressing the power button causes it to take a screenshot. This is not a Corona bug. The device is literally not providing the up event to native code, meaning there is no possible way to work-around this behavior. I suspect you are running into something like this with your device. Because of this, I highly recommend that you use the “down” phase instead which has been proven to be reliable on all devices we’ve tested with so far.
Sorry for bumping an old thread but doesn’t this mean that if we use the timer solution for holding down the keys that we’ll have no way to stop holding down the volume key for galaxytab users if the up event is never fired? We’d have to check for specific devices or have some kind of timeout (which would give a bad user experience).
In the case of the GalaxyTab, it only steals the “Back” key’s “up” phase. The GalaxyTab does not do this with the volume keys.
Awesome, i’ll go ahead and implement the hold functionality then!
Sorry for bumping an old thread but doesn’t this mean that if we use the timer solution for holding down the keys that we’ll have no way to stop holding down the volume key for galaxytab users if the up event is never fired? We’d have to check for specific devices or have some kind of timeout (which would give a bad user experience).
In the case of the GalaxyTab, it only steals the “Back” key’s “up” phase. The GalaxyTab does not do this with the volume keys.
Awesome, i’ll go ahead and implement the hold functionality then!
any solution for this. Samsung is rejecting app that does not continuosly update the OS volume when holding down the volume up/down key
rbm1155,
Well that’s extremely picky of Samsung. Google Play and Amazon have never rejected apps because of this. I suppose as an alternate solution you could always override the volumeUp/Down key events and then adjust the volume yourself via Corona’s audio.setVolume() function. But note that this function will adjust the volume for sounds played via the “audio” APIs and not the “media” APIs. It will not actually adjust the operating system’s volume levels. If your app is a game, then adjusting volume levels in this manner is pretty normal.
Hi Joshua,
Thanks for the response.
I think samsung is referring to OS volume, since it shows the slider volume control.
they want the slider volume to update.
i already made it work via audio.setVolume but it does not show the slider volume control which I think what samsung wanted.
Yeah, the audio.setVolume() will not display the operating system’s volume slider. This is because that function adjusts the audio stream’s “gain” at the OpenAL/OpenSL level.
Well shoot. If that’s what they want, then I don’t have a work-around for you.
Are you not able to negotiate with them about this and say that this is by your app’s design? I’ve seen other Corona made apps that always override the volume keys and handle the volume levels themselves, such as a separate volume level for background music and sound effects. That’s pretty normal for games.
I will try to compose a compelling response to Samsung, so they can re-evaluate.
I have my own other horrors submitting to Samsung , I have 5 apps approved 1.3 years ago, now i have 21 apps.
so I decided to upload the new apps. But hey, it’s really hard to get approved especially with their
extra special QA process.
Thanks for the reply Josh.