Unhide the write mode constants.
Unhide the write method where data is stored in a ByteBuffer.
Bug 7919023
Change-Id: Ie9e24c744067f164d1a3e3363c7718b0a70e1cae
Priority is given first to the system priorty session, then to
active local sessions, then to active remote sessions, then to
the rest of the sessions. Ordering within categories is by whoever
last performed an action we associate with the user.
The stack has methods for getting filtered sets of this priority.
This also:
-Changes publish to setActive(boolean)
-Adds a flag for handling media buttons.
-Adds a flag for transport controls instead of enabling once.
-Unhides the setFlags API.
-Updates the legacy helper to use the flags.
Change-Id: I6ebeb27410de1b24149fd6e1785613ac444f0774
This adds a hidden call to set flags and a flag for making a session an
exclusive high priority session. This will cause all media button events
to be sent to that session as long as it is stillr egistered. This
requires the MODIFY_PHONE_STATE permission like the old forCalls API.
This also adds a way to get controllers for all the ongoing sessions.
This is protected by the MEDIA_CONTENT_CONTROL permission like the
old RemoteController APIs.
Change-Id: I51540e8dcf3a7dbe02a0f8ee003821e40af653a3
BOOT_COMPLETED intent is not a reliable way for system services
to detect boot completion. The intent broadcast can be significantly
delayed and there is no guaranty that system services
receive it before apps.
Use a systemReady() method called by SystemServer instead.
Bug: 14323903.
Change-Id: I781596a3545e7a1e719799982347cbcd9a4c9009
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
