History log of /frameworks/support/v7/mediarouter/src/android/support/v7/app/MediaRouteButton.java
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
429c3b17b88ebd8c4512e9179fd9d48333c0979e 21-Mar-2014 Tor Norbye <tnorbye@google.com> Add tools metadata annotations to the mediarouter library

Change-Id: I69322fb994a840b7142109ca48c29fb51829a2dd
/frameworks/support/v7/mediarouter/src/android/support/v7/app/MediaRouteButton.java
d59166433cee5a854f60321a469e225effac480f 10-Nov-2013 Jeff Brown <jeffbrown@google.com> Remove dead code.

Bug: 11257292
Change-Id: Ifb88f3fe03a8a3bc3cdf372d902f4b63c1ed454b
/frameworks/support/v7/mediarouter/src/android/support/v7/app/MediaRouteButton.java
eff7719415542ba819054863b0995f07742a7a8a 10-Jul-2013 Jeff Brown <jeffbrown@google.com> Media router API updates.

Added a MediaRouteDialogFactory to make it easier for applications
to customize the dialog fragments such as adding custom views
into the media route controller dialog.

Added an API to disable volume control in the media route
controller dialog.

Added a method that the application can override to change how
routes are filtered in the chooser dialog.

Changed the remote playback protocol to isolate the queuing
feature and @hide it. This required a few semantic changes
to the protocol so that the non-queuing subset is able to
stand on its own and be coherent. Most of these changes are
simple renames and incremental changes of existing concepts
but the documentation had to be substantially updated to keep
it clear.

The protocol changes are roughly as follows.

- QUEUE_ID renamed to SESSION_ID. Sessions are created
implicitly by ACTION_PLAY just like queues but the concept is
somewhat more generic. The session is documented conceptually
as having a queue that can only contain at most one item which
makes it easier to explain certain behaviors. However, we
now deemphasize the concept of the queue in the documentation and
focus more on the session. Since the word "queue" no longer
appears in the API, we could go either way in the future and choose
to expand on or abandon the queue concept just by changing
the documentation.

- ACTION_STOP renamed to ACTION_REMOVE and now @hide. The action
removes one specific item from the queue.

- ACTION_CLEAR_QUEUE renamed to ACTION_STOP. Now documented to
have the side-effect of both clearing and unpausing the queue
like hitting a reset switch on the session. The choice of name
creates good symmetry with ACTION_PLAY in the single item case.

- ACTION_ENQUEUE (@hide) added to represent the previous
queuing behavior so that we can continue to experiment with it.
Support for this action might be optional in the future.

- ACTION_PLAY is documented in a way that makes it equivalent
to ACTION_STOP followed by ACTION_ENQUEUE. This way we enforce
the constraint that the queue can have at most one item in it
while still leaving the door open to exposing more features later.

- ACTION_PAUSE_QUEUE renamed to ACTION_PAUSE. We still refer to
it as conceptually pausing a queue but this now fits in better with
the one at a time nature of ACTION_PLAY.

- ACTION_RESUME_QUEUE renamed to ACTION_RESUME.

- PLAYBACK_STATE_QUEUED renamed to PLAYBACK_STATE_PENDING.

- PLAYBACK_STATE_STOPPED renamed to PLAYBACK_STATE_FINISHED to make
it clear that this state means the media item finished playing
normally.

- PLAYBACK_STATE_CANCELED now only means that the media item was
canceled by the app by way of ACTION_PLAY or ACTION_STOP
(or ACTION_REMOVE) which caused the item to be removed from the
queue before it had a chance to finish normally.

- PLAYBACK_STATE_INVALIDATED added to specifically refer to the
case where another application takes control of the route and
stomps on the session and its media items. The documentation now
consistently uses the word invalidate rather than cancel when
referring to sessions or media items that have been involuntarily
aborted by an external cause.

- @hide HTTP request headers, response headers and status code.

Bug: 9743462
Change-Id: I3bdb4cd8947112ab409983a74fa4bc062465149a
/frameworks/support/v7/mediarouter/src/android/support/v7/app/MediaRouteButton.java
d11aa1784335270b8d85e385f2c8be79ee6a586c 31-May-2013 Jeff Brown <jeffbrown@google.com> Remove isActiveScanRequired().

This flag was originally added to support media route providers
that are unable to discover media routes passively. However, this
would be true in practice for most media route providers since
they will usually need to poll the network periodically to find
new routes.

Previously we did not have a good way to tell when discovery was
really needed so we forced these providers to rely on active scans
instead. Unfortunately this meant that the MediaRouterButton needed
to be visible all of the time.

Now that we have CALLBACK_FLAG_REQUEST_DISCOVERY, we can be more
conservative about when discovery occurs. In practice, discovery
will only happen when an application that uses media router is in
the foreground. So it's ok for providers to do some moderate work
during normal discovery and we don't need to force them to rely
exclusively on active scans anymore.

We also remove getDiscoverableControlFilters() since it was only
needed for the case where active scans were required.

Note that we still do perform active scans when the chooser dialog
is open. However, we don't allow providers to require them.
This even works for Wifi Display because the system already knows
which displays have been paired so it doesn't require active scans
to decide whether to advertise those routes (although it does
require active scans to discover whether they are really available).

Bug: 9210033
Change-Id: I69adaf42fb461ee2b564e3605f921d23b6b5c7be
/frameworks/support/v7/mediarouter/src/android/support/v7/app/MediaRouteButton.java
9942d40d0d952b03b583fe66f434676793697aa2 24-May-2013 Jeff Brown <jeffbrown@google.com> MediaRouter UI tweaks.

Fix an issue where the MediaRouteButton would cause the currently
selected route to be deselected when switching activities.
The button now no longer has any side-effects.

Added code to handle the case where the dialog may be empty
by showing a progress bar and placeholder text.

Make the route chooser and controller dialogs dark to match
the system volume dialog.

Fixed the dividers in the route controller dialog.

Fixed some incorrect assumptions in the MediaRouteActionProvider
related to whether the MediaRouteButton has been attached to
the window. Sometimes we would fail to add the necessary
route callbacks. This was intended to workaround a framework
limitation but it caused other problems.

Fixed the padding of the media route button.

Cleaned up some documentation.

Bug: 9102538
Change-Id: I226e33c3017e8e4a9d877d023a8f158184861343
/frameworks/support/v7/mediarouter/src/android/support/v7/app/MediaRouteButton.java
11417b1cfde8f1749905f2d735623af9214148af 27-Apr-2013 Jeff Brown <jeffbrown@google.com> Add media router picker UI.

Introduced the concept of a MediaRouteSelector which is the means
by which an application states the route capabilities of routes
that it would like to discover.

Added selectors to the addCallback method along with several
other methods to assist with discovery. Callbacks can specify
flags to perform active scans of routes or to disable filtering
of route events.

Added a workaround to scan for wifi displays on JB MR1.

Refactored the route descriptor objects to use the builder pattern
instead of simply documenting that they should be immutable
since several developers have already tripped over this.

The UI is feature complete but not final.

Bug: 8175766
Change-Id: I54ebb7488222746b0c07292e65b9ded1b9d720fa
/frameworks/support/v7/mediarouter/src/android/support/v7/app/MediaRouteButton.java