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
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
Call release for DrmManagerClient to avoid resource leaks
Introduced by following commit (5d143ad4a8f...),
"Media scanner support for FL(Forward Lock) DRM file types"
Change-Id: Ic3c458579f4e99b3b072a2e13362d1996b982589
The top of the stack of PlayerRecord instances is the "promoted"
instance whose RemoteControlClient information is available
to RemoteController objects, only when it also has audio focus.
This change removes the condition on audio focus ownership:
- whenever the player record stack ordering changes, no need to
check if it also has audio focus
- since the player record and audio focus stacks operate separately,
there is no need to synchronize access to both stacks.
Change-Id: I668f2aa2950f19f8c2a30bc59c7352246edcc56e
Java API version
Update frameworks to enable support for CAST
V2 Authentication in the DRM Plugin.
Change-Id: I23cfbbbc89c1226b7a3968ce8bc1e2d4bd41014a
related-to-bug: 12702350
