Bugzilla – Bug 17130
Possible to coerce volume to 100 by tapping vol up/down keys back and forth
Last modified: 2019-01-25 12:22:44 UTC
If you tap the vol up and vol down keys rapidly back and forth the volume will eventually spontaneously jump to 100. Probably not a valid use case, thus not a show stopper, but it's reproducible. Some fidgety user might do it and then be rudely greeted with vol at 100. tested on 1.1.1 r8350, Galaxy Tab running with Comet against SBS 7.6/trunk Android 2.2
Some background information: The volume handler (as well as the progress slider) is very tricky, as it's not only a client side UI element, but server driven too. Eg. if you change volume on a Squeezebox, the server will send that information to the client (the app), which should then update the slider on the screen. If at the same time you change the volume in the app, it has to send this information back to the server (which in turn would then cause a volume change on the device itself). This information loop could potentially cause race conditions, or quick app side changes might get back from the server to the app, which then in turn would set the volume to an old/unexpected value. You should probably look into the message flow, checking whether the client (app) is triggering the volume changes, or whether the server driven update is causing the app to send another volume change back to the server.
I tried tapping the volume up and down keys rapidly in both the devices (Android 2.2 Galaxy Tab and IPad v1). But its not reproducible in the devices. Is there any specific ways to reproduce the issue?(In reply to comment #1) > Some background information: > > The volume handler (as well as the progress slider) is very tricky, as it's not > only a client side UI element, but server driven too. Eg. if you change volume > on a Squeezebox, the server will send that information to the client (the app), > which should then update the slider on the screen. If at the same time you > change the volume in the app, it has to send this information back to the > server (which in turn would then cause a volume change on the device itself). > This information loop could potentially cause race conditions, or quick app > side changes might get back from the server to the app, which then in turn > would set the volume to an old/unexpected value. > > You should probably look into the message flow, checking whether the client > (app) is triggering the volume changes, or whether the server driven update is > causing the app to send another volume change back to the server.