Mark is right about the main issue -- bumping the volume switches. But that's not the only factor -- there are applications that misbehave, and there are apps that may be "behaving" by some standard that conflicts with what the user's policy would be.
Some of us have an effort underway to standardize on an open broadcast intent protocol to allow applications to coordinate. This was originally pioneered by the developers of Advanced Volume Manager and RingGuard. The basic idea is to send an ordered intent to effect the change; handlers can then reject the change, and if you get the broadcast on your own default-level handler, then you actually effect the change. I'm not sure what changes to suggest at the SDK level. I'm not sure there's any single policy that would suit all users, so perhaps it's best left to add-on applications to enforce policies. I haven't yet tried to analyze my Flurry data to see if there are distinct patterns people settle into. What WOULD help, would be if we could be notified of volume changes in a more timely way. Currently we don't get notified of an attempt to change the volume until after a significant delay -- a second or two. This isn't much of a problem from the standpoint of ensuring that no lasting harm is done to the user's desired setting, but it makes for a very confusing UI. Being able to immediately reject an unwanted volume change would be much more understandable. It *might* make sense to institute a permission for permanent changes, and a way to change a volume stream for the life of an activity, or the life of a service. Activity.setStreamVolume(stream, volume, flag). These wouldn't require the permission. It would also help if the AudioManager were actually fully implemented, returned the correct number of available streams, and appropriate metadata about what the different streams can do, which ones are linked to which other ones, etc. It would really help to be able to define additional ones, active for the life of an application or a service, that default from one of the system ones. This would allow a better user experience, where the user actually sees what specific audio is playing, and can control the volume for that one directly. It was clearly inappropriate that AudioManager.NUM_STREAMS was a constant, rather than a function. But making it deprecated, in favor of AudioSystem.getNumStreamTypes(), which isn't even part of the SDK, was not an improvement! On Apr 30, 2:30 pm, Dianne Hackborn <hack...@android.com> wrote: > On Fri, Apr 30, 2010 at 8:46 AM, Bob Kerns <r...@acm.org> wrote: > > Just to emphasize Mark's point: Thousands of people have downloaded my > > app to *prevent* accidental changes to volume controls, primarily the > > ringer volume. > > Hm, so should be be more restrictive about how applications can modify the > value level(s)? > > -- > Dianne Hackborn > Android framework engineer > hack...@android.com > > Note: please don't send private questions to me, as I don't have time to > provide private support, and so won't reply to such e-mails. All such > questions should be posted on public forums, where I and others can see and > answer them. > > -- > You received this message because you are subscribed to the Google > Groups "Android Developers" group. > To post to this group, send email to android-developers@googlegroups.com > To unsubscribe from this group, send email to > android-developers+unsubscr...@googlegroups.com > For more options, visit this group > athttp://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
