This makes RCC and MediaButtonReceiver (via AudioManager) also use the new Session APIs in parallel to their existing code. This will allow us to bring up the Session compatibility pieces without disrupting the old behavior and then switch everything over to just using the new APIs when ready.
Change-Id: I33ce0a044dea3ec763f2302b91a5e415be27d4a4
When updating the PlayerRecord stack on playstate changes and
media button event receiver registrations, evaluate the index
of the stack entry to remove against the index of the last playing
entry as this index was valid before the entry was removed.
This affects the insertion index.
Change-Id: Iec58d2df6bcbd8f55925e9e0f9d48f698f7cf4e5
If present and set to false, media http redirects across domains
will not be followed. As long as domains are identical, redirects
across protocols or ports will still be followed.
Also fail more seriously if redirection fails or is not supported,
so that media client does not keep retrying the connection.
Bug: 12573548
Change-Id: Ifd2539ad3a90f669d43bd0e82845dbc8ae0b4a3e
Adds a dump implementation for debugging MediaSessionService. Also
fixes some synchronize calls that weren't using the same lock object.
Change-Id: I14343f853398749c8ce7ebf91f72729abc9132d9
When registering a media button event receiver (through
AudioManager.registerMediaButtonEventReceiver()), do not
always push the receiver to the top of the stack of event
receivers:
- only push to the top if the associated RemoteControlClient
is in a playing state
- otherwise push it below the entries at the top of the stack
that are in a playing state
When changing the playstate of a RemoteControlClient:
- push to the top of the stack the corresponding PlayerRecord
is the state is a playing state
- otherwise push it below the entries at the top of the stack
that are in a playing state
When AudioService starts (e.g. after boot) and the last media
button receiver is restored, it goes in the stack.
After this CL, this entry is not "orphaned" anymore after the
same application registers itself to receive media buttons:
the entry from the restoration is now properly associated with
the registration from the application.
Bug 10749554
Change-Id: I985f9cc17b64a60ed4f2f2f6d03e117fb4e27570
The thumbnail size was not being passed to the MTP stack so getThumbnail
was returning zero length data.
Bug: 13747419
Change-Id: I309d35b5c46ab5f631c0dcb5981f7896bb5a2ed5
Compiles and works with OneMedia. This currently is a rough test of
the system for finding, connecting to, and sending messages to routes.
This will just connect to the first route it finds when a request to
open the route picker is made (and disconnect when another request is
made).
Change-Id: I5de5521a079471b9e02664be4654c0591dfd9a6d