This class seems to be written as a "view" of a "model", where the controller is the Android system itself.  In the context of RedPhone, that feels a little cumbersome because of how the state transitions need to happen.  The widget gets a click event, which gets passed through a chain of listeners to RedPhone.java, which makes an idempotent call to AudioUtils, and then calls back up through the listener chain to this widget, instructing it to update its view (which requires constructing another class that represents the current system state).

Passing the events down through the listener chain is arguably alright, but couldn't this widget handle its own view updates, rather than relying on the recipient of the click event to notify it with a representation of the system state?  Can't this class just update its view after every firing of a listener event?