Home

Audio Volume Update Notification Broadcast

Mon, 04/05/2010 - 21:55 — pfn
Action: 
org.openintents.audio.action_volume_update
Input: 
Broadcast action: org.openintents.audio.action_volume_update Required Extra: org.openintents.audio.extra_stream_type Type of the stream upon which the volume is being changed, e.g. STREAM_MEDIA, STREAM_RING, etc. Required Extra: org.openintents.audio.extra_volume_index The volume level to which the stream is being set
Output: 
No output, the intent should be broadcast as an Ordered broadcast so that any receiver may have the option of cancelling the broadcast and aborting the volume change.

This broadcast intent is used by an application to notify any receivers that an audio volume change is being performed.

Use cases for this intent is for preventing any unauthorized or unintentional volume changes. For example, volume rockers can easily be hit changing the ringer volume from silent to audible; Ring Guard and Advanced Audio Manager use this intent to communicate volume changes such that RG will not prevent any volume changes made by AAM, but still protect against accidental rocker activation.

Comments

Sat, 01/08/2011 - 07:06 — Bob Kerns

Not enough for reliable operation

This is a really great idea, that unfortunately isn't quite complete. Now that I've noticed it's been captured here on openintents.org, let me capture the issues.

First let me point out an important omission in the description (that I overlooked in my initial implementation): You should actually perform the indicated change in your own default handler. The priority of this handler isn't defined here. I don't recall what others are using (or what I am using, which I think I made the same). I'll post that when I figure it out.

However, that poses a problem. When your default handler receives the broadcast, you have no idea whether the broadcast you are receiving is your own -- or someone else's! And if executing it would result in triggering yourself (though you can compare with what you're expecting it to be), or worse, trigger another app to send its own broadcast.

It's really necessary in this (and many other broadcasts) to identify the sender. I suggest:
Version 2 of the protocol:
Required Extra: org.openintents.extra_protocol_version -- integer = 2. Note that omitting ".audio" is deliberate. I'm suggesting this as a bit of global meta-protocol.

Required Extra: org.openintents.extra_broadcast_sender -- string. This must be the package name of the app which is sending the broadcast. Omitting ".audio" is likewise deliberate here.

I seem to recall there are a couple other issues to consider; I'll dig up the old discussions and dig through my code, and add them here if I find them.

Fri, 08/20/2010 - 09:29 — yvolk

Implemented by Locale Audio Update Notifier plugin

The interface is being implemented by Locale Audio Update Notifier plugin.
The intent that is being sent by this plugin is currently consumed by two Android applications:
RingGuard and Volume Locker.
For more information about the implementation see Source Code at http://code.google.com/p/locale-audio-update-notifier/

Wed, 06/30/2010 - 08:47 — dimkcho

How to use this intents??

How does one use this intent from openintents.org? I took a look at the faq and didnt see anything.
This intent cannot already be bundled with android, can they? Please let me know how to use in a program making my app?

Mon, 04/12/2010 - 10:57 — yvolk

Request to support another business case

I see that current spec won't allow me to implement that "Locale Ringguard setting plug-in" which I proposed here: http://feedback.twofortyfouram.com/forums/5655-locale-feedback/suggestio...
- because my plugin will know only that _some_ Locale plugin wants to change _some_ volume and won't know exact values...
---
This new case that is needed to be supported under this spec, differs substantially from what is currently described in the spec:
1. The application that is broadcasting this intent in itself is not aware of which application (plugin...), which "stream", to what level will be set, because this is NOT the application that changes the volume. So org.openintents.audio.extra_stream_type and org.openintents.audio.extra_volume_index should NOT be required.
2. The reason why this additional application is needed to notify compatible receivers about intended (but not specified explicitely) volume changes is this:
There are already many existing applications that do change volume, but it's impossible to force their developers (reasonably quickly...) to support this spec. But in some cases (e.g. in case of Locale setting plugins) we may create "attendand" application to be used by the Man (the owner of the Android device), to to communicate this Man's wish to change volume level to all compatible receivers so these receivers won't block the change.

Mon, 04/05/2010 - 22:46 — pjv

gone from android itself + purpose

Thanks for adding this to the db.

I'd like to point out however that this is an entry that stands a good chance of being added to android itself, even though it is currently not available. From http://groups.google.com/group/android-beginners/browse_thread/thread/e8... I gather something similar has been present before.

Do I understand correctly the purpose here is also to be used by individual apps that catch the volume rocker key events and want to send out a warning?