SurfaceMediaSource_test now does not use pbuffer configs
to create a surface. Always uses a window config.
Also, cleaned up the test a bit.
Change-Id: Idda40dcb8474249eccaa8d2dad20ee840d2dd484
Update to the RemoteControlClient.Editor API:
- new method for setting metadata of type long
- methods for setting metadata throw an exception if using
the wrong key with the wrong method.
Note that this change will cause the Music2 application to
throw an exception when it tries to set the duration as a string.
Change-Id: I17cff86467851a0aff313c07653e752ae6b6180f
When an IRemoteControlDisplay registers, cause the
RemoteControlClient to send all its information to the newly
registered display.
The previous code was only sending a request for update: this
request didn't here cause the client to send the data because
a new client generation had not been synchronized among clients
and displays.
This CL uses the same code path to force an update as when audio
focus changes, or a new client registers, by calling the same
method that is called in those cases,
updateRemoteControlDisplay_syncRcs(flags).
Also in this CL: more method renames to indicate methods that
are called synchronized on mRCStack.
Change-Id: I54102f45ba1cd4812d958ecd883bec7bc45ae88f
* changes:
MediaDump: use the MediaPlayer#setSurface method
HTML5VideoView: switch to MediaPlayer#setSurface
MediaPlayer: unhide the setSurface method
Surface: unhide the SurfaceTexture ctor
When the A2DP headset is connected, there is a possible
race condition when the audio tracks are moved from
the mixer thread attached to the speaker output to the thread
attached to A2DP output.
As the request to clear the stream type to output mapping cache in
the client process is asynchronous, it is possible that the flag
indicating to the client audio track to re-create the IAudioTrack
on the new thread is processed before the cache is invalidated.
In this case, the track will be attached to the old thread and
music will continue playing over the device speaker instead of being
redirected to A2DP headset.
Change-Id: Ib2ce1eb5320eaff83287b93779061bf4e7a330df
Video Editor engine wrongly set the profile in place of level.
So level was always 1 (default value for Profile)
Change-Id: I202f866d32e81869d9692174d59d9d777a772282
This previous frame size computation code had two incorrect
assumptions:
1/ the ADTS frame length value already contains the header size
2/ the ADTS header is not of fixed size: it is 2 bytes bigger
if it contains the CRC value.
For 1/, the code worked because when the header size was added
to the frame size, the + operator is of stronger precedence
than the ? operator, so the size added was always 0 (instead
of ADTS_HEADER_LENGTH.
For 2/, the code worked as long as there was no CRC in the ADTS
data.
The fix consists in:
- documenting what the frame length computation code returns
- fixing the frame length computation
- when computing the frame length, also returning the header
size so the correct data can be sent to the decoder.
Change-Id: I92df72a9e531f594f762e63d62f9dee7b0109904
This change updates the MediaDump test to use the new
MediaPlayer#setSurface method in place of MediaPlayer#setTexture, which
will be removed.
Change-Id: I33f59705c728f0884452d45cf83cb5b80f66a95a
Cannot trust references to IRemoteControlDisplay to remain the
same when removing a RemoteControlDisplay, compare the
result of .asBinder() instead.
Change-Id: Ib2e82aa24bd4b12804bccff94a6a0090ff83bea8
The RemoteControlClient / Display feature only supports one
display. If multiple displays are registered, this CL implements
the following policy:
- cannot unregister a display that is not the current one,
- registering a display when another is already registered
causes the old one to be unregistered.
This fixes a death handler leak where the previous display was
simply overwritten, without unlinking to its death.
Change-Id: I63f8a38093796e0960761936d7fc58d47b7589b3
If a RemoteControlClient has a null artwork, do no attempt to
rescale the bitmap, it's ok to send a null bitmap to the
IRemoteControlDisplay.
Change-Id: I8332ccfcf18107ea0b41d4e7fa232d7f68798efc
in order to compute the final delay before posting end-of-stream correctly.
Change-Id: I4ff6d7142fdf1ea2d19d12ec78c1e84322d22e5f
related-to-bug: 5216930
AudioTrack::stop() is not synchronous, so a stop() followed
by flush(), which is synchronous, will not always report
a playhead position of 0 after being called.
This CL adds a flag to mark a track as flushed, and report the
correct playhead position in this state.
Bug 5217011 has been created to address the real issue in the
future, where flush could be made synchronous, to properly
address bug 4364249.
Change-Id: Icf989d41a6bcd5985bb87764c287f3edb7e26d12
Locks related to audio focus and remote control should always be
taken in the following order:
1/ audio focus lock
2/ remote control stack
3/ current remote control client generation
Change-Id: If8be11bfef92849957e692b2bd52adbd67a2ef0b
The client does not have to send (w, h) = (0,0) in dequeuebuffer. It can
set the same w, h as the default width and height.
Change-Id: I8202f90261ccaebbd35ea28c153a7472f01912f1
