This API is needed by the support library media router to ensure
that wifi display routes can be discovered while the route
chooser dialog is open.
Bug: 8175766
Change-Id: I3773773d93384aa4a3c009e71a5444ee8ce37caf
We could sometimes crash due to some inconsistencies in the
way the wifi display routes were updates when connecting,
disconnecting or scanning wifi displays.
Bug: 8837094
Change-Id: I10c7ccb163ec33c4ea107dfcb5074741049fe955
RemoteControlClient has an interface for the framework to query
the playback position. This mechanism is used to detect
when the estimated position drifts from the real position by
having the framework regularly poll (every 15s when playing at
1x) this interface and compare against the estimation.
But this mechanism:
- should only be used when IRemoteControlDisplay implementation
care about position display
- should not be used by default because the implementation of
the position query interface might involve network traffic
in some remote media player implementation for instance.
This CL implements an opt-in mechanism to be used by
implementators of IRemoteControlDisplay, to request the
anti-drift mechanism to be turned on.
bug 8120740
Change-Id: I1baa3e515546ac41e0ac9c3a41bfa3147ecf3d7f
API change in f0d4777473f25847d67fc17fc082fada08cf678d didn't update a
comment to match which caused doc build failures.
Bug: 8603279
Change-Id: I475dc569747ae5d34b4267537370f18446386bb9
Clearly identify in the logs when AudioService starts one of
the following two intents in response to long-press on
the KEYCODE_HEADSETHOOK key: ACTION_WEB_SEARCH and
ACTION_VOICE_SEARCH_HANDS_FREE.
Bug 8095981
Change-Id: I14ca99533dfb011cdc530c0bafd8104ff2436c7d
Periodically verify that the reported playback position hasn't
drifted from the estimated playback position.
If a drift is noticed, re-synchronize registered
IRemoteControlDisplay implementations.
bug 8120740
Note that this implementation updates the playback position
of all IRemoteControlDisplay implementations,
and always causes the OnGetPlaybackPositionListener to be
called. This might be undesirable in some circumstances
and will be addressed in a subsequent CL.
Change-Id: Ib9f40e1b000e912f6c35fa03e41adf81efadc894
After commit 25fc29b3, AudioManager.startBluetoothSco()
does not use virtual voice call mode anymore when starting the
SCO audio connection to the headset.
To help backward compatibility, this change makes that virtual voice call
is used if the request comes from an application targeting a SDK version
before JB MR2. For applications targeted to JB MR2 and above a raw SCO
audio connection is established.
Bug 8157702
Change-Id: If1ded2fd99b7ed76d2435d95ee03659e78a7882a
Internal message must go through the message queue, not be
dispatched immediately.
Missing 'break' when handling MSG_SEEK_TO message.
This was spamming the log with fake error messages.
Bug 8120740
Change-Id: Ib53ec05ef33133637e587eb1b24dac9ea32a5680
New APIs in android.media.RemoteControlClient to support application
exposing their current media playback position and speed, and
let the framework request position changes.
Bug 8120740
Change-Id: Ibfc41f60e279413c26147e3276d96f28b7f506e7
AudioService handles seek requests to RemoteControlClients.
Discard old or unprocessed seek requests when handling a new one.
Update javadoc for OnPlaybackPositionUpdateListener interface.
bug 8120740
Change-Id: Id17c2852b24d4b8af85e472a177484b98cfeba05
The new media button receiver with only a pending intent (no
component name) could be left hanging if the process that
registered it went away. These semantically need to be tied
to the calling process's lifetime; we now clean them up when
the calling process goes away.
Also added some additional cleanup of media button receivers
when packages change (updated, cleared).
And on top of that, a new "media" command for doing media
things. Currently lets you send media keys and monitor
remote display data.
Oh and finally added a new BaseCommand base class for
implementing these command line utilities.
Change-Id: Iba1d56f10bab1eec4a94a7bb1d1c2ae614c8bcf5
Do not use startScoUsingVirtualVoiceCall() BluetoothHeadset
API to connect SCO audio. This will cause headsets to act as if an incoming
call was received which is not what we want for voice commands.
Bug 8157702
Change-Id: I271909d4d1f3822758740a8484e3d2d8b4f34c00
CTS expects that setPlaybackRate() returns an error for a static buffer
AudioTrack that has not yet had any data written to the buffer.
Bug: 8181114
Change-Id: I17ba039368468f6ccd1eec5322018bfe420c09c8
Clarify offline usage of sessions and keys and implement
implement CryptoSession to support additional crypto use
cases.
Change-Id: Id3f8c706e9e3034b09af8e2a6a2f26bd74a49f93
RemoteControlClient defines two listener interfaces for playback
position, one to let the framework query the current playback
position, the other to request playback to seek to a given
position.
Updated IRemoteControlDisplay interface to support passing info
about whether the user of RemoteControlClient can provide a
playback position, and receive a new one.
Updated implementations of IRemoteControlDisplay to new
interface.
Bug 8120740
Change-Id: I1a5a969da4d0f8c9ad27f691919dd08f8653982b
