There's a longer term plan to fix audio/video sync, but
this gets the Java level to parity with the native level,
and allows applications in Java to achieve sync in the
same way as the native media player. APIs are left as hidden
for now.
Bug: 9587132
Change-Id: Iaf70baac1ffb50ef48e03355163158568fbd0fe9
The BT stack needs to differentiate between applications that use
the new RemoteControlClient APIs to pass a playback position but
don't have one yet, and applications that use the legacy API and
will never pass a position.
Bug 9294855
Change-Id: I05cba82a073e6e0aaea1d8bbf9cc8c99da715f58
SAMPLE_SYNC_FLAG is not used by MediaMuxer; instead,
MediaCodec.BUFFER_FLAG_SYNC_FRAME is used, which has
the same value.
Remove this now, so that users will not have to translate
MediaCodec flags to MediaMuxer flags, even though MediaMuxer
takes in MediaCodec.BufferInfo objects to specify these flags.
Change-Id: I4b2f2039ca16debf4788a530a36bdd06d516f417
Signed-off-by: Lajos Molnar <lajos@google.com>
Bug: 9169479
If requested by ro.audio.monitorOrientation property, set orientation
information as audio system parameter on configuration changes.
Bug 9095903
Change-Id: I669d4084eade3c14feb63f644bdd5b74fddc8857
additional functional tests for: flash, exposure, white balance, and
focus mode. Also add pairwise tests.
Slight refactor to add camera test helper and also additional
tests for: flash, exposure, white balance, and focus mode
Bug: 9174937
Change-Id: I3d26b545dc8ff972c8173066df59a2e572a837ef
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
There's a runtime check for a bad argument, but it is
after the usage of the bad argument. Move the usage
after the check.
Bug 8687716
Change-Id: Iddfa457951bac69b436a430cda21b5d7a563107b
Signed-off-by: Mike J. Chen <mjchen@google.com>
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
